OpenStack - User contributions [en]

Governance/InteropWG

2014-03-21T19:56:29Z

Joshua-mckenty:

This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.

Our mission is to define "OpenStack Core" as chartered by the by-laws and guided by [[Governance/CoreDefinition]]

== Objective / Scope ==

The DefCore charter is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.

There are three ways in which the community uses the OpenStack brand including referring to projects.
# General community use of the mark
# Project-specific use associated with development activity
# DefCore-governed commercial use

While the top two of these uses are out of scope for DefCore, the committee has a need to participate in the discussion to ensure consistent and clear use.

== Current Committee Participants ==

=== Defcore committee (board members) ===
* Rob H. (Co-chair)
* Josh M. (Co-chair)
* Alan Clark
* Sean Roberts
* Troy Toman
* Randy Bias
* Eileen Evans
* Lew Tucker
* Mark McLoughlin
* Van Lindberg
* John Zannos

=== Defcore participants (non-board member) ===
* Anne Gentle
* Jonathan Bryce
* Mark Radcliffe
* Mark Collier
* Michael Still
* Rochelle Grober

=== Criteria Subcommittee ===
* Rob H.
* Josh M.
* John Zannos
* Rochelle Grober
* Troy Toman

=== Legal subcommittee ===
* Eileen Evans
* Mark Radcliffe

=== Former / Inactive committee participants / member ===
* Nicolas Barcet
* Monty Taylor
* Russell Bryant
* Simon Anderson
* Todd Moore

== How to Engage? ==

* Read the (pending) white paper and (pending) watch the video about DefCore.
* Join the [[http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee defcore-committee]] list
* Join #refstack on Freenode IRC
* Follow PlanetOpenStack DefCore Tag (instructions pending)
* Follow the code at https://github.com/stackforge/refstack
* Register your user and then upload your test results to [[RefStack.org]] (instructions pending)

== RefStack ==

RefStack is a way of collecting and comparing test results that support the core definition process.

Details on using [[RefStack]]

== Governance Process ==

* Meetings will be interactive using Google Hangouts (we will already stream for non-committee members)
* Members are expected to to their homework. We will _not_ be rehashing due to time limits.
* Meetings will work from resolutions that are proposed in advance with +/- voting (cochairs are +/-2)
** as per Board of Directors policy, we welcome broad engagement but cannot allow proxies on resolutions
** resolution +/- could be asserted before the meeting (but may have to be overruled based on discussion)

== Process Cycles ==

Defining OpenStack Core is a long term process and we are doing the work in progressive cycles. For reference, we have named the cycles. This helps describe concrete deliverables for a cycle while allowing discussion of the broader long term issues. For example, we may say that "item X is important to DefCore but out of scope for Elephant." We have found that this approach to breaking down the problem is necessary to maintain community consensus because we are taking smaller bites of the larger challenge (aka eating the elephant).

=== Spider (previous, Fall 2013) ===
Objectives
# Find a consensus approach to moving forward on DefCore
# Define process by which Core will be defined

=== Elephant (current, Spring 2014) ===
Objectives:
# If needed, change the bylaws to reflect the Spider Core Principles
# Establish the "must-pass" tests, processes and tools
## Define tests that will be used to determine core based on Spider cycle work
# Lower the water in the discussion to expose broader issues
## Clearly identity "elephants" that we are not ready to resolve in this cycle
==== Elephant Etherpads ====
https://etherpad.openstack.org/p/DefCoreElephant.2 
https://etherpad.openstack.org/p/DefCoreElephant.3 
https://etherpad.openstack.org/p/DefCoreElephant.4 
https://etherpad.openstack.org/p/DefCoreElephant.5 

=== Future ===
Names to be decided when we get there.
Topics ("Elephants") that are intentionally pushed into the future:
* OpenStack Compatible Mark
* ... Committee Chairs will add to this ...

== Meetings/Agenda Schedule ==

* 11/20 [[Governance/CoreDefinition/Meeting20131120]]
* 12/03 [[Governance/CoreDefinition/Meeting20131203]]
* 12/10 Criteria Subcommittee
* 12/17 1:30 PST [[Governance/CoreDefinition/Meeting20131217]]
** OIN impacts from Core/Commons definition
** How to figure out where we have gaps in Tempest coverage
** Program vs Project Definition Discussion
** Define a process by which programs are nominated for use with the mark by which tests certified for use with the mark test list is vetted and approved by the board
* 12/30 1:30 PST Criteria Subcommittee Meeting

Governance/Foundation/30Jan2014BoardMeeting

2014-01-30T20:07:42Z

Joshua-mckenty:

== Board of Directors - January 30, 2014 Meeting ==
The OpenStack Foundation Board of Directors will meet at 12:00pm - 2pm on January 30, 2014. Directors may participate via conference dial-in. Audio from the meeting will also be available to the community.

To join the session
# Go to https://openstack.webex.com/openstack/k2/j.phpED=250657692&UID=0&HMAC=5a750fba5b7e9342b7acb67cc264f5eed89cb7a8&RT=MiM2
# Enter your name and email address.
# Enter the session password: This session does not require a password.
# Click "Join Now".
# Follow the instructions that appear on your screen.

== Agenda ==
: * Julia Dechance will monitor and manage the webex connection
: * Minutes recorded by AlanClark (Mark Radcliffe is not available for the full meeting)
'''Call To Order'''
# Roll Call
# Approve minutes from November 4th board meeting

'''Welcome to the new board members'''
# Introduction of new board members
# Quick review of
## Antitrust policy (https://wiki.openstack.org/wiki/Governance/Foundation/AntitrustPolicy) - Mark designee
## Code of Conduct (https://wiki.openstack.org/wiki/Governance/Foundation/CodeOfConduct) - Alan
## Transparency policy (http://www.openstack.org/legal/transparency-policy/) - Joshua
## Communication channels
### webex for the board meeting calls (thank you to Lew)
### Foundation mailing list
### board mailing list
### IRC #openstack-board
###Other?
# 2014 Board meeting schedule
## https://wiki.openstack.org/wiki/Governance/Foundation

'''Current Board work groups and committees'''
:(Suggested topic: Goals for 2014, current efforts, next steps, issues that the board needs to address, current members, invitation to new board members, Is the committee open to community member participation?)
# Compensation Committee - Alan Clark
# Financial Committee - Sean Roberts
# User Committee - Tim Bell
# Legal Advisory Committee - Van Lindberg
# Election Committee - Todd Moore
# Transparency Work Group - Joshua Mckenty
## http://www.slideshare.net/joshuamckenty/transparency-committee
# DefCore Work Group - Rob Hirschfeld / Joshua Mckenty
## https://docs.google.com/presentation/d/19lkpHcYHr4OpVj45XP1gVMKVYfOPaFzqiNc92vqhEvI/edit?usp=sharing&invite=CI68xr8K
# New Gold Member Committee - Simon Anderson

'''Executive Director Update'''
# 2014 Objectives

'''New Strategic Topics'''

Governance/Foundation/30Jan2014BoardMeeting

2014-01-30T20:02:32Z

Joshua-mckenty:

== Board of Directors - January 30, 2014 Meeting ==
The OpenStack Foundation Board of Directors will meet at 12:00pm - 2pm on January 30, 2014. Directors may participate via conference dial-in. Audio from the meeting will also be available to the community.

To join the session
# Go to https://openstack.webex.com/openstack/k2/j.phpED=250657692&UID=0&HMAC=5a750fba5b7e9342b7acb67cc264f5eed89cb7a8&RT=MiM2
# Enter your name and email address.
# Enter the session password: This session does not require a password.
# Click "Join Now".
# Follow the instructions that appear on your screen.

== Agenda ==
: * Julia Dechance will monitor and manage the webex connection
: * Minutes recorded by AlanClark (Mark Radcliffe is not available for the full meeting)
'''Call To Order'''
# Roll Call
# Approve minutes from November 4th board meeting

'''Welcome to the new board members'''
# Introduction of new board members
# Quick review of
## Antitrust policy (https://wiki.openstack.org/wiki/Governance/Foundation/AntitrustPolicy) - Mark designee
## Code of Conduct (https://wiki.openstack.org/wiki/Governance/Foundation/CodeOfConduct) - Alan
## Transparency policy (http://www.openstack.org/legal/transparency-policy/) - Joshua
## Communication channels
### webex for the board meeting calls (thank you to Lew)
### Foundation mailing list
### board mailing list
### IRC #openstack-board
###Other?
# 2014 Board meeting schedule
## https://wiki.openstack.org/wiki/Governance/Foundation

'''Current Board work groups and committees'''
:(Suggested topic: Goals for 2014, current efforts, next steps, issues that the board needs to address, current members, invitation to new board members, Is the committee open to community member participation?)
# Compensation Committee - Alan Clark
# Financial Committee - Sean Roberts
# User Committee - Tim Bell
# Legal Advisory Committee - Van Lindberg
# Election Committee - Todd Moore
# Transparency Work Group - Joshua Mckenty
# DefCore Work Group - Rob Hirschfeld / Joshua Mckenty
## https://docs.google.com/presentation/d/19lkpHcYHr4OpVj45XP1gVMKVYfOPaFzqiNc92vqhEvI/edit?usp=sharing&invite=CI68xr8K
# New Gold Member Committee - Simon Anderson

'''Executive Director Update'''
# 2014 Objectives

'''New Strategic Topics'''

Foundation-participation

2013-12-09T17:40:34Z

Joshua-mckenty:

{| class="wikitable sortable"
|-
! Rights, Responsibilities, Restrictions (more details on the [http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/ bylaws]) ([https://docs.google.com/spreadsheet/ccc?key=0Ahy1qS0O_cnldFdEcHNVdEJEN2tnTWNnZV9ZeThhZmc&usp=sharing source]) !! role !! cost !! maximum count !! election held !! can be an openstack foundation member !! can be an Active Technical Contributor (ATC) !! can be a openstack foundation employee !! vote in individual board director elections !! vote in technical committee elections !! vote in gold board director elections !! vote in project elections
|-
| platinum board director || individual || none || 8 || see bylaws || yes || yes || no || unrescrictive no || unrescrictive no || no || unrescrictive no
|-
| platinum member || company || $500,000 || 8 || see bylaws || yes || yes || no || unrescrictive no || unrescrictive no || no || unrescrictive no
|-
| gold board director || individual || none || 8 || first two weeks of January || yes || yes || no || unrescrictive no || unrescrictive no || additive yes || unrescrictive no
|-
| gold member || company || $50,000-$200,000 || 24 || see bylaws || yes || yes || no || unrescrictive no || unrescrictive no || yes || unrescrictive no
|-
| corporate sponsor || company || $10,000-$25,000 || none || none || yes || yes || no || unrestrictive no || unrestrictive no || unrestrictive no || unrestrictive no
|-
| individual board director || individual || none || 8 || first two weeks of January || yes || yes || yes || unrescrictive no || unrescrictive no || no || unrescrictive no
|-
| individual member || individual || none || none || none || yes || yes || yes || unrescrictive no || unrescrictive no || no || unrescrictive no
|-
| technical committee member || individual || none || none || staggered every 6 months || yes || yes || yes || additive yes || additive yes || no || if a project ATC, additive yes
|-
| project technical lead (PTL) || individual || none || 1 || any project ATC || additive yes || additive yes || yes || additive yes || additive yes || no || if a project ATC, additive yes
|-
| project core reviewer || individual || none || none || none || additive yes || additive yes || yes || additive yes || additive yes || no || if a project ATC, additive yes
|-
| project reviewer* || individual || none || none || none || additive yes || additive yes || yes || additive yes || additive yes || no || if a project ATC, additive yes
|-
| project active technical contributor (ATC) || || none || || none || additive yes || additive yes || yes || additive yes || additive yes || no || additive yes
|-
| active technical contributor (ATC) || individual || none || none || none || additive yes || additive yes || yes || additive yes || additive yes || no || if a project ATC, additive yes
|-
| summit sponsor || company || $7,500 - $75,000 || none || none || yes || yes || no || no || no || no || unrescrictive no
|-
| Foundation Executive Director / CEO || individual || none || 1 || none || yes || yes || additive yes || yes || unrestrictive no || no || unrescrictive no
|-
| Foundation Secretary || individual || none || 1 || none || yes || yes || additive yes || yes || unrescrictive no || no || unrescrictive no
|-
| Foundation Chief Operations Officer / COO || individual || none || 1 || none || yes || yes || additive yes || yes || unrescrictive no || no || unrescrictive no
|-
| Foundation Employee || individual || none || none || none || yes || yes || additive yes || yes || unrescrictive no || no || unrescrictive no
|-
| OpenStack Foundation || group || none || 1 || none || additive yes || no || no || no || no || no || no
|-
| Foundation Board of Directors || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation Technical committee || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation Board finance committee || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation Board transparency committee || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation Board gold member review committee || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation User Committee || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation Board Legal Affairs Committee || group || none || 1 || none || no || no || no || no || no || no || no
|}

Foundation-participation

2013-12-09T17:37:39Z

Joshua-mckenty: Adding corporate sponsors, simplifying wording.

{| class="wikitable sortable"
|-
! Rights, Responsibilities, Restrictions (more details on the [http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/ bylaws]) ([https://docs.google.com/spreadsheet/ccc?key=0Ahy1qS0O_cnldFdEcHNVdEJEN2tnTWNnZV9ZeThhZmc&usp=sharing source]) !! role !! cost !! maximum count !! election held !! can be an openstack foundation member !! can be an Active Technical Contributor (ATC) !! can be a openstack foundation employee !! vote in individual board director elections !! vote in technical committee elections !! vote in gold board director elections !! vote in project elections
|-
| platinum board director || individual || none || 8 || see bylaws || yes || yes || no || unrescrictive no || unrescrictive no || no || unrescrictive no
|-
| platinum member || company || $500,000 || 8 || see bylaws || yes || yes || no || unrescrictive no || unrescrictive no || no || unrescrictive no
|-
| gold board director || individual || none || 8 || first two weeks of January || yes || yes || no || unrescrictive no || unrescrictive no || additive yes || unrescrictive no
|-
| gold member || company || $50,000-$200,000 || 24 || see bylaws || yes || yes || no || unrescrictive no || unrescrictive no || yes || unrescrictive no
|-
| corporate sponsor || company || $10,000 || none || none || yes || yes || no || unrestrictive no || unrestrictive no || unrestrictive no || unrestrictive no
|-
| individual board director || individual || none || 8 || first two weeks of January || yes || yes || yes || unrescrictive no || unrescrictive no || no || unrescrictive no
|-
| individual member || individual || none || none || none || yes || yes || yes || unrescrictive no || unrescrictive no || no || unrescrictive no
|-
| technical committee member || individual || none || none || staggered every 6 months || yes || yes || yes || additive yes || additive yes || no || if a project ATC, additive yes
|-
| project technical lead (PTL) || individual || none || 1 || any project ATC || additive yes || additive yes || yes || additive yes || additive yes || no || if a project ATC, additive yes
|-
| project core reviewer || individual || none || none || none || additive yes || additive yes || yes || additive yes || additive yes || no || if a project ATC, additive yes
|-
| project reviewer* || individual || none || none || none || additive yes || additive yes || yes || additive yes || additive yes || no || if a project ATC, additive yes
|-
| project active technical contributor (ATC) || || none || || none || additive yes || additive yes || yes || additive yes || additive yes || no || additive yes
|-
| active technical contributor (ATC) || individual || none || none || none || additive yes || additive yes || yes || additive yes || additive yes || no || if a project ATC, additive yes
|-
| summit sponsor || company || $7,500 - $75,000 || none || none || yes || yes || no || no || no || no || unrescrictive no
|-
| Foundation Executive Director / CEO || individual || none || 1 || none || yes || yes || additive yes || yes || unrestrictive no || no || unrescrictive no
|-
| Foundation Secretary || individual || none || 1 || none || yes || yes || additive yes || yes || unrescrictive no || no || unrescrictive no
|-
| Foundation Chief Operations Officer / COO || individual || none || 1 || none || yes || yes || additive yes || yes || unrescrictive no || no || unrescrictive no
|-
| Foundation Employee || individual || none || none || none || yes || yes || additive yes || yes || unrescrictive no || no || unrescrictive no
|-
| OpenStack Foundation || group || none || 1 || none || additive yes || no || no || no || no || no || no
|-
| Foundation Board of Directors || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation Technical committee || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation Board finance committee || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation Board transparency committee || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation Board gold member review committee || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation User Committee || group || none || 1 || none || no || no || no || no || no || no || no
|-
| Foundation Board Legal Affairs Committee || group || none || 1 || none || no || no || no || no || no || no || no
|}

Governance/CoreDefinition

2013-11-20T22:27:21Z

Joshua-mckenty: /* Implementation */

== Objective ==
The following list represents the "guiding principles" used by the Foundation Board to determine how commercial implementations of OpenStack can be granted use of the trademark. They will continue to get refined over the next 6 months as the to-be-renamed-Core-Definition Committee refines the must-pass test selection process and governance. They committee may suggest changes to the by-laws to clarify the definition of core.

: Principles Adopted at Oct 4th 2013 Board Meeting

== Implementation ==
* The [[Governance/DefCoreCommittee]] is working to manage this.
* Meetings and agendas will be posted to that page, hosted on Google Hangouts and (generally) open to the community.
* Meeting participants will be expected to commit to the full set of meetings, be familiar with the Spider process materials, and up-to-date on the committee resolutions to date.
* Havana must-pass tests approved by Ice House Release
* Ice House must-pass tests approved by Ice House Release +90

== Principles ==
[[File:Core flow.png|500px|thumb|right]]

# Implementations that are Core can use OpenStack trademark (OpenStack™)
## This is the legal definition of “core” and the why it matters to the community.
## We want to make sure that the OpenStack™ mark means something.
## The OpenStack™ mark is not the same as the OpenStack brand; however, the Board uses it’s control of the mark as a proxy to help manage the brand.
# Core is a subset of the whole project
## The OpenStack project is supposed to be a broad and diverse community with new projects entering incubation and new implementations being constantly added. This innovation is vital to OpenStack but separate from the definition of Core.
## There may be other marks that are managed separately by the foundation, and available for the platform ecosystem as per the Board’s discretion
## “OpenStack API Compatible ” mark not part of this discussion and should be not be assumed.
# Core definition can be applied equally to all usage models
## There should not be multiple definitions of OpenStack depending on the operator (public, private, community, etc)
## While expected that each deployment is identical, the differences must be quantifiable
# Claiming OpenStack requiring use of designated upstream code
## Implementation’s claiming the OpenStack™ mark must use the OpenStack upstream code (or be using code submitted to upstream)
## You are not OpenStack, if you pass all the tests but do not use the API framework
## This prevents people from using the API without joining the community
## This also surfaces bit-rot in alternate implementations to the larger community
## This behavior improves interoperability because there is more shared code between implementation
# Projects must have an open reference implementation
## OpenStack will require an open source reference base plug-in implementation for projects (if not part of OpenStack, license model for reference plug-in must be compatible).
## Definition of a plug-in: alternate backend implementations with a common API framework that uses common _code_ to implement the API
## This expects that projects (where technically feasible) are expected to implement a plug-in or extension architecture.
## This is already in place for several projects and addresses around ecosystem support, enabling innovation
## Reference plug-ins are, by definition, the complete capability set. It is not acceptable to have “core” features that are not functional in the reference plug-in
## This will enable alternate implementations to offer innovative or differentiated features without forcing changes to the reference plug-in implementation
## This will enable the reference to expand without forcing other alternate implementations to match all features and recertify
# Vendors may substitute alternate implementations
## If a vendor plug-in passes all relevant tests then it can be considered a full substitute for the reference plug-in
## If a vendor plug-in does NOT pass all relevant test then the vendor is required to include the open source reference in the implementation.
## Alternate implementations may pass any tests that make sense
## Alternate implementations should add tests to validate new functionality.
## They must have all the must-pass tests (see #10) to claim the OpenStack mark.
## OpenStack Implementations are verified by open community tests
## Vendor OpenStack implementations must achieve 100% of must-have coverage?
## Implemented tests can be flagged as may-have requires list [Joshua McKenty]
## Certifiers will be required to disclose their testing gaps.
## This will put a lot of pressure on the Tempest project
## Maintenance of the testing suite to become a core Foundation responsibility. This may require additional resources
## Implementations and products are allowed to have variation based on publication of compatibility
## Consumers must have a way to determine how the system is different from reference (posted, discovered, etc)
## Testing must respond in an appropriate way on BOTH pass and fail (the wrong return rejects the entire suite)
# Tests can be remotely or self-administered
## Plug-in certification is driven by Tempest self-certification model
## Self-certifiers are required to publish their results
## Self-certified are required to publish enough information that a 3rd party could build the reference implementation to pass the tests.
## Self-certified must include the operating systems that have been certified
## It is preferred for self-certified implementation to reference an OpenStack reference architecture “flavor” instead of defining their own reference. (a way to publish and agree on flavors is needed)
## The Foundation needs to define a mechanism of dispute resolution. (A trust but verify model)
## As an ecosystem partner, you have a need to make a “works against OpenStack” statement that is supportable
## API consumer can claim working against the OpenStack API if it works against any implementation passing all the “must have” tests(YES)
## API consumers can state they are working against the OpenStack API with some “may have” items as requirements
## API consumers are expected to write tests that validate their required behaviors (submitted as “may have” tests)
# A subset of tests are chosen by the Foundation as “must-pass”
## An OpenStack body will recommend which tests are elevated from may-have to must-have
## The selection of “must-pass” tests should be based on quantifiable information when possible.
## Must-pass tests should be selected from the existing body of “may-pass” tests. This encourages people to write tests for cases they want supported.
## We will have a process by which tests are elevated from may to must lists
## Potentially: the User Committee will nominate tests that elevated to the board
## OpenStack Core means passing all “must-pass” tests
# The OpenStack board owns the responsibility to define ‘core’ – to approve ‘musts’
## The "CoreDef" committee will submit the must-pass tests to the board as a block and passed as a single motion
## We are NOT defining which items are on the list in this effort, just making the position that it is how we will define core
## May-have tests include items in the integrated release, but which are not core.
## Must haves – must comply with the Core criteria defined from the IncUp committee results
## Projects in Incubation or pre-Incubation are not to be included in the ‘may’ list
# OpenStack Core means passing all “must-pass” tests
## The OpenStack board owns the responsibility to define ‘core’ – to approve ‘musts’
## We are NOT defining which items are on the list in this effort, just making the position that it is how we will define core
## May-have tests include items in the integrated release, but which are not core.
## Must haves – must comply with the Core criteria defined from the IncUp committee results
## Projects in Incubation or pre-Incubation are not to be included in the ‘may’ list

Governance/CoreDefinition

2013-11-20T22:26:15Z

Joshua-mckenty: /* Implementation */

== Objective ==
The following list represents the "guiding principles" used by the Foundation Board to determine how commercial implementations of OpenStack can be granted use of the trademark. They will continue to get refined over the next 6 months as the to-be-renamed-Core-Definition Committee refines the must-pass test selection process and governance. They committee may suggest changes to the by-laws to clarify the definition of core.

: Principles Adopted at Oct 4th 2013 Board Meeting

== Implementation ==
* The [[DefCoreCommittee]] is working to manage this.
* Meetings and agendas will be posted to that page, hosted on Google Hangouts and (generally) open to the community.
* Meeting participants will be expected to commit to the full set of meetings, be familiar with the Spider process materials, and up-to-date on the committee resolutions to date.
* Havana must-pass tests approved by Ice House Release
* Ice House must-pass tests approved by Ice House Release +90

== Principles ==
[[File:Core flow.png|500px|thumb|right]]

# Implementations that are Core can use OpenStack trademark (OpenStack™)
## This is the legal definition of “core” and the why it matters to the community.
## We want to make sure that the OpenStack™ mark means something.
## The OpenStack™ mark is not the same as the OpenStack brand; however, the Board uses it’s control of the mark as a proxy to help manage the brand.
# Core is a subset of the whole project
## The OpenStack project is supposed to be a broad and diverse community with new projects entering incubation and new implementations being constantly added. This innovation is vital to OpenStack but separate from the definition of Core.
## There may be other marks that are managed separately by the foundation, and available for the platform ecosystem as per the Board’s discretion
## “OpenStack API Compatible ” mark not part of this discussion and should be not be assumed.
# Core definition can be applied equally to all usage models
## There should not be multiple definitions of OpenStack depending on the operator (public, private, community, etc)
## While expected that each deployment is identical, the differences must be quantifiable
# Claiming OpenStack requiring use of designated upstream code
## Implementation’s claiming the OpenStack™ mark must use the OpenStack upstream code (or be using code submitted to upstream)
## You are not OpenStack, if you pass all the tests but do not use the API framework
## This prevents people from using the API without joining the community
## This also surfaces bit-rot in alternate implementations to the larger community
## This behavior improves interoperability because there is more shared code between implementation
# Projects must have an open reference implementation
## OpenStack will require an open source reference base plug-in implementation for projects (if not part of OpenStack, license model for reference plug-in must be compatible).
## Definition of a plug-in: alternate backend implementations with a common API framework that uses common _code_ to implement the API
## This expects that projects (where technically feasible) are expected to implement a plug-in or extension architecture.
## This is already in place for several projects and addresses around ecosystem support, enabling innovation
## Reference plug-ins are, by definition, the complete capability set. It is not acceptable to have “core” features that are not functional in the reference plug-in
## This will enable alternate implementations to offer innovative or differentiated features without forcing changes to the reference plug-in implementation
## This will enable the reference to expand without forcing other alternate implementations to match all features and recertify
# Vendors may substitute alternate implementations
## If a vendor plug-in passes all relevant tests then it can be considered a full substitute for the reference plug-in
## If a vendor plug-in does NOT pass all relevant test then the vendor is required to include the open source reference in the implementation.
## Alternate implementations may pass any tests that make sense
## Alternate implementations should add tests to validate new functionality.
## They must have all the must-pass tests (see #10) to claim the OpenStack mark.
## OpenStack Implementations are verified by open community tests
## Vendor OpenStack implementations must achieve 100% of must-have coverage?
## Implemented tests can be flagged as may-have requires list [Joshua McKenty]
## Certifiers will be required to disclose their testing gaps.
## This will put a lot of pressure on the Tempest project
## Maintenance of the testing suite to become a core Foundation responsibility. This may require additional resources
## Implementations and products are allowed to have variation based on publication of compatibility
## Consumers must have a way to determine how the system is different from reference (posted, discovered, etc)
## Testing must respond in an appropriate way on BOTH pass and fail (the wrong return rejects the entire suite)
# Tests can be remotely or self-administered
## Plug-in certification is driven by Tempest self-certification model
## Self-certifiers are required to publish their results
## Self-certified are required to publish enough information that a 3rd party could build the reference implementation to pass the tests.
## Self-certified must include the operating systems that have been certified
## It is preferred for self-certified implementation to reference an OpenStack reference architecture “flavor” instead of defining their own reference. (a way to publish and agree on flavors is needed)
## The Foundation needs to define a mechanism of dispute resolution. (A trust but verify model)
## As an ecosystem partner, you have a need to make a “works against OpenStack” statement that is supportable
## API consumer can claim working against the OpenStack API if it works against any implementation passing all the “must have” tests(YES)
## API consumers can state they are working against the OpenStack API with some “may have” items as requirements
## API consumers are expected to write tests that validate their required behaviors (submitted as “may have” tests)
# A subset of tests are chosen by the Foundation as “must-pass”
## An OpenStack body will recommend which tests are elevated from may-have to must-have
## The selection of “must-pass” tests should be based on quantifiable information when possible.
## Must-pass tests should be selected from the existing body of “may-pass” tests. This encourages people to write tests for cases they want supported.
## We will have a process by which tests are elevated from may to must lists
## Potentially: the User Committee will nominate tests that elevated to the board
## OpenStack Core means passing all “must-pass” tests
# The OpenStack board owns the responsibility to define ‘core’ – to approve ‘musts’
## The "CoreDef" committee will submit the must-pass tests to the board as a block and passed as a single motion
## We are NOT defining which items are on the list in this effort, just making the position that it is how we will define core
## May-have tests include items in the integrated release, but which are not core.
## Must haves – must comply with the Core criteria defined from the IncUp committee results
## Projects in Incubation or pre-Incubation are not to be included in the ‘may’ list
# OpenStack Core means passing all “must-pass” tests
## The OpenStack board owns the responsibility to define ‘core’ – to approve ‘musts’
## We are NOT defining which items are on the list in this effort, just making the position that it is how we will define core
## May-have tests include items in the integrated release, but which are not core.
## Must haves – must comply with the Core criteria defined from the IncUp committee results
## Projects in Incubation or pre-Incubation are not to be included in the ‘may’ list

Governance/CoreDefinition

2013-11-20T22:25:49Z

Joshua-mckenty: Linking to DefCoreCommittee homepage.

== Objective ==
The following list represents the "guiding principles" used by the Foundation Board to determine how commercial implementations of OpenStack can be granted use of the trademark. They will continue to get refined over the next 6 months as the to-be-renamed-Core-Definition Committee refines the must-pass test selection process and governance. They committee may suggest changes to the by-laws to clarify the definition of core.

: Principles Adopted at Oct 4th 2013 Board Meeting

== Implementation ==
* The DefCoreCommittee is working to manage this.
* Meetings and agendas will be posted to that page, hosted on Google Hangouts and (generally) open to the community.
* Meeting participants will be expected to commit to the full set of meetings, be familiar with the Spider process materials, and up-to-date on the committee resolutions to date.
* Havana must-pass tests approved by Ice House Release
* Ice House must-pass tests approved by Ice House Release +90

== Principles ==
[[File:Core flow.png|500px|thumb|right]]

# Implementations that are Core can use OpenStack trademark (OpenStack™)
## This is the legal definition of “core” and the why it matters to the community.
## We want to make sure that the OpenStack™ mark means something.
## The OpenStack™ mark is not the same as the OpenStack brand; however, the Board uses it’s control of the mark as a proxy to help manage the brand.
# Core is a subset of the whole project
## The OpenStack project is supposed to be a broad and diverse community with new projects entering incubation and new implementations being constantly added. This innovation is vital to OpenStack but separate from the definition of Core.
## There may be other marks that are managed separately by the foundation, and available for the platform ecosystem as per the Board’s discretion
## “OpenStack API Compatible ” mark not part of this discussion and should be not be assumed.
# Core definition can be applied equally to all usage models
## There should not be multiple definitions of OpenStack depending on the operator (public, private, community, etc)
## While expected that each deployment is identical, the differences must be quantifiable
# Claiming OpenStack requiring use of designated upstream code
## Implementation’s claiming the OpenStack™ mark must use the OpenStack upstream code (or be using code submitted to upstream)
## You are not OpenStack, if you pass all the tests but do not use the API framework
## This prevents people from using the API without joining the community
## This also surfaces bit-rot in alternate implementations to the larger community
## This behavior improves interoperability because there is more shared code between implementation
# Projects must have an open reference implementation
## OpenStack will require an open source reference base plug-in implementation for projects (if not part of OpenStack, license model for reference plug-in must be compatible).
## Definition of a plug-in: alternate backend implementations with a common API framework that uses common _code_ to implement the API
## This expects that projects (where technically feasible) are expected to implement a plug-in or extension architecture.
## This is already in place for several projects and addresses around ecosystem support, enabling innovation
## Reference plug-ins are, by definition, the complete capability set. It is not acceptable to have “core” features that are not functional in the reference plug-in
## This will enable alternate implementations to offer innovative or differentiated features without forcing changes to the reference plug-in implementation
## This will enable the reference to expand without forcing other alternate implementations to match all features and recertify
# Vendors may substitute alternate implementations
## If a vendor plug-in passes all relevant tests then it can be considered a full substitute for the reference plug-in
## If a vendor plug-in does NOT pass all relevant test then the vendor is required to include the open source reference in the implementation.
## Alternate implementations may pass any tests that make sense
## Alternate implementations should add tests to validate new functionality.
## They must have all the must-pass tests (see #10) to claim the OpenStack mark.
## OpenStack Implementations are verified by open community tests
## Vendor OpenStack implementations must achieve 100% of must-have coverage?
## Implemented tests can be flagged as may-have requires list [Joshua McKenty]
## Certifiers will be required to disclose their testing gaps.
## This will put a lot of pressure on the Tempest project
## Maintenance of the testing suite to become a core Foundation responsibility. This may require additional resources
## Implementations and products are allowed to have variation based on publication of compatibility
## Consumers must have a way to determine how the system is different from reference (posted, discovered, etc)
## Testing must respond in an appropriate way on BOTH pass and fail (the wrong return rejects the entire suite)
# Tests can be remotely or self-administered
## Plug-in certification is driven by Tempest self-certification model
## Self-certifiers are required to publish their results
## Self-certified are required to publish enough information that a 3rd party could build the reference implementation to pass the tests.
## Self-certified must include the operating systems that have been certified
## It is preferred for self-certified implementation to reference an OpenStack reference architecture “flavor” instead of defining their own reference. (a way to publish and agree on flavors is needed)
## The Foundation needs to define a mechanism of dispute resolution. (A trust but verify model)
## As an ecosystem partner, you have a need to make a “works against OpenStack” statement that is supportable
## API consumer can claim working against the OpenStack API if it works against any implementation passing all the “must have” tests(YES)
## API consumers can state they are working against the OpenStack API with some “may have” items as requirements
## API consumers are expected to write tests that validate their required behaviors (submitted as “may have” tests)
# A subset of tests are chosen by the Foundation as “must-pass”
## An OpenStack body will recommend which tests are elevated from may-have to must-have
## The selection of “must-pass” tests should be based on quantifiable information when possible.
## Must-pass tests should be selected from the existing body of “may-pass” tests. This encourages people to write tests for cases they want supported.
## We will have a process by which tests are elevated from may to must lists
## Potentially: the User Committee will nominate tests that elevated to the board
## OpenStack Core means passing all “must-pass” tests
# The OpenStack board owns the responsibility to define ‘core’ – to approve ‘musts’
## The "CoreDef" committee will submit the must-pass tests to the board as a block and passed as a single motion
## We are NOT defining which items are on the list in this effort, just making the position that it is how we will define core
## May-have tests include items in the integrated release, but which are not core.
## Must haves – must comply with the Core criteria defined from the IncUp committee results
## Projects in Incubation or pre-Incubation are not to be included in the ‘may’ list
# OpenStack Core means passing all “must-pass” tests
## The OpenStack board owns the responsibility to define ‘core’ – to approve ‘musts’
## We are NOT defining which items are on the list in this effort, just making the position that it is how we will define core
## May-have tests include items in the integrated release, but which are not core.
## Must haves – must comply with the Core criteria defined from the IncUp committee results
## Projects in Incubation or pre-Incubation are not to be included in the ‘may’ list

Governance/Foundation/TransparencyCommittee

2013-10-27T19:54:26Z

Joshua-mckenty: /* Published Materials */

= Transparency Working Group =

The transparency working group is a sub-committee of the [[Governance/Foundation|Foundation]] Board of Directors formed to consider issues related to transparency of community governance. The committee was created in the February 12, 2013 meeting ([[Governance/Foundation/12Feb2013BoardMinutes|Minutes]]).

== Members ==

* Joshua McKenty
* Lauren Sell
* Kyle MacDonald
* Alan Clark
* Eileen Evans
* Jonathan Bryce
* Mark McLoughlin
* Nick Barcet
* Rob Hirschfeld
* Tristan Goode

== Published Materials ==

* https://docs.google.com/document/d/1sGBtza-mjRXcDzFBSS9aUrYlAtu1se-eerHZN16DPyU/edit?disco=AAAAAGHicDU
* https://etherpad.openstack.org/p/TransparencyWG-Feb21-Agenda
* https://etherpad.openstack.org/p/TransparencyWG-April14-Update
* https://etherpad.openstack.org/p/TransparencyPolicy

== Meetings ==

http://lists.openstack.org/pipermail/transparency/2013-February/000002.html

== transparency-committee Mailing List ==

The [http://lists.openstack.org/cgi-bin/mailman/listinfo/transparency transparency@lists.openstack.org] mailing list is the public mailing list the committee uses for its discussions.

Governance/Foundation/TransparencyCommittee

2013-10-27T19:52:54Z

Joshua-mckenty: First draft.

= Transparency Working Group =

The transparency working group is a sub-committee of the [[Governance/Foundation|Foundation]] Board of Directors formed to consider issues related to transparency of community governance. The committee was created in the February 12, 2013 meeting ([[Governance/Foundation/12Feb2013BoardMinutes|Minutes]]).

== Members ==

* Joshua McKenty
* Lauren Sell
* Kyle MacDonald
* Alan Clark
* Eileen Evans
* Jonathan Bryce
* Mark McLoughlin
* Nick Barcet
* Rob Hirschfeld
* Tristan Goode

== Published Materials ==

https://docs.google.com/document/d/1sGBtza-mjRXcDzFBSS9aUrYlAtu1se-eerHZN16DPyU/edit?disco=AAAAAGHicDU
https://etherpad.openstack.org/p/TransparencyWG-Feb21-Agenda
https://etherpad.openstack.org/p/TransparencyWG-April14-Update
https://etherpad.openstack.org/p/TransparencyPolicy

== Meetings ==

http://lists.openstack.org/pipermail/transparency/2013-February/000002.html

== transparency-committee Mailing List ==

The [http://lists.openstack.org/cgi-bin/mailman/listinfo/transparency transparency@lists.openstack.org] mailing list is the public mailing list the committee uses for its discussions.

Governance/Foundation

2013-10-27T19:43:52Z

Joshua-mckenty: /* Committees */

== OpenStack Foundation ==
Documents

* [[Governance/Foundation/Mission|Foundation Mission]]
* [[Governance/Foundation/Structure|Foundation Structure]]
* [[Governance/Foundation/Funding|Foundation Funding]]
* [[Governance/Foundation/Bylaws|Foundation Bylaws]]
* [[Governance/Foundation/TechnicalCommittee|Technical Committee]]
* [[Governance/Foundation/UserCommittee|User Committee]]
* [[Governance/Foundation/PotentialMemberCriteria|Potential Gold and Platinum Member Criteria]]
* [http://www.openstack.org/foundation/board-of-directors/ OpenStack Board Directors]

== OpenStack Board of Director Meetings ==
* 2013
** [[Governance/Foundation/31Jan2013BoardMeeting|January 31, 2013 Board Meeting Agenda]] ([[Governance/Foundation/31Jan2013BoardMinutes|Official Minutes]])
** [[Governance/Foundation/12Feb2013BoardMeeting|February 12, 2013 Board Meeting Agenda]]([[Governance/Foundation/12Feb2013BoardMinutes|Official Minutes]])
** [[Governance/Foundation/14Apr2013BoardMeeting|April 14, 2013 Board Meeting Agenda]]([[Governance/Foundation/14Apr2013BoardMinutes|Official Minutes]])
** [[Governance/Foundation/30May2013BoardMeeting|May 30, 2013 Board Meeting Agenda]]([[Governance/Foundation/30May2013BoardMinutes|Official Minutes]])
** [[Governance/Foundation/27June2013BoardMeeting|June 27, 2013 Board Meeting Agenda]]([[Governance/Foundation/27June2013BoardMinutes|Official Minutes]])
** [[Governance/Foundation/6Aug2013BoardMeeting|August 6, 2013 Board Meeting Agenda]]([[Governance/Foundation/6Aug2013BoardMinutes|Official Minutes]])
** [[Governance/Foundation/3Oct2013BoardMeeting|October 3, 2013 Board Meeting Agenda]]([[Governance/Foundation/3Oct2013BoardMinutes|Official Minutes]])
** [[Governance/Foundation/17Oct2013BoardMeeting|October 17, 2013 Board Meeting Agenda]]([[Governance/Foundation/3Oct2013BoardMinutes|Official Minutes]])
** [[Governance/Foundation/4Nov2013BoardMeeting|November 4, 2013 Board Meeting Agenda]]([[Governance/Foundation/4Nov2013BoardMinutes|Official Minutes]])

* 2012
** [[Governance/Foundation/Aug2012BoardAgenda|August 28, 2012, First Board Meeting]] ([[Governance/Foundation/Aug2012BoardMinutes|Official Minutes]])
** [[Governance/Foundation/07Sept2012BoardMeeting|September 7, 2012 Meeting]] ([[Governance/Foundation/07Sept2012BoardMinutes|Official Minutes]])
** [[Governance/Foundation/18Sept2012BoardMeeting|September 18, 2012 Meeting]] ([[Governance/Foundation/18Sept2012BoardMinutes|Official Minutes]])
** [[Governance/Foundation/15Oct2012BoardMeeting|October 15, 2012 Meeting]] ([[Governance/Foundation/15Oct2012BoardMinutes|Official Minutes]])
** [[Governance/Foundation/02Nov2012BoardMeeting|November 2, 2012 Meeting]] ([[Governance/Foundation/02Nov2012BoardMinutes|Official Minutes]])
** [[Governance/Foundation/16Nov2012BoardMeeting|November 16, 2012 Meeting]] ([[Governance/Foundation/16Nov2012BoardMinutes|Official Minutes]])

== Committees ==
* [[Governance/Foundation/IncubationUpdate2013|Incubation Process Update Committee]]
* [[Governance/Foundation/LegalAffairsCommittee|Legal Affairs Committee]]
* [[Governance/Foundation/TransparencyCommittee|Transparency Committee]]
* [[Governance/Foundation/ElectionsCommittee|Elections Committee]]

== 2013 Board Meeting Schedule ==
* January 31, 2013 Conference Call, 9am - 11am pacific (First Board meeting post elections)
* February 12, 2013, San Francisco, [[InPerson]] F2F meeting, 10am - 5pm pacific (Board dinner Feb 12 6pm, location TBD)
* March 12, 2013 Conference Call, 9am - 11am pacific - Meeting not to be held in lieu of April 14 meeting
* April 14, 2013, Portland Oregon, inPerson F2F, 9am - 5pm pacific (Board dinner April 14, 6pm -10pm pacific, Location: Hilton, Galleria South meeting room, Portland Oregon)
* May 30, 2013 Conference Call, 9am - 11am pacific
* August 6, 2013 Conference Call, 9am - 11am pacific
* October 3, 2013 Conference Call 9am - 11am pacific
* November 4, 2013 [[InPerson]] F2F meeting at the OpenStack Summit

== Community Marketing & Events ==
* [[Governance/Foundation/Marketing|Marketing & Events Overview]]

Get OpenStack

2013-05-09T22:14:14Z

Joshua-mckenty:

= How to get OpenStack =

OpenStack is a large and fast moving project. We are also an upstream
project, with a large community of packagers and distributions who
redistribute our work.

The best way to install OpenStack is to rely on one of the downstream
distributions, which will take care of many of the details for you.
There are also source code installers oriented towards developers.

Also, you don't have to install OpenStack - there are Cloud services
that can provide OpenStack, without ever installing the software.

The current release of OpenStack is [[ReleaseNotes/Grizzly|2013.1 Grizzly]]

== Get the source code ==
* [https://launchpad.net/nova/grizzly/2013.1/+download/nova-2013.1.tar.gz Openstack Compute] ([https://launchpad.net/nova/grizzly/2013.1/+download/nova-2013.1.tar.gz/+md5 md5],[https://launchpad.net/nova/grizzly/2013.1/+download/nova-2013.1.tar.gz.asc sig])
* [https://launchpad.net/swift/grizzly/1.8.0/+download/swift-1.8.0.tar.gz OpenStack Object Storage] ([https://launchpad.net/swift/grizzly/1.8.0/+download/swift-1.8.0.tar.gz/+md5 md5],[https://launchpad.net/swift/grizzly/1.8.0/+download/swift-1.8.0.tar.gz.asc sig])
* [https://launchpad.net/glance/grizzly/2013.1/+download/glance-2013.1.tar.gz OpenStack Image Service] ([https://launchpad.net/glance/grizzly/2013.1/+download/glance-2013.1.tar.gz/+md5 md5],[https://launchpad.net/glance/grizzly/2013.1/+download/glance-2013.1.tar.gz.asc sig])
* [https://launchpad.net/quantum/grizzly/2013.1/+download/quantum-2013.1.tar.gz OpenStack Networking] ([https://launchpad.net/quantum/grizzly/2013.1/+download/quantum-2013.1.tar.gz/+md5 md5],[https://launchpad.net/quantum/grizzly/2013.1/+download/quantum-2013.1.tar.gz.asc sig])
* [https://launchpad.net/cinder/grizzly/2013.1/+download/cinder-2013.1.tar.gz OpenStack Block Storage] ([https://launchpad.net/cinder/grizzly/2013.1/+download/cinder-2013.1.tar.gz/+md5 md5],[https://launchpad.net/cinder/grizzly/2013.1/+download/cinder-2013.1.tar.gz.asc sig])
* [https://launchpad.net/keystone/grizzly/2013.1/+download/keystone-2013.1.tar.gz OpenStack Identity] ([https://launchpad.net/keystone/grizzly/2013.1/+download/keystone-2013.1.tar.gz/+md5 md5],[https://launchpad.net/keystone/grizzly/2013.1/+download/keystone-2013.1.tar.gz.asc sig])
* [https://launchpad.net/horizon/grizzly/2013.1/+download/horizon-2013.1.tar.gz OpenStack Dashboard] ([https://launchpad.net/horizon/grizzly/2013.1/+download/horizon-2013.1.tar.gz/+md5 md5],[https://launchpad.net/horizon/grizzly/2013.1/+download/horizon-2013.1.tar.gz.asc sig])

== Linux Distributions Including OpenStack ==

OpenStack is available for all major Linux Distributions.

=== Debian GNU/Linux wheezy ===

All core OpenStack Essex components are officially supported and
available in the Main wheezy archive:

* [http://packages.qa.debian.org/n/nova.html Nova]
* [http://packages.qa.debian.org/g/glance.html Glance]
* [http://packages.qa.debian.org/s/swift.html Swift]
* [http://packages.qa.debian.org/k/keystone.html Keystone]
* [http://packages.qa.debian.org/h/horizon.html Horizon]
* [http://packages.qa.debian.org/q/quantum.html Quantum]
* [http://packages.qa.debian.org/m/melange.html Melange]

Essex can be deployed with [http://wiki.debian.org/OpenStackHowto a HOWTO] and
[https://github.com/puppetlabs/puppetlabs-openstack puppet modules].

More details about Debian packaging can be found on the [[Packaging/Debian]] wiki page.

=== Fedora 17 / Fedora 16 / EPEL 6 ===

* Fedora 17 (May 2012) will ship with OpenStack Essex
* The [http://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux] repository supporting RHEL >= 6.2 and derivatives will update from Diablo to Essex
* You can get Fedora/EPEL OpenStack package details at https://apps.fedoraproject.org/packages/s/openstack
* [http://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17 Install/Setup notes for Essex]
* [http://repos.fedorapeople.org/repos/apevec/openstack-preview/fedora-16/noarch/ An unofficial Essex repository for Fedora 16 ]

More details about Fedora-based packages can be found on the [[Packaging/Fedora]] and [[Packaging/RHEL]] wiki pages.

=== openSUSE / SLES11 SP2 ===

Packages of OpenStack Folsom are available:

https://build.opensuse.org/project/show?project=isv%3AB1-Systems%3AOpenStack%3Arelease%3AFolsom

You can find all details about the repositories for openSUSE 12.2 and SLES11 SP2 on our
packaging site in the wiki: [[Packaging/SUSE]]

=== Ubuntu 12.04 LTS (Precise Pangolin) ===

All core OpenStack Essex components are officially supported and available in the Main Precise Ubuntu archive:

* [https://launchpad.net/ubuntu/+source/nova Nova]
* [https://launchpad.net/ubuntu/+source/glance Glance]
* [https://launchpad.net/ubuntu/+source/swift Swift]
* [https://launchpad.net/ubuntu/+source/keystone Keystone]
* [https://launchpad.net/ubuntu/+source/horizon Horizon]

Note: Horizon and Keystone are currently located in Universe as they undergo
a security review before promotion to Main for the 12.04 Precise release (April 26th 2012)-~

Incubated projects Quantum and Melange are available for Precise in Universe

* [https://launchpad.net/ubuntu/+source/quantum Quantum]
* [https://launchpad.net/ubuntu/+source/melange Melange]

Essex can be deployed on Ubuntu Server using MAAS and Juju.

Martin Loschwitz has written a wonderful step-by-step guide for manually
[http://www.hastexo.com/resources/docs/installing-openstack-essex-4-ubuntu-1204-precise-pangolin installing Essex on Ubuntu 12.04]

More details about Ubuntu packages can be found on the [[Packaging/Ubuntu]] wiki page.

== [[DevOps]] Installers ==

For those that deploy rather than install, there are several DevOps options for automating your installation of OpenStack.

=== Chef ===

See Opscode's [http://www.opscode.com/openstack/ Welcome to Chef for OpenStack] for a starting point.

There are multiple [http://opscode.com/chef Chef] cookbooks.

* Matt Ray from Opscode maintains a set of OpenStack cookbooks on github at [https://github.com/mattray/openstack-cookbooks mattray/openstack-cookbooks]
* Rackspace Cloud Builders maintain a set of repositories with openstack-related chef cookbooks on github at [https://github.com/rcbops/chef-cookbooks rcbops/chef-cookbooks]
* [http://www.dell.com/crowbar Dell Crowbar] is an OpenStack deployment solution built on top of Chef. They maintain their Chef recipes on github at [https://github.com/dellcloudedge/crowbar dellcouldedge/crowbar]

=== Puppet ===

* Puppet Labs maintains a set of puppet modules for OpenStack at [http://github.com/puppetlabs/puppetlabs-openstack puppetlabs/puppetlabs-openstack].
* NII developed a Puppet-based tool called [https://github.com/nii-cloud/dodai-deploy/wiki dodai-deploy]. It is available for download on github at [https://github.com/nii-cloud/dodai-deploy nii-cloud/dodai-deploy]. Documentation for dodai-deploy can be found on the wiki at its github site, as well as in the [http://docs.openstack.org/trunk/openstack-compute/admin/content/openstack-compute-deployment-tool-with-puppet.html OpenStack Compute admin guide].

=== Juju ===

* Canonical maintains a collection of [http://juju.ubuntu.com Juju] charms for OpenStack, see the [http://jujucharms.com/charms Juju charm browser].

== Developer Installers ==

For developers, there are installers that create a core development
environment.

* [http://devstack.org/ Devstack] is the developer installer.
* [https://github.com/yahoo/Openstack-Anvil ANVIL] is version of devstack, written in Python.

== OpenStack as a Service ==

* [http://trystack.org/ TryStack] is an easy way to try OpenStack.
* [http://www.rackspace.com/cloud/ RackSpace Cloud] is powered by OpenStack
* [http://hpcloud.com/ HPCloud] is powered by OpenStack

== Commercial Distributions ==

* [http://www.pistoncloud.com/download/ Piston Cloud Computing] offers a free trial of their Piston Enterprise OpenStack product.
* [http://www.nebula.com/ Nebula] is developing an OpenStack appliance.
* [http://www.stackops.com/ StackOps] provides [[StackOps]] Enterprise Edition for IT Professionals, Hosters and Services Providers. It also offers a free version for small Private Clouds and Testing Labs [http://docs.stackops.org/display/STACKOPSDOCS/Home/ StackOps Community Edition].

== Miscellaneous Notes ==

If you're a packager looking for packaging tips, see [[PackagerResources]].

For Quantum, see [[QuantumPackages]].

----
[[Category:HowTo]]
[[Category:Installation]]

Get OpenStack

2013-05-09T22:12:20Z

Joshua-mckenty:

= How to get OpenStack =

OpenStack is a large and fast moving project. We are also an upstream
project, with a large community of packagers and distributions who
redistribute our work.

The best way to install OpenStack is to rely on one of the downstream
distributions, which will take care of many of the details for you.
There are also source code installers oriented towards developers.

Also, you don't have to install OpenStack - there are Cloud services
that can provide OpenStack, without ever installing the software.

The current release of OpenStack is [[ReleaseNotes/Grizzly|2013.1 Grizzly]]

== Get the source code ==
* [https://launchpad.net/nova/grizzly/2013.1/+download/nova-2013.1.tar.gz Openstack Compute] ([https://launchpad.net/nova/grizzly/2013.1/+download/nova-2013.1.tar.gz/+md5 md5],[https://launchpad.net/nova/grizzly/2013.1/+download/nova-2013.1.tar.gz.asc sig])
* [https://launchpad.net/swift/grizzly/1.8.0/+download/swift-1.8.0.tar.gz OpenStack Object Storage] ([https://launchpad.net/swift/grizzly/1.8.0/+download/swift-1.8.0.tar.gz/+md5 md5],[https://launchpad.net/swift/grizzly/1.8.0/+download/swift-1.8.0.tar.gz.asc sig])
* [https://launchpad.net/glance/grizzly/2013.1/+download/glance-2013.1.tar.gz OpenStack Image Service] ([https://launchpad.net/glance/grizzly/2013.1/+download/glance-2013.1.tar.gz/+md5 md5],[https://launchpad.net/glance/grizzly/2013.1/+download/glance-2013.1.tar.gz.asc sig])
* [https://launchpad.net/quantum/grizzly/2013.1/+download/quantum-2013.1.tar.gz OpenStack Networking] ([https://launchpad.net/quantum/grizzly/2013.1/+download/quantum-2013.1.tar.gz/+md5 md5],[https://launchpad.net/quantum/grizzly/2013.1/+download/quantum-2013.1.tar.gz.asc sig])
* [https://launchpad.net/cinder/grizzly/2013.1/+download/cinder-2013.1.tar.gz OpenStack Block Storage] ([https://launchpad.net/cinder/grizzly/2013.1/+download/cinder-2013.1.tar.gz/+md5 md5],[https://launchpad.net/cinder/grizzly/2013.1/+download/cinder-2013.1.tar.gz.asc sig])
* [https://launchpad.net/keystone/grizzly/2013.1/+download/keystone-2013.1.tar.gz OpenStack Identity] ([https://launchpad.net/keystone/grizzly/2013.1/+download/keystone-2013.1.tar.gz/+md5 md5],[https://launchpad.net/keystone/grizzly/2013.1/+download/keystone-2013.1.tar.gz.asc sig])
* [https://launchpad.net/horizon/grizzly/2013.1/+download/horizon-2013.1.tar.gz OpenStack Dashboard] ([https://launchpad.net/horizon/grizzly/2013.1/+download/horizon-2013.1.tar.gz/+md5 md5],[https://launchpad.net/horizon/grizzly/2013.1/+download/horizon-2013.1.tar.gz.asc sig])

== Linux Distributions Including OpenStack ==

OpenStack is available for all major Linux Distributions.

=== Debian GNU/Linux wheezy ===

All core OpenStack Essex components are officially supported and
available in the Main wheezy archive:

* [http://packages.qa.debian.org/n/nova.html Nova]
* [http://packages.qa.debian.org/g/glance.html Glance]
* [http://packages.qa.debian.org/s/swift.html Swift]
* [http://packages.qa.debian.org/k/keystone.html Keystone]
* [http://packages.qa.debian.org/h/horizon.html Horizon]
* [http://packages.qa.debian.org/q/quantum.html Quantum]
* [http://packages.qa.debian.org/m/melange.html Melange]

Essex can be deployed with [http://wiki.debian.org/OpenStackHowto a HOWTO] and
[https://github.com/puppetlabs/puppetlabs-openstack puppet modules].

More details about Debian packaging can be found on the [[Packaging/Debian]] wiki page.

=== Fedora 17 / Fedora 16 / EPEL 6 ===

* Fedora 17 (May 2012) will ship with OpenStack Essex
* The [http://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux] repository supporting RHEL >= 6.2 and derivatives will update from Diablo to Essex
* You can get Fedora/EPEL OpenStack package details at https://apps.fedoraproject.org/packages/s/openstack
* [http://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17 Install/Setup notes for Essex]
* [http://repos.fedorapeople.org/repos/apevec/openstack-preview/fedora-16/noarch/ An unofficial Essex repository for Fedora 16 ]

More details about Fedora-based packages can be found on the [[Packaging/Fedora]] and [[Packaging/RHEL]] wiki pages.

=== openSUSE / SLES11 SP2 ===

Packages of OpenStack Folsom are available:

https://build.opensuse.org/project/show?project=isv%3AB1-Systems%3AOpenStack%3Arelease%3AFolsom

You can find all details about the repositories for openSUSE 12.2 and SLES11 SP2 on our
packaging site in the wiki: [[Packaging/SUSE]]

=== Ubuntu 12.04 LTS (Precise Pangolin) ===

All core OpenStack Essex components are officially supported and available in the Main Precise Ubuntu archive:

* [https://launchpad.net/ubuntu/+source/nova Nova]
* [https://launchpad.net/ubuntu/+source/glance Glance]
* [https://launchpad.net/ubuntu/+source/swift Swift]
* [https://launchpad.net/ubuntu/+source/keystone Keystone]
* [https://launchpad.net/ubuntu/+source/horizon Horizon]

Note: Horizon and Keystone are currently located in Universe as they undergo
a security review before promotion to Main for the 12.04 Precise release (April 26th 2012)-~

Incubated projects Quantum and Melange are available for Precise in Universe

* [https://launchpad.net/ubuntu/+source/quantum Quantum]
* [https://launchpad.net/ubuntu/+source/melange Melange]

Essex can be deployed on Ubuntu Server using MAAS and Juju.

Martin Loschwitz has written a wonderful step-by-step guide for manually
[http://www.hastexo.com/resources/docs/installing-openstack-essex-4-ubuntu-1204-precise-pangolin installing Essex on Ubuntu 12.04]

More details about Ubuntu packages can be found on the [[Packaging/Ubuntu]] wiki page.

== [[DevOps]] Installers ==

For those that deploy rather than install, there are several DevOps options for automating your installation of OpenStack.

=== Chef ===

See Opscode's [http://www.opscode.com/openstack/ Welcome to Chef for OpenStack] for a starting point.

There are multiple [http://opscode.com/chef Chef] cookbooks.

* Matt Ray from Opscode maintains a set of OpenStack cookbooks on github at [https://github.com/mattray/openstack-cookbooks mattray/openstack-cookbooks]
* Rackspace Cloud Builders maintain a set of repositories with openstack-related chef cookbooks on github at [https://github.com/rcbops/chef-cookbooks rcbops/chef-cookbooks]
* [http://www.dell.com/crowbar Dell Crowbar] is an OpenStack deployment solution built on top of Chef. They maintain their Chef recipes on github at [https://github.com/dellcloudedge/crowbar dellcouldedge/crowbar]

=== Puppet ===

* Puppet Labs maintains a set of puppet modules for OpenStack at [http://github.com/puppetlabs/puppetlabs-openstack puppetlabs/puppetlabs-openstack].
* NII developed a Puppet-based tool called [https://github.com/nii-cloud/dodai-deploy/wiki dodai-deploy]. It is available for download on github at [https://github.com/nii-cloud/dodai-deploy nii-cloud/dodai-deploy]. Documentation for dodai-deploy can be found on the wiki at its github site, as well as in the [http://docs.openstack.org/trunk/openstack-compute/admin/content/openstack-compute-deployment-tool-with-puppet.html OpenStack Compute admin guide].

=== Juju ===

* Canonical maintains a collection of [http://juju.ubuntu.com Juju] charms for OpenStack, see the [http://jujucharms.com/charms Juju charm browser].

== Developer Installers ==

For developers, there are installers that create a core development
environment.

* [http://devstack.org/ Devstack] is the developer installer.
* [https://github.com/yahoo/Openstack-Anvil ANVIL] is version of devstack, written in Python.

== OpenStack as a Service ==

* [http://trystack.org/ TryStack] is an easy way to try OpenStack.
* [http://www.rackspace.com/cloud/ RackSpace Cloud] is powered by OpenStack
* [http://hpcloud.com/ HPCloud] is powered by OpenStack

== Commercial Distributions ==

* [http://http://www.pistoncloud.com/download/ Piston Cloud Computing] offers a free trial of their Piston Enterprise OpenStack product.
* [http://www.nebula.com/ Nebula] is developing an OpenStack appliance.
* [http://www.stackops.com/ StackOps] provides [[StackOps]] Enterprise Edition for IT Professionals, Hosters and Services Providers. It also offers a free version for small Private Clouds and Testing Labs [http://docs.stackops.org/display/STACKOPSDOCS/Home/ StackOps Community Edition].

== Miscellaneous Notes ==

If you're a packager looking for packaging tips, see [[PackagerResources]].

For Quantum, see [[QuantumPackages]].

----
[[Category:HowTo]]
[[Category:Installation]]

Contact

2013-04-14T14:18:56Z

Joshua-mckenty:

= General Help =

For any question about the OpenStack project, see:

* Our [[MailingLists|Mailing Lists]]
* Our [[IRC|IRC Channels]]
* [[StefanoMaffulli|Stefano Maffulli]], our Community Manager

If you have questions about installing, using, or contributing to OpenStack, see the https://ask.openstack.org/questions/ website.

= Wiki administrators =

You can contact [[AnneGentle|Anne Gentle]] or [[ThierryCarrez|Thierry Carrez]] with any technical question you have on the wiki.

= OpenStack Foundation =

Questions, comments and feedback about the governance of the OpenStack project can be directed to [mailto:info@openstack.org the staff of the OpenStack Foundation]. You may also find useful updates on the [http://www.openstack.org/foundation/ main foundation website.]

Contact

2013-04-14T14:16:18Z

Joshua-mckenty: Adding contact info for the foundation staff, and a link to the ask.openstack.org site.

= Contacts =

== General Help ==

For any question about the OpenStack project, see:

* Our [[MailingLists|Mailing Lists]]
* Our [[IRC|IRC Channels]]
* [[StefanoMaffulli|Stefano Maffulli]], our Community Manager

If you have questions about installing, using, or contributing to OpenStack, see the https://ask.openstack.org/questions/ website.

== Wiki administrators ==

You can contact [[AnneGentle|Anne Gentle]] or [[ThierryCarrez|Thierry Carrez]] with any technical question you have on the wiki.

== OpenStack Foundation ==

Questions, comments and feedback about the governance of the OpenStack project can be directed to [mailto:info@openstack.org the staff of the OpenStack Foundation].

Nova/APIFeatureComparison

2013-03-24T21:01:34Z

Joshua-mckenty:

= EC2 API Comparison Matrix =

This page attempts to enumerate how [[OpenStack]], Eucalyptus and [[CloudStack]] compare in regards to EC2 API support. Corrections/contributions welcome.

== General API Support ==

{| border="1" cellpadding="2" cellspacing="0"
| Feature
| Eucalyptus
| [[OpenStack]]
|-
| EC2 Query API
| Y
| Y
|-
| EC2 Soap API
| (./)
||X
|-
| OpenStack API / Rackspace API
||X
| (./)
|-
| SSL Between Components
| (./)
||X
|-
| Horizontal Component Scalability
||X
| (./)
|-
| Web-based UI
| (./)
| (./)
|-
| Command line interface
| (./)
| (./)
|}

== Amazon EC2 High Level Feature Support ==

{| border="1" cellpadding="2" cellspacing="0"
| EC2 feature
| Eucalyptus
| [[OpenStack]]
|-
| Shared AMIs
| (./)
| (./)
|-
| Parameterized launch (user-data)
| (./)
| (./)
|-
| Instance metadata
| (./)
| (./)
|-
| Public AMI's
| (./)
| (./)
|-
| Launch/Terminate Instance
| (./)
| (./)
|-
| Reboot Instance
| (./)
| (./)
|-
| Start/Stop Persisted Instance
||X
| (./)
|-
| Retrieve Console Output
| (./)
| (./)
|-
| Paid AMI's
||X
||X
|-
| Multiple Instance Types
| (./)
| (./)
|-
| Instance Launch Time
| (./)
| (./)
|-
| Elastic IP's
| (./)
| (./)
|-
| Availability Zones
| (./)
| (./)
|-
| Region Support
| (./)
| (./)
|-
| User selectable kernels
| (./)
| (./)
|-
| Elastic Block Store
| (./)
| (./)
|-
| Booting without a ramdisk
| (./)
| (./)
|-
| Windows Support
||X
| (./)
|-
| Reserved Instances
||X
||X
|-
| Auto Scaling
||X
||X
|-
| Elastic Load Balancing
||X
||X
|-
| [[CloudWatch]]
||X
||X
|-
| Virtual Private Cloud (IPSec)
||X
||X
|-
| Shared Snapshots
||X
||X
|-
| AMI's backed by EBS
||X
| (./)
|-
| Spot Instances
||X
||X
|-
| Sticky session in Elastic LB
||X
||X
|-
| cc1.4xlarge
||X
||X
|-
| Specify IP address for inst in VPC
||X
||X
|-
| Tags
||X
||X
|-
| Filters
||X
||X
|-
| Idempotent [[RunInstance]] Calls
||X
||X
|-
| Import keypair
||X
| (./)
|-
| SSL termination
||X
||X
|}

== Amazon EC2 API Compatability ==

Note: Info on Eucalyptus was provided entirely by doing a grep of the source code. The Eucalyptus repository is [https://launchpad.net/eucalyptus here]. Info on [[CloudStack]]'s [[CloudBridge]] EC2 Commands was provided from [http://docs.cloudstack.org/@api/deki/files/165/CloudBridgeGuide.pdf CloudStack's Cloud Bridge Guide]. Eucalyptus and [[OpenStack]]'s EC2 support is integrated into the respective code bases. [[CloudStack]]'s support is provided by running a [[CloudBridge]] proxy server. Source code for the [[CloudBridge]] proxy is [https://github.com/CloudStack/CloudBridge here].

{| border="1" cellpadding="2" cellspacing="0"
| EC2 API method
| Eucalyptus
| [[OpenStack]]
|-
| AllocateAddress
| (./)
| (./)
|-
| AssociateAddress
| (./)
| (./)
|-
| AttachVolume
| (./)
| (./)
|-
| AuthorizeSecurityGroupIngress
| (./)
| (./)
|-
| BundleInstance
||X
||X
|-
| CancelBundleTask
||X
||X
|-
| CancelSpotInstanceRequests
||X
||X
|-
| ConfirmProductInstance
||X
||X
|-
| CreateImage
||X
||X
|-
| CreateKeyPair
| (./)
| (./)
|-
| CreatePlacementGroup
||X
||X
|-
| CreateSecurityGroup
| (./)
| (./)
|-
| CreateSnapshot
| (./)
| (./)
|-
| CreateSpotDatafeedSubscription
||X
||X
|-
| CreateTags
||X
||X
|-
| CreateVolume
| (./)
| (./)
|-
| DeleteKeyPair
| (./)
| (./)
|-
| DeletePlacementGroup
||X
||X
|-
| DeleteSecurityGroup
| (./)
| (./)
|-
| DeleteSnapshot
| (./)
| (./)
|-
| DeleteSpotDatafeedSubscription
||X
||X
|-
| DeleteTags
||X
||X
|-
| DeleteVolume
| (./)
| (./)
|-
| DeregisterImage
| (./)
| (./)
|-
| DescribeAddresses
| (./)
| (./)
|-
| DescribeAvailabilityZones
| (./)
| (./)
|-
| DescribeBundleTasks
||X
||X
|-
| DescribeImageAttribute
| (./)
| (./)
|-
| DescribeImages
| (./)
| (./)
|-
| DescribeInstanceAttribute
||X
||X
|-
| DescribeInstances
| (./)
| (./)
|-
| DescribeKeyPairs
| (./)
| (./)
|-
| DescribePlacementGroups
||X
||X
|-
| DescribeRegions
| (./)
| (./)
|-
| DescribeReservedInstances
||X
||X
|-
| DescribeReservedInstancesOfferings
||X
||X
|-
| DescribeSecurityGroups
| (./)
| (./)
|-
| DescribeSnapshotAttribute
||X
||X
|-
| DescribeSnapshots
| (./)
| (./)
|-
| DescribeSpotDatafeedSubscription
||X
||X
|-
| DescribeSpotInstanceRequests
||X
||X
|-
| DescribeSpotPriceHistory
||X
||X
|-
| DescribeTags
||X
||X
|-
| DescribeVolumes
| (./)
| (./)
|-
| DetachVolume
| (./)
| (./)
|-
| DisassociateAddress
| (./)
| (./)
|-
| GetConsoleOutput
| (./)
| (./)
|-
| GetPasswordData
||X
||X
|-
| ImportKeyPair
||X
| (./)
|-
| ModifyImageAttribute
| (./)
| (./)
|-
| ModifyInstanceAttribute
||X
||X
|-
| ModifySnapshotAttribute
||X
||X
|-
| MonitorInstances
||X
||X
|-
| PurchaseReservedInstancesOffering
||X
||X
|-
| RebootInstances
| (./)
| (./)
|-
| RegisterImage
| (./)
| (./)
|-
| ReleaseAddress
| (./)
| (./)
|-
| RequestSpotInstances
||X
||X
|-
| ResetImageAttribute
| (./)
||X
|-
| ResetInstanceAttribute
||X
||X
|-
| ResetSnapshotAttribute
||X
||X
|-
| RevokeSecurityGroupIngress
| (./)
| (./)
|-
| RunInstances
| (./)
| (./)
|-
| StartInstances
||X
| (./)
|-
| StopInstances
||X
| (./)
|-
| TerminateInstances
| (./)
| (./)
|-
| UnmonitorInstances
||X
||X
|}

----
[[Category:Nova]]

Nova/APIFeatureComparison

2013-03-24T20:55:11Z

Joshua-mckenty:

= EC2 API Comparison Matrix =

This page attempts to enumerate how [[OpenStack]], Eucalyptus and [[CloudStack]] compare in regards to EC2 API support. Corrections/contributions welcome.

== General API Support ==

{| border="1" cellpadding="2" cellspacing="0"
| Feature
| Eucalyptus
| [[OpenStack]]
|-
| EC2 Query API
| {{Check mark}}
| {{Check mark}}
|-
| EC2 Soap API
| (./)
||X
|-
| OpenStack API / Rackspace API
||X
| (./)
|-
| SSL Between Components
| (./)
||X
|-
| Horizontal Component Scalability
||X
| (./)
|-
| Web-based UI
| (./)
| (./)
|-
| Command line interface
| (./)
| (./)
|}

== Amazon EC2 High Level Feature Support ==

{| border="1" cellpadding="2" cellspacing="0"
| EC2 feature
| Eucalyptus
| [[OpenStack]]
|-
| Shared AMIs
| (./)
| (./)
|-
| Parameterized launch (user-data)
| (./)
| (./)
|-
| Instance metadata
| (./)
| (./)
|-
| Public AMI's
| (./)
| (./)
|-
| Launch/Terminate Instance
| (./)
| (./)
|-
| Reboot Instance
| (./)
| (./)
|-
| Start/Stop Persisted Instance
||X
| (./)
|-
| Retrieve Console Output
| (./)
| (./)
|-
| Paid AMI's
||X
||X
|-
| Multiple Instance Types
| (./)
| (./)
|-
| Instance Launch Time
| (./)
| (./)
|-
| Elastic IP's
| (./)
| (./)
|-
| Availability Zones
| (./)
| (./)
|-
| Region Support
| (./)
| (./)
|-
| User selectable kernels
| (./)
| (./)
|-
| Elastic Block Store
| (./)
| (./)
|-
| Booting without a ramdisk
| (./)
| (./)
|-
| Windows Support
||X
| (./)
|-
| Reserved Instances
||X
||X
|-
| Auto Scaling
||X
||X
|-
| Elastic Load Balancing
||X
||X
|-
| [[CloudWatch]]
||X
||X
|-
| Virtual Private Cloud (IPSec)
||X
||X
|-
| Shared Snapshots
||X
||X
|-
| AMI's backed by EBS
||X
| (./)
|-
| Spot Instances
||X
||X
|-
| Sticky session in Elastic LB
||X
||X
|-
| cc1.4xlarge
||X
||X
|-
| Specify IP address for inst in VPC
||X
||X
|-
| Tags
||X
||X
|-
| Filters
||X
||X
|-
| Idempotent [[RunInstance]] Calls
||X
||X
|-
| Import keypair
||X
| (./)
|-
| SSL termination
||X
||X
|}

== Amazon EC2 API Compatability ==

Note: Info on Eucalyptus was provided entirely by doing a grep of the source code. The Eucalyptus repository is [https://launchpad.net/eucalyptus here]. Info on [[CloudStack]]'s [[CloudBridge]] EC2 Commands was provided from [http://docs.cloudstack.org/@api/deki/files/165/CloudBridgeGuide.pdf CloudStack's Cloud Bridge Guide]. Eucalyptus and [[OpenStack]]'s EC2 support is integrated into the respective code bases. [[CloudStack]]'s support is provided by running a [[CloudBridge]] proxy server. Source code for the [[CloudBridge]] proxy is [https://github.com/CloudStack/CloudBridge here].

{| border="1" cellpadding="2" cellspacing="0"
| EC2 API method
| Eucalyptus
| [[OpenStack]]
|-
| AllocateAddress
| (./)
| (./)
|-
| AssociateAddress
| (./)
| (./)
|-
| AttachVolume
| (./)
| (./)
|-
| AuthorizeSecurityGroupIngress
| (./)
| (./)
|-
| BundleInstance
||X
||X
|-
| CancelBundleTask
||X
||X
|-
| CancelSpotInstanceRequests
||X
||X
|-
| ConfirmProductInstance
||X
||X
|-
| CreateImage
||X
||X
|-
| CreateKeyPair
| (./)
| (./)
|-
| CreatePlacementGroup
||X
||X
|-
| CreateSecurityGroup
| (./)
| (./)
|-
| CreateSnapshot
| (./)
| (./)
|-
| CreateSpotDatafeedSubscription
||X
||X
|-
| CreateTags
||X
||X
|-
| CreateVolume
| (./)
| (./)
|-
| DeleteKeyPair
| (./)
| (./)
|-
| DeletePlacementGroup
||X
||X
|-
| DeleteSecurityGroup
| (./)
| (./)
|-
| DeleteSnapshot
| (./)
| (./)
|-
| DeleteSpotDatafeedSubscription
||X
||X
|-
| DeleteTags
||X
||X
|-
| DeleteVolume
| (./)
| (./)
|-
| DeregisterImage
| (./)
| (./)
|-
| DescribeAddresses
| (./)
| (./)
|-
| DescribeAvailabilityZones
| (./)
| (./)
|-
| DescribeBundleTasks
||X
||X
|-
| DescribeImageAttribute
| (./)
| (./)
|-
| DescribeImages
| (./)
| (./)
|-
| DescribeInstanceAttribute
||X
||X
|-
| DescribeInstances
| (./)
| (./)
|-
| DescribeKeyPairs
| (./)
| (./)
|-
| DescribePlacementGroups
||X
||X
|-
| DescribeRegions
| (./)
| (./)
|-
| DescribeReservedInstances
||X
||X
|-
| DescribeReservedInstancesOfferings
||X
||X
|-
| DescribeSecurityGroups
| (./)
| (./)
|-
| DescribeSnapshotAttribute
||X
||X
|-
| DescribeSnapshots
| (./)
| (./)
|-
| DescribeSpotDatafeedSubscription
||X
||X
|-
| DescribeSpotInstanceRequests
||X
||X
|-
| DescribeSpotPriceHistory
||X
||X
|-
| DescribeTags
||X
||X
|-
| DescribeVolumes
| (./)
| (./)
|-
| DetachVolume
| (./)
| (./)
|-
| DisassociateAddress
| (./)
| (./)
|-
| GetConsoleOutput
| (./)
| (./)
|-
| GetPasswordData
||X
||X
|-
| ImportKeyPair
||X
| (./)
|-
| ModifyImageAttribute
| (./)
| (./)
|-
| ModifyInstanceAttribute
||X
||X
|-
| ModifySnapshotAttribute
||X
||X
|-
| MonitorInstances
||X
||X
|-
| PurchaseReservedInstancesOffering
||X
||X
|-
| RebootInstances
| (./)
| (./)
|-
| RegisterImage
| (./)
| (./)
|-
| ReleaseAddress
| (./)
| (./)
|-
| RequestSpotInstances
||X
||X
|-
| ResetImageAttribute
| (./)
||X
|-
| ResetInstanceAttribute
||X
||X
|-
| ResetSnapshotAttribute
||X
||X
|-
| RevokeSecurityGroupIngress
| (./)
| (./)
|-
| RunInstances
| (./)
| (./)
|-
| StartInstances
||X
| (./)
|-
| StopInstances
||X
| (./)
|-
| TerminateInstances
| (./)
| (./)
|-
| UnmonitorInstances
||X
||X
|}

----
[[Category:Nova]]