OpenStack - User contributions [en]

Magnum/Acronyms

2017-04-18T16:33:54Z

P Rivera: /* Table of Acronyms */ Added PV

= Table of Acronyms =
{| class="wikitable sortable"
|-
! Acronym !! Full Name !! Notes / Helpful Links
|-
| AI || Action Item || [http://whatis.techtarget.com/definition/action-item What is an action item?]
|-
| API || Application Programmer Interface || [http://en.wikipedia.org/wiki/Application_programming_interface API as defined by Wikipedia]
|-
| ATC || Active Technical Contributor || [https://ask.openstack.org/en/question/1629/how-do-i-become-an-active-technical-contributor/ How do I become an Active Technical Contributor?]
|-
| BP || Blueprint || [https://wiki.openstack.org/wiki/Blueprints OpenStack Blueprints]
|-
| CNM || Container Networking Model || [https://github.com/openstack/magnum/blob/master/specs/container-networking-model.rst Container Networking Model]
|-
| COE || Container Orchestration Engine || Software to manage containers
|-
| CR || Core Reviewer || [http://docs.openstack.org/infra/manual/core.html Core Reviewer's Guide]
|-
| CRUD || Create, Read, Update, Delete || [https://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD as defined by Wikipedia]
|-
| GKE || Google Container Engine || [https://cloud.google.com/container-engine/ GKE as defined by Google]
|-
| IaaS || Infrastructure as a Service || [http://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29 IaaS as defined by Wikipedia]
|-
| IRC || Internet Relay Chat || Our way of communicating via instant messages
|-
| K8S || Kubernetes || [http://kubernetes.io/ Kubernetes by Google]
|-
| LB || Load Balancer || [http://paulbakker.io/kubernetes/load-balancing-kubernetes/ Load Balancing Kubernetes]
|-
| ML || Mailing List || [[Magnum/Contributing#Sign_Up_for_the_OpenStack_Development_Mailing_List|OpenStack_Development_Mailing_List]]
|-
| PBR || Python Build Reasonableness || [https://pypi.python.org/pypi/pbr Python Build Reasonableness]
|-
| PTL || Project Team Lead || See http://docs.openstack.org/project-team-guide/
|-
| PV || Persistent Volumes || See https://kubernetes.io/docs/user-guide/persistent-volumes/
|-
| RC || Replication Controller || See https://www.openstack.org/assets/presentation-media/openstack-magnum-hands-on.pdf
|-
| TLS || Transport Layer Security || [http://en.wikipedia.org/wiki/Transport_Layer_Security Transport_Layer_Security as defined by Wikipedia]
|-
| WSME || Web Services Made Easy || [https://pypi.python.org/pypi/WSME Python-based framework used in OpenStack]
|}

Magnum/Acronyms

2017-04-18T16:29:43Z

P Rivera: /* Table of Acronyms */ Added GKE

= Table of Acronyms =
{| class="wikitable sortable"
|-
! Acronym !! Full Name !! Notes / Helpful Links
|-
| AI || Action Item || [http://whatis.techtarget.com/definition/action-item What is an action item?]
|-
| API || Application Programmer Interface || [http://en.wikipedia.org/wiki/Application_programming_interface API as defined by Wikipedia]
|-
| ATC || Active Technical Contributor || [https://ask.openstack.org/en/question/1629/how-do-i-become-an-active-technical-contributor/ How do I become an Active Technical Contributor?]
|-
| BP || Blueprint || [https://wiki.openstack.org/wiki/Blueprints OpenStack Blueprints]
|-
| CNM || Container Networking Model || [https://github.com/openstack/magnum/blob/master/specs/container-networking-model.rst Container Networking Model]
|-
| COE || Container Orchestration Engine || Software to manage containers
|-
| CR || Core Reviewer || [http://docs.openstack.org/infra/manual/core.html Core Reviewer's Guide]
|-
| CRUD || Create, Read, Update, Delete || [https://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD as defined by Wikipedia]
|-
| GKE || Google Container Engine || [https://cloud.google.com/container-engine/ GKE as defined by Google]
|-
| IaaS || Infrastructure as a Service || [http://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29 IaaS as defined by Wikipedia]
|-
| IRC || Internet Relay Chat || Our way of communicating via instant messages
|-
| K8S || Kubernetes || [http://kubernetes.io/ Kubernetes by Google]
|-
| LB || Load Balancer || [http://paulbakker.io/kubernetes/load-balancing-kubernetes/ Load Balancing Kubernetes]
|-
| ML || Mailing List || [[Magnum/Contributing#Sign_Up_for_the_OpenStack_Development_Mailing_List|OpenStack_Development_Mailing_List]]
|-
| PBR || Python Build Reasonableness || [https://pypi.python.org/pypi/pbr Python Build Reasonableness]
|-
| PTL || Project Team Lead || See http://docs.openstack.org/project-team-guide/
|-
| RC || Replication Controller || See https://www.openstack.org/assets/presentation-media/openstack-magnum-hands-on.pdf
|-
| TLS || Transport Layer Security || [http://en.wikipedia.org/wiki/Transport_Layer_Security Transport_Layer_Security as defined by Wikipedia]
|-
| WSME || Web Services Made Easy || [https://pypi.python.org/pypi/WSME Python-based framework used in OpenStack]
|}

Magnum/Acronyms

2017-04-18T16:21:26Z

P Rivera: /* Table of Acronyms */

= Table of Acronyms =
{| class="wikitable sortable"
|-
! Acronym !! Full Name !! Notes / Helpful Links
|-
| AI || Action Item || [http://whatis.techtarget.com/definition/action-item What is an action item?]
|-
| API || Application Programmer Interface || [http://en.wikipedia.org/wiki/Application_programming_interface API as defined by Wikipedia]
|-
| ATC || Active Technical Contributor || [https://ask.openstack.org/en/question/1629/how-do-i-become-an-active-technical-contributor/ How do I become an Active Technical Contributor?]
|-
| BP || Blueprint || [https://wiki.openstack.org/wiki/Blueprints OpenStack Blueprints]
|-
| CNM || Container Networking Model || [https://github.com/openstack/magnum/blob/master/specs/container-networking-model.rst Container Networking Model]
|-
| COE || Container Orchestration Engine || Software to manage containers
|-
| CR || Core Reviewer || [http://docs.openstack.org/infra/manual/core.html Core Reviewer's Guide]
|-
| CRUD || Create, Read, Update, Delete || [https://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD as defined by Wikipedia]
|-
| IaaS || Infrastructure as a Service || [http://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29 IaaS as defined by Wikipedia]
|-
| IRC || Internet Relay Chat || Our way of communicating via instant messages
|-
| K8S || Kubernetes || [http://kubernetes.io/ Kubernetes by Google]
|-
| LB || Load Balancer || [http://paulbakker.io/kubernetes/load-balancing-kubernetes/ Load Balancing Kubernetes]
|-
| ML || Mailing List || [[Magnum/Contributing#Sign_Up_for_the_OpenStack_Development_Mailing_List|OpenStack_Development_Mailing_List]]
|-
| PBR || Python Build Reasonableness || [https://pypi.python.org/pypi/pbr Python Build Reasonableness]
|-
| PTL || Project Team Lead || See http://docs.openstack.org/project-team-guide/
|-
| RC || Replication Controller || See https://www.openstack.org/assets/presentation-media/openstack-magnum-hands-on.pdf
|-
| TLS || Transport Layer Security || [http://en.wikipedia.org/wiki/Transport_Layer_Security Transport_Layer_Security as defined by Wikipedia]
|-
| WSME || Web Services Made Easy || [https://pypi.python.org/pypi/WSME Python-based framework used in OpenStack]
|}

Magnum/Acronyms

2016-02-19T22:36:29Z

P Rivera: /* Table of Acronyms */

= Table of Acronyms =
{| class="wikitable sortable"
|-
! Acronym !! Full Name !! Notes / Helpful Links
|-
| AI || Action Item || [http://whatis.techtarget.com/definition/action-item What is an action item?]
|-
| API || Application Programmer Interface || [http://en.wikipedia.org/wiki/Application_programming_interface API as defined by Wikipedia]
|-
| ATC || Active Technical Contributor || [https://ask.openstack.org/en/question/1629/how-do-i-become-an-active-technical-contributor/ How do I become an Active Technical Contributor?]
|-
| BP || Blueprint || [https://wiki.openstack.org/wiki/Blueprints OpenStack Blueprints]
|-
| CNM || Container Networking Model || [https://github.com/openstack/magnum/blob/master/specs/container-networking-model.rst Container Networking Model]
|-
| COE || Container Orchestration Engine || Software to manage containers
|-
| CR || Core Reviewer || [http://docs.openstack.org/infra/manual/core.html Core Reviewer's Guide]
|-
| CRUD || Create, Read, Update, Delete || [https://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD as defined by Wikipedia]
|-
| IaaS || Infrastructure as a Service || [http://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29 IaaS as defined by Wikipedia]
|-
| IRC || Internet Relay Chat || Our way of communicating via instant messages
|-
| K8S || Kubernetes || [http://kubernetes.io/ Kubernetes by Google]
|-
| LB || Load Balancer || [http://paulbakker.io/kubernetes/load-balancing-kubernetes/ Load Balancing Kubernetes]
|-
| ML || Mailing List || [[Magnum/Contributing#Sign_Up_for_the_OpenStack_Development_Mailing_List|OpenStack_Development_Mailing_List]]
|-
| PBR || Python Build Reasonableness || [https://pypi.python.org/pypi/pbr Python Build Reasonableness]
|-
| PTL || Project Team Lead || [[PTL Guide]]
|-
| TLS || Transport Layer Security || [http://en.wikipedia.org/wiki/Transport_Layer_Security Transport_Layer_Security as defined by Wikipedia]
|-
| WSME || Web Services Made Easy || [https://pypi.python.org/pypi/WSME Python-based framework used in OpenStack]
|}

Magnum/Acronyms

2015-12-15T16:56:08Z

P Rivera: /* Table of Acronyms */

= Table of Acronyms =
{| class="wikitable sortable"
|-
! Acronym !! Full Name !! Notes / Helpful Links
|-
| AI || Action Item || [http://whatis.techtarget.com/definition/action-item What is an action item?]
|-
| API || Application Programmer Interface || [http://en.wikipedia.org/wiki/Application_programming_interface API as defined by Wikipedia]
|-
| ATC || Active Technical Contributor || [https://ask.openstack.org/en/question/1629/how-do-i-become-an-active-technical-contributor/ How do I become an Active Technical Contributor?]
|-
| BP || Blueprint || [https://wiki.openstack.org/wiki/Blueprints OpenStack Blueprints]
|-
| CNM || Container Networking Model || [https://github.com/openstack/magnum/blob/master/specs/container-networking-model.rst Container Networking Model]
|-
| CR || Core Reviewer || [http://docs.openstack.org/infra/manual/core.html Core Reviewer's Guide]
|-
| CRUD || Create, Read, Update, Delete || [https://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD as defined by Wikipedia]
|-
| IaaS || Infrastructure as a Service || [http://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29 IaaS as defined by Wikipedia]
|-
| IRC || Internet Relay Chat || Our way of communicating via instant messages
|-
| K8S || Kubernetes || [http://kubernetes.io/ Kubernetes by Google]
|-
| LB || Load Balancer || [http://paulbakker.io/kubernetes/load-balancing-kubernetes/ Load Balancing Kubernetes]
|-
| ML || Mailing List || [[Magnum/Contributing#Sign_Up_for_the_OpenStack_Development_Mailing_List|OpenStack_Development_Mailing_List]]
|-
| PBR || Python Build Reasonableness || [https://pypi.python.org/pypi/pbr Python Build Reasonableness]
|-
| PTL || Project Team Lead || [[PTL Guide]]
|-
| TLS || Transport Layer Security || [http://en.wikipedia.org/wiki/Transport_Layer_Security Transport_Layer_Security as defined by Wikipedia]
|-
| WSME || Web Services Made Easy || [https://pypi.python.org/pypi/WSME Python-based framework used in OpenStack]
|}

Magnum/Acronyms

2015-12-08T16:32:19Z

P Rivera: /* Table of Acronyms */

= Table of Acronyms =
{| class="wikitable sortable"
|-
! Acronym !! Full Name !! Notes / Helpful Links
|-
| AI || Action Item || [http://whatis.techtarget.com/definition/action-item What is an action item?]
|-
| API || Application Programmer Interface || [http://en.wikipedia.org/wiki/Application_programming_interface API as defined by Wikipedia]
|-
| ATC || Active Technical Contributor || [https://ask.openstack.org/en/question/1629/how-do-i-become-an-active-technical-contributor/ How do I become an Active Technical Contributor?]
|-
| BP || Blueprint || [https://wiki.openstack.org/wiki/Blueprints OpenStack Blueprints]
|-
| CNM || Container Networking Model || [https://github.com/openstack/magnum/blob/master/specs/container-networking-model.rst Container Networking Model]
|-
| CR || Core Reviewer || [http://docs.openstack.org/infra/manual/core.html Core Reviewer's Guide]
|-
| IaaS || Infrastructure as a Service || [http://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29 IaaS as defined by Wikipedia]
|-
| IRC || Internet Relay Chat || Our way of communicating via instant messages
|-
| K8S || Kubernetes || [http://kubernetes.io/ Kubernetes by Google]
|-
| LB || Load Balancer || [http://paulbakker.io/kubernetes/load-balancing-kubernetes/ Load Balancing Kubernetes]
|-
| ML || Mailing List || [[Magnum/Contributing#Sign_Up_for_the_OpenStack_Development_Mailing_List|OpenStack_Development_Mailing_List]]
|-
| PBR || Python Build Reasonableness || [https://pypi.python.org/pypi/pbr Python Build Reasonableness]
|-
| PTL || Project Team Lead || [[PTL Guide]]
|-
| TLS || Transport Layer Security || [http://en.wikipedia.org/wiki/Transport_Layer_Security Transport_Layer_Security as defined by Wikipedia]
|-
| WSME || Web Services Made Easy || [https://pypi.python.org/pypi/WSME Python-based framework used in OpenStack]
|}

Magnum/Acronyms

2015-11-24T16:51:49Z

P Rivera: /* Table of Acronyms */

= Table of Acronyms =
{| class="wikitable sortable"
|-
! Acronym !! Full Name !! Notes / Helpful Links
|-
| AI || Action Item || [http://whatis.techtarget.com/definition/action-item What is an action item?]
|-
| API || Application Programmer Interface || [http://en.wikipedia.org/wiki/Application_programming_interface API as defined by Wikipedia]
|-
| ATC || Active Technical Contributor || [https://ask.openstack.org/en/question/1629/how-do-i-become-an-active-technical-contributor/ How do I become an Active Technical Contributor?]
|-
| BP || Blueprint || [https://wiki.openstack.org/wiki/Blueprints OpenStack Blueprints]
|-
| CNM || Container Networking Model || [https://github.com/openstack/magnum/blob/master/specs/container-networking-model.rst Container Networking Model]
|-
| CR || Core Reviewer || [http://docs.openstack.org/infra/manual/core.html Core Reviewer's Guide]
|-
| IaaS || Infrastructure as a Service || [http://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29 IaaS as defined by Wikipedia]
|-
| IRC || Internet Relay Chat || Our way of communicating via instant messages
|-
| K8S || Kubernetes || [http://kubernetes.io/ Kubernetes by Google]
|-
| LB || Load Balancer || [http://paulbakker.io/kubernetes/load-balancing-kubernetes/ Load Balancing Kubernetes]
|-
| ML || Mailing List || [[Magnum/Contributing#Sign_Up_for_the_OpenStack_Development_Mailing_List|OpenStack_Development_Mailing_List]]
|-
| PBR || Python Build Reasonableness || [https://pypi.python.org/pypi/pbr Python Build Reasonableness]
|-
| PTL || Project Team Lead || [[PTL Guide]]
|-
| TLS || Transport Layer Security || [http://en.wikipedia.org/wiki/Transport_Layer_Security Transport_Layer_Security as defined by Wikipedia]
|}

Magnum

2015-10-06T16:07:43Z

P Rivera: /* Meetings */

Magnum is an OpenStack API service developed by the [[Teams/Containers|OpenStack Containers Team]] making container orchestration engines such as Docker and Kubernetes available as first class resources in OpenStack. Magnum uses Heat to orchestrate an OS image which contains Docker and Kubernetes and runs that image in either virtual machines or bare metal in a cluster configuration. Click below for a 5 minute demo of how Magnum works.

<center>
[[File:Demo-Preview-Frame.png|none|link=https://vimeo.com/128538940|frame|400px]]
</center>

__TOC__

= News =

* 2015-08-26 Magnum will be presenting [http://sched.co/49xE a session on Magnum] at the 2015 OpenStack Summit in Tokyo on October 28 4:40pm - 5:20pm
* 2015-05-21 We presented [https://openstacksummitmay2015vancouver.sched.org/event/ec3936678ef22681408088ec52a4e80b a session on Magnum] at the 2015 OpenStack Summit in Vancouver on Thursday, May 21 9:00am - 9:40am US/Pacific. [https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/magnum-containers-as-a-service-for-openstack Video]
* 2015-03-24 Magnum has [https://review.openstack.org/161080 officially joined] the OpenStack project list upon approval by a unanimous vote by the Technical Committee.
* 2015-03-09 Our Kilo-2 release is now [https://github.com/stackforge/magnum/releases/tag/2015.1.0b2 available for download]
* 2015-01-20 We [http://lists.openstack.org/pipermail/openstack-dev/2015-January/054848.html have announced] Magnum's first release, now [https://github.com/stackforge/magnum/releases/tag/m1 available for download].

= Getting Started =
To get started with Magnum, see: [http://docs.openstack.org/developer/magnum/dev/dev-quickstart.html Our Quickstart Guide]

= Contributing =

The project is under active development by our OpenStack Containers Team. We [[Meetings/Containers|meet weekly by IRC]]. Magnum's meetings are normally chaired by our PTL [https://launchpad.net/~aotto Adrian Otto].

* We want you to [[Magnum/Contributing|contribute to Magnum]]!

= Architecture =

[[File:Magnum_architecture.png|center|800px|Magnum Architeture Diagram]]
Bay Create/Update/Delete

= Resources =
* Launchpad Project Pages
** [http://launchpad.net/magnum Magnum Launchpad Project] for Blueprints
** [http://launchpad.net/python-magnumclient python-magnumclient Launchpad Project] for Blueprints
* Mailing List
** [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack Mailing List] for project related discussion
*** Add [Magnum] to the subject line of new posts about this project.
** [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing List Archives] for current discussion.
* Code Reviews
** [https://review.openstack.org/#/q/status:open+magnum,n,z Gerrit Reviews]
* Code Repository
** git clone git://git.openstack.org/openstack/magnum
* Specification
** [https://review.openstack.org/136103 Containers Service Spec]
* References
**[[Magnum/Acronyms|Acronyms]]
**[http://eavesdrop.openstack.org/irclogs/%23openstack-containers/ IRC Logs - OpenStack Containers]
**[http://eavesdrop.openstack.org/meetings/containers/2015/ Meeting Minutes - OpenStack Containers]

= IRC =

Our developers use IRC in #openstack-containers on freenode for development discussion.

= Meetings =

* The weekly Containers [[Meetings/Containers|IRC meeting]] is held on Tuesdays at 1600 UTC [[Meetings/Containers|[schedule]]].
* [http://eavesdrop.openstack.org/meetings/containers/2014/ 2014 Containers Meeting Archive]

= Frequently Asked Questions =
'''1) How is Magnum is different from Nova?'''

Magnum provides a purpose built API to manage application containers, which have a distinctly different life cycle and operations than Nova (machine) Instances. We actually use Nova instances to run our application containers.

'''2) How is Magnum different than Docker or Kubernetes?'''

Magnum offers an asynchronous API that's compatible with Keystone, and a complete multi-tenancy implementation. It does not perform orchestration
internally, and instead relies on OpenStack Orchestration. Magnum does leverage both Kubernetes and Docker as components.

'''3) Is this the same thing as Nova-Docker?'''

No, Nova-Docker is a virt driver for Nova that allows containers to be created as Nova instances. This is suitable for use cases when you want to treat a container like a lightweight machine. Magnum provides container specific features that are beyond the scope of Nova's API, and implements its own API to surface these features in a way that is consistent with other OpenStack services. Containers started by Magnum are run on top of Nova instances that are created using Heat.

'''4) Who is Magnum for?'''

Magnum is for OpenStack cloud operators (public or private) who want to offer a self-service solution to provide containers to their cloud users as a managed hosted service. Magnum simplifies the required integration with OpenStack, and allows for cloud users who can already launch cloud resources such as Nova Instances, Cinder Volumes, Trove Databases, etc. to also create application containers to run applications in an environment that provides advanced features that are beyond the scope of existing cloud resources. The same identity credentials used to create IaaS resources can be used to run containerized applications using Magnum. Some examples of advanced features available with Magnum are the ability to scale an application to a specified number of instances, to cause your application to automatically re-spawn an instance in the event of a failure, and to pack applications together more tightly than would be possible using Virtual Machines.

'''5) Will I get the same thing if I use the Docker resource in Heat?'''

No, the Docker Heat resource does not provide a resource scheduler, or a choice of container technology used. It is specific to Docker, and uses Glance to store container images. It does not currently allow for layered image features, which can cause containers to take longer to start than if layered images are used with a locally cached base image. Magnum leverages all of the speed benefits that Docker offers.

'''6) What does multi-tenancy mean in Magnum (Is Magnum Secure)?'''

Resources such as Containers, Services, Pods, Bays, etc. started by Magnum can only be viewed and accessed by users of the tenant that created them. Bays are not shared, meaning that containers will not run on the same kernel as neighboring tenants. This is a key security feature that allows containers belonging to the same tenant to be tightly packed within the same Pods and Bays, but runs separate kernels (in separate Nova Instances) between different tenants. This is different than using a system like Kubernetes without Magnum, which is intended to be used only by a single tenant, and leaves the security isolation design up to the implementer. Using Magnum provides the same level of security isolation as Nova provides when running Virtual Machines belonging to different tenants on the same compute nodes.

Magnum/Acronyms

2015-09-22T22:44:36Z

P Rivera: /* Table of Acronyms */

Magnum/Acronyms

2015-09-22T22:25:06Z

P Rivera: /* Table of Acronyms */

Magnum/Contributing

2015-07-15T00:33:42Z

P Rivera: /* Write some awesome code */

__TOC__

= Before You Begin =
To familiarize yourself with Magnum, try it out using the information in our [http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst Dev Quickstart Guide] and [https://github.com/openstack/magnum/blob/master/doc/source/dev/dev-manual-devstack.rst Manually Adding Magnum to DevStack Guide]. When you are ready to start contributing, you will need to execute an [[How_To_Contribute#Contributors_License_Agreement|OpenStack CLA]]. This is required before you can submit reviews to our [https://github.com/openstack/magnum Magnum Repo]. For information about how prepare for contribution, please consult the [[How_To_Contribute |How To Contribute]] wiki page.

We strongly recommend that you spend 40 minutes watching the [https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/7-habits-of-highly-effective-contributors 7 Habits of Highly Effective Contributors] video. This is Adrian Otto's philosophy on the behaviors that you should exhibit to become a valued member of our contributor community. Adrian is the founding PTL of Magnum.

== Sign Up for the OpenStack Development Mailing List ==
Head on over to [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack Dev Mailing List], fill out the fields under "Subscribing to OpenStack-dev" and click Subscribe.

== Learn About Gerrit ==
Be sure to read the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide] for information about how to submit your commit for review so it can be merged into the Magnum code base.

If you do not have a gerrit username setup or do not remember it,
verify and configure it here: https://review.openstack.org/#/settings/

Keep that handy for the "git review -s" command later in the https://wiki.openstack.org/wiki/Magnum/Contributing#Setting_up_your_git_review_settings and https://wiki.openstack.org/wiki/Magnum/Contributing#Set_up_your_local_branch sections below...

You'll also need to upload an SSH public key, specifically for Gerrit:
https://review.openstack.org/#/settings/ssh-keys

== Setting up your git review settings ==
New to git? Try the 15-minute high-level interactive Git demo [http://try.github.com/ GitHub Demo]

Need a git refresher? Download a git reference direct from the source: [https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf GitHub Git Cheat Sheet]

Then:

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"

In the event your launchpad and gerrit usernames are identical:
git config --global gitreview.username "your_launchpad_username"
In the event your launchpad and gerrit usernames are not identical:
git config --global gitreview.username "your_gerrit_username"

To check your git configuration:

git config --list

== Installing git-review ==
On Ubuntu, MacOSx, or most other Unix-like systems, it is as simple as:
pip install git-review

There are other installation options detailed in the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide]. You can now check out the Magnum code and begin working on it:

= Your first commit =

== Set up your local branch ==

git clone git://git.openstack.org/openstack/magnum
cd magnum
git checkout -b [branch name (see below...)]
git review -s

To find out what branch names are valid, try out one of the useful git branch commands here: http://gitready.com/intermediate/2009/02/13/list-remote-branches.html

If you receive the following error when running the "git review -s" command:
We don't know where your gerrit is. Please manually create a remote
named "gerrit" and try again.

Perform the following (substituting <your gerrit username> with your specific gerrit username...):
git remote add gerrit ssh://<your gerrit username>@review.openstack.org:29418/openstack/magnum.git
git review -s

If you receive the following error when running the "git review -s" command:
Agent admitted failure to sign using the key

See this support page: https://help.github.com/articles/error-agent-admitted-failure-to-sign/

== Identify bugs ==
Observe a bug? Report it here: https://launchpad.net/magnum
# Click the '''Report a Bug''' button.
# Enter a Summary in the field and click Next. Here's an example: Stale link to Gerrit Workflow
# Review the choices you've been given. If you spot your bug, click on the bug and review its status; proceed to the awesome code section below if there's more to do.. If you do not spot your bug, proceed to the next step.
# Click the '''No, I need to report a new bug''' button.
# Type in a detailed description of the bug in the "Further information" field and click '''Submit bug report'''. Here's an example description for our previous example: In doc/source/dev/dev-quickstart.rst the link to the Gerrit workflow is incorrect. It should be: http://docs.openstack.org/infra/manual/developers.html

== Write some awesome code ==

At this point can write your code and push it to Gerrit for review.

git add <list of files you added/changed>

If you submitted a bug in the previous section, be sure to add the bug link in the commit message.

Each commit line should conform with the OpenStack style guidelines. Some highlights:
# The first line of the commit message should be <=50 characters.
# The subsequent lines can be <= 78 characters.
# Lines 2 onward are a blank line followed by a more verbose description of the first commit line (as needed).
# The last commit line needs to link to either a blueprint or bug/task ticket number.
# There should be no whitespace at the end of all lines.
# The order these lines is important.

If you'd like specific details of how to assemble your commit message,
see the message structure guideline document here:
https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_Git_commit_message_structure

For the example case, a possible message might look like:
Adjust Gerrit workflow Link
<blank line>
The Gerrit workflow link in the previous version is no longer valid.
This patch updates documentation to the current link.
<blank line>
Closes-Bug: #<some bug/task ticket number>
Change-Id: <some lengthy hexadecimal string>

'''WARNING:''' Be sure to include the pound (#) symbol in the Closes-Bug line, e.g. Closes-Bug: #111111

Once you organize the above information, perform the following command to type it in:
git commit -a

Then, submit the review:
git review -v --draft

Once you are happy with your code and want it to be reviewed you want to convert it from a Draft. "Sign In" at https://review.openstack.org/ and after verifying the review yourself hit the "Publish" button on the page.

If you know you are ready for others to review your code, you can skip the draft step and just do:
git review -v

By this point, your code will be reviewed by the Openstack automatic testing frameworks and, potentially, your peers on the project.

If you want to revise your patchset in the review system in response to feedback, first navigate back to your development area:
cd ~/magnum [or wherever that is for your setup...]

Download the change. Be sure to use the review number and NOT the bug number:
git review -d <review number>

Then, make your changes, and update the commit message using the aforementioned commit guidelines:
git commit --amend

Then:
git review -v

Upon approval of the review your code will be automatically merged.

=== Need somewhere to start writing code? ===

You can also contribute to the quality of the code by looking at the coverage of current Magnum unit tests and improving the code coverage.
The following code has under 30% code coverage.

Name Stmts Miss Branch BrMiss Cover Missing
magnum/base 56 56 16 16 0% 13-113
magnum/cloud/nova_driver 20 20 0 0 0% 13-45
magnum/cmd/api 23 23 2 2 0% 15-54
magnum/cmd/conductor 28 28 3 3 0% 15-65
magnum/cmd/db_manage 42 42 2 2 0% 14-91
magnum/cmd/template_manage 49 49 15 15 0% 14-96
magnum/common/pythonk8sclient/client/ApivbetaApi 4570 4415 1656 1656 2% 30, 55-109, ...
magnum/common/pythonk8sclient/client/models/V1beta3_Binding 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Container 21 18 0 0 14% 29-179
magnum/common/pythonk8sclient/client/models/V1beta3_ContainerStateTerminated 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_ContainerStatus 13 10 0 0 23% 29-107
magnum/common/pythonk8sclient/client/models/V1beta3_Endpoints 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Event 24 21 0 0 13% 29-206
magnum/common/pythonk8sclient/client/models/V1beta3_LimitRange 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Namespace 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Node 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_NodeCondition 11 8 0 0 27% 29-89
magnum/common/pythonk8sclient/client/models/V1beta3_NodeSystemInfo 13 10 0 0 23% 29-105
magnum/common/pythonk8sclient/client/models/V1beta3_ObjectReference 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_PersistentVolume 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_PersistentVolumeClaim 19 16 0 0 16% 29-160
magnum/common/pythonk8sclient/client/models/V1beta3_Pod 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_PodSpec 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_PodStatus 11 8 0 0 27% 29-89
magnum/common/pythonk8sclient/client/models/V1beta3_PodTemplateSpec 16 13 0 0 19% 29-134
magnum/common/pythonk8sclient/client/models/V1beta3_ReplicationController 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_ResourceQuota 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Secret 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Service 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_ServiceSpec 11 8 0 0 27% 29-88
magnum/common/pythonk8sclient/client/models/V1beta3_Volume 13 10 0 0 23% 29-107
magnum/common/pythonk8sclient/client/swagger 154 125 74 74 13% 33-40, 44, 48, ...
magnum/common/service 5 5 0 0 0% 15-22
magnum/config 8 8 0 0 0% 15-78
magnum/db/migration 19 19 2 2 0% 17-52
magnum/opts 16 16 0 0 0% 16-34
TOTAL 10985 5975 2908 2063 42%

You can review the code coverage of your currently checked out code with:
$ tox -e cover

This will produce a '''cover''' directory that provides HTML output showing the code coverage as well as the specific lines of code that are not covered.

==== Low Hanging Fruit ====
Some bugs have been identified by the bug manager as appropriate for first time contributors. These bugs should require small patches, and don't require an extensive understanding of Magnum to work on. Find them [https://bugs.launchpad.net/magnum/+bugs?field.tag=low-hanging-fruit tagged with the low-hanging-fruit tag in the bug system].

= How to Resolve Merge Conflicts =

If another patch changes the same line of code as your patch, and it gets merged before yours, your patch may get a <code>patch in merge conflict</code> status in red. If that happens, here is how you can resolve it. You will need the patch number from the Gerrit URL https://review.openstack.org/NNNNN to make your rebase a revision of the previous review.

git clone https://github.com/openstack/magnum
cd magnum
git review -d NNNNN
git rebase master

Now edit all files with merge conflicts to resolve them by making the code look the way it should both with the recently merged code, and your own. Then <code>git add</code> each of the files you edited.

git add path/to/file/you/edited
git rebase --continue
git review -v

That will resubmit your patch with the original commit message, and the rebased code with your merge fix as a new patch set.

= Reviews =

The OpenStack CI system uses the concept of core reviewers. These are individuals who have consistently reviewed code for the project, and helped over a considerable period of time to improve the quality and consistency of what we merge into the code base. Project contributors will feel that this reviewer is a positive influence on the team and that they maintain the values and traditions of the OpenStack development community.

== Policies ==
Existing core reviewers may nominate new ones in an ML thread. Consent among the current reviewers shall result in the declaration of the new core reviewer by the PTL. Lack of unanimous consent shall be carefully considered, and a final decision informed by input from from active team members shall be made by the PTL. Core reviewers who are judged by their peers in the core review group to fall short of the expectations for contribution of a core reviewer may be nominated for return to regular reviewer status.

Patches require a core reviewer to mark a review as "Approved" before they are merged.

== Review Guidelines ==
=== Code Approval for Merge ===
* For Approval, two core reviewers shall supply a <code>+2</code>.
=== Continuing Someone Else's Contribution ===
* If a patch submitted by one contributor is picked up and completed by another contributor, [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg05998.html special handling] of the resolution should be used.
=== Advice for Reviewers ===
* A <code>-1</code> vote is an opportunity to make our code better before it is merged. Please do your best to make helpful, actionable -1 votes.
* Avoid the temptation to blindly <code>+1</code> code without reviewing it in sufficient detail to form an opinion.
* When voting <code>-1</code> on a patch, it means that you want the submitter to make a revision in accordance with your feedback before core reviewers should consider this code for merge.
* If you ask a question, you should vote <code>0</code> unless you anticipate that the answer to that question is likely to cause you to vote against the patch without further revisions.
* If you use a <code>-1</code> vote for a question, and the contributor answers the question, please respond acknowledging the question. Either change your vote or follow up with additional rationale for why this should remain a <code>-1</code> comment.
* A <code>-2</code> vote is a veto by a single core reviewer. It is sticky. That means that even if you revise your patch, that vote will persist. To allow your patch to merge, that same reviewer must clear the <code>-2</code> vote first. This vote is used when you have contributed something that is not in alignment with the current project vision, or is implemented in a way that can not be accepted. For example, security concerns that a core reviewer wants to individually re-evaluate before allowing the contribution to continue. It can also be used as a way to halt further gate testing of a patch, if something is included that may break the gate. It works even after a <code>2*+2,+A</code> approval for merge, but before the patch reaches MERGED state.
* To avoid a <code>-2</code> vote, discuss your plans with the development team prior to writing code, and post a WIP (workflow-1) patch while you are working on it, and ask for input before you submit it for merge review.

Magnum/Contributing

2015-07-15T00:31:15Z

P Rivera: /* Write some awesome code */

__TOC__

= Before You Begin =
To familiarize yourself with Magnum, try it out using the information in our [http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst Dev Quickstart Guide] and [https://github.com/openstack/magnum/blob/master/doc/source/dev/dev-manual-devstack.rst Manually Adding Magnum to DevStack Guide]. When you are ready to start contributing, you will need to execute an [[How_To_Contribute#Contributors_License_Agreement|OpenStack CLA]]. This is required before you can submit reviews to our [https://github.com/openstack/magnum Magnum Repo]. For information about how prepare for contribution, please consult the [[How_To_Contribute |How To Contribute]] wiki page.

We strongly recommend that you spend 40 minutes watching the [https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/7-habits-of-highly-effective-contributors 7 Habits of Highly Effective Contributors] video. This is Adrian Otto's philosophy on the behaviors that you should exhibit to become a valued member of our contributor community. Adrian is the founding PTL of Magnum.

== Sign Up for the OpenStack Development Mailing List ==
Head on over to [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack Dev Mailing List], fill out the fields under "Subscribing to OpenStack-dev" and click Subscribe.

== Learn About Gerrit ==
Be sure to read the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide] for information about how to submit your commit for review so it can be merged into the Magnum code base.

If you do not have a gerrit username setup or do not remember it,
verify and configure it here: https://review.openstack.org/#/settings/

Keep that handy for the "git review -s" command later in the https://wiki.openstack.org/wiki/Magnum/Contributing#Setting_up_your_git_review_settings and https://wiki.openstack.org/wiki/Magnum/Contributing#Set_up_your_local_branch sections below...

You'll also need to upload an SSH public key, specifically for Gerrit:
https://review.openstack.org/#/settings/ssh-keys

== Setting up your git review settings ==
New to git? Try the 15-minute high-level interactive Git demo [http://try.github.com/ GitHub Demo]

Need a git refresher? Download a git reference direct from the source: [https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf GitHub Git Cheat Sheet]

Then:

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"

In the event your launchpad and gerrit usernames are identical:
git config --global gitreview.username "your_launchpad_username"
In the event your launchpad and gerrit usernames are not identical:
git config --global gitreview.username "your_gerrit_username"

To check your git configuration:

git config --list

== Installing git-review ==
On Ubuntu, MacOSx, or most other Unix-like systems, it is as simple as:
pip install git-review

There are other installation options detailed in the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide]. You can now check out the Magnum code and begin working on it:

= Your first commit =

== Set up your local branch ==

git clone git://git.openstack.org/openstack/magnum
cd magnum
git checkout -b [branch name (see below...)]
git review -s

To find out what branch names are valid, try out one of the useful git branch commands here: http://gitready.com/intermediate/2009/02/13/list-remote-branches.html

If you receive the following error when running the "git review -s" command:
We don't know where your gerrit is. Please manually create a remote
named "gerrit" and try again.

Perform the following (substituting <your gerrit username> with your specific gerrit username...):
git remote add gerrit ssh://<your gerrit username>@review.openstack.org:29418/openstack/magnum.git
git review -s

If you receive the following error when running the "git review -s" command:
Agent admitted failure to sign using the key

See this support page: https://help.github.com/articles/error-agent-admitted-failure-to-sign/

== Identify bugs ==
Observe a bug? Report it here: https://launchpad.net/magnum
# Click the '''Report a Bug''' button.
# Enter a Summary in the field and click Next. Here's an example: Stale link to Gerrit Workflow
# Review the choices you've been given. If you spot your bug, click on the bug and review its status; proceed to the awesome code section below if there's more to do.. If you do not spot your bug, proceed to the next step.
# Click the '''No, I need to report a new bug''' button.
# Type in a detailed description of the bug in the "Further information" field and click '''Submit bug report'''. Here's an example description for our previous example: In doc/source/dev/dev-quickstart.rst the link to the Gerrit workflow is incorrect. It should be: http://docs.openstack.org/infra/manual/developers.html

== Write some awesome code ==

At this point can write your code and push it to Gerrit for review.

git add <list of files you added/changed>

If you submitted a bug in the previous section, be sure to add the bug link in the commit message.

Each commit line should conform with the OpenStack style guidelines. Some highlights:
# The first line of the commit message should be <=50 characters.
# The subsequent lines can be <= 78 characters.
# Lines 2 onward are a blank line followed by a more verbose description of the first commit line (as needed).
# The last commit line needs to link to either a blueprint or bug/task ticket number.
# There should be no whitespace at the end of all lines.
# The order these lines is important.

If you'd like specific details of how to assemble your commit message,
see the message structure guideline document here:
https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_Git_commit_message_structure

For the example case, a possible message might look like:
Adjust Gerrit workflow Link
<blank line>
The Gerrit workflow link in the previous version is no longer valid.
This patch updates documentation to the current link.
<blank line>
Closes-Bug: #<some bug/task ticket number>
Change-Id: <some lengthy hexadecimal string>

'''WARNING:''' Be sure to include the pound (#) symbol in the Closes-Bug line!

Once you organize the above information, perform the following command to type it in:
git commit -a

Then, submit the review:
git review -v --draft

Once you are happy with your code and want it to be reviewed you want to convert it from a Draft. "Sign In" at https://review.openstack.org/ and after verifying the review yourself hit the "Publish" button on the page.

If you know you are ready for others to review your code, you can skip the draft step and just do:
git review -v

By this point, your code will be reviewed by the Openstack automatic testing frameworks and, potentially, your peers on the project.

If you want to revise your patchset in the review system in response to feedback, first navigate back to your development area:
cd ~/magnum [or wherever that is for your setup...]

Download the change. Be sure to use the review number and NOT the bug number:
git review -d <review number>

Then, make your changes, and update the commit message using the aforementioned commit guidelines:
git commit --amend

Then:
git review -v

Upon approval of the review your code will be automatically merged.

=== Need somewhere to start writing code? ===

You can also contribute to the quality of the code by looking at the coverage of current Magnum unit tests and improving the code coverage.
The following code has under 30% code coverage.

Name Stmts Miss Branch BrMiss Cover Missing
magnum/base 56 56 16 16 0% 13-113
magnum/cloud/nova_driver 20 20 0 0 0% 13-45
magnum/cmd/api 23 23 2 2 0% 15-54
magnum/cmd/conductor 28 28 3 3 0% 15-65
magnum/cmd/db_manage 42 42 2 2 0% 14-91
magnum/cmd/template_manage 49 49 15 15 0% 14-96
magnum/common/pythonk8sclient/client/ApivbetaApi 4570 4415 1656 1656 2% 30, 55-109, ...
magnum/common/pythonk8sclient/client/models/V1beta3_Binding 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Container 21 18 0 0 14% 29-179
magnum/common/pythonk8sclient/client/models/V1beta3_ContainerStateTerminated 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_ContainerStatus 13 10 0 0 23% 29-107
magnum/common/pythonk8sclient/client/models/V1beta3_Endpoints 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Event 24 21 0 0 13% 29-206
magnum/common/pythonk8sclient/client/models/V1beta3_LimitRange 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Namespace 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Node 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_NodeCondition 11 8 0 0 27% 29-89
magnum/common/pythonk8sclient/client/models/V1beta3_NodeSystemInfo 13 10 0 0 23% 29-105
magnum/common/pythonk8sclient/client/models/V1beta3_ObjectReference 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_PersistentVolume 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_PersistentVolumeClaim 19 16 0 0 16% 29-160
magnum/common/pythonk8sclient/client/models/V1beta3_Pod 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_PodSpec 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_PodStatus 11 8 0 0 27% 29-89
magnum/common/pythonk8sclient/client/models/V1beta3_PodTemplateSpec 16 13 0 0 19% 29-134
magnum/common/pythonk8sclient/client/models/V1beta3_ReplicationController 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_ResourceQuota 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Secret 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Service 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_ServiceSpec 11 8 0 0 27% 29-88
magnum/common/pythonk8sclient/client/models/V1beta3_Volume 13 10 0 0 23% 29-107
magnum/common/pythonk8sclient/client/swagger 154 125 74 74 13% 33-40, 44, 48, ...
magnum/common/service 5 5 0 0 0% 15-22
magnum/config 8 8 0 0 0% 15-78
magnum/db/migration 19 19 2 2 0% 17-52
magnum/opts 16 16 0 0 0% 16-34
TOTAL 10985 5975 2908 2063 42%

You can review the code coverage of your currently checked out code with:
$ tox -e cover

This will produce a '''cover''' directory that provides HTML output showing the code coverage as well as the specific lines of code that are not covered.

==== Low Hanging Fruit ====
Some bugs have been identified by the bug manager as appropriate for first time contributors. These bugs should require small patches, and don't require an extensive understanding of Magnum to work on. Find them [https://bugs.launchpad.net/magnum/+bugs?field.tag=low-hanging-fruit tagged with the low-hanging-fruit tag in the bug system].

= How to Resolve Merge Conflicts =

If another patch changes the same line of code as your patch, and it gets merged before yours, your patch may get a <code>patch in merge conflict</code> status in red. If that happens, here is how you can resolve it. You will need the patch number from the Gerrit URL https://review.openstack.org/NNNNN to make your rebase a revision of the previous review.

git clone https://github.com/openstack/magnum
cd magnum
git review -d NNNNN
git rebase master

Now edit all files with merge conflicts to resolve them by making the code look the way it should both with the recently merged code, and your own. Then <code>git add</code> each of the files you edited.

git add path/to/file/you/edited
git rebase --continue
git review -v

That will resubmit your patch with the original commit message, and the rebased code with your merge fix as a new patch set.

= Reviews =

The OpenStack CI system uses the concept of core reviewers. These are individuals who have consistently reviewed code for the project, and helped over a considerable period of time to improve the quality and consistency of what we merge into the code base. Project contributors will feel that this reviewer is a positive influence on the team and that they maintain the values and traditions of the OpenStack development community.

== Policies ==
Existing core reviewers may nominate new ones in an ML thread. Consent among the current reviewers shall result in the declaration of the new core reviewer by the PTL. Lack of unanimous consent shall be carefully considered, and a final decision informed by input from from active team members shall be made by the PTL. Core reviewers who are judged by their peers in the core review group to fall short of the expectations for contribution of a core reviewer may be nominated for return to regular reviewer status.

Patches require a core reviewer to mark a review as "Approved" before they are merged.

== Review Guidelines ==
=== Code Approval for Merge ===
* For Approval, two core reviewers shall supply a <code>+2</code>.
=== Continuing Someone Else's Contribution ===
* If a patch submitted by one contributor is picked up and completed by another contributor, [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg05998.html special handling] of the resolution should be used.
=== Advice for Reviewers ===
* A <code>-1</code> vote is an opportunity to make our code better before it is merged. Please do your best to make helpful, actionable -1 votes.
* Avoid the temptation to blindly <code>+1</code> code without reviewing it in sufficient detail to form an opinion.
* When voting <code>-1</code> on a patch, it means that you want the submitter to make a revision in accordance with your feedback before core reviewers should consider this code for merge.
* If you ask a question, you should vote <code>0</code> unless you anticipate that the answer to that question is likely to cause you to vote against the patch without further revisions.
* If you use a <code>-1</code> vote for a question, and the contributor answers the question, please respond acknowledging the question. Either change your vote or follow up with additional rationale for why this should remain a <code>-1</code> comment.
* A <code>-2</code> vote is a veto by a single core reviewer. It is sticky. That means that even if you revise your patch, that vote will persist. To allow your patch to merge, that same reviewer must clear the <code>-2</code> vote first. This vote is used when you have contributed something that is not in alignment with the current project vision, or is implemented in a way that can not be accepted. For example, security concerns that a core reviewer wants to individually re-evaluate before allowing the contribution to continue. It can also be used as a way to halt further gate testing of a patch, if something is included that may break the gate. It works even after a <code>2*+2,+A</code> approval for merge, but before the patch reaches MERGED state.
* To avoid a <code>-2</code> vote, discuss your plans with the development team prior to writing code, and post a WIP (workflow-1) patch while you are working on it, and ask for input before you submit it for merge review.

Magnum/Contributing

2015-07-07T06:13:33Z

P Rivera: /* Set up your local branch */

__TOC__

= Before You Begin =
To familiarize yourself with Magnum, try it out using the information in our [http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst Dev Quickstart Guide] and [https://github.com/openstack/magnum/blob/master/doc/source/dev/dev-manual-devstack.rst Manually Adding Magnum to DevStack Guide]. When you are ready to start contributing, you will need to execute an [[How_To_Contribute#Contributors_License_Agreement|OpenStack CLA]]. This is required before you can submit reviews to our [https://github.com/openstack/magnum Magnum Repo]. For information about how prepare for contribution, please consult the [[How_To_Contribute |How To Contribute]] wiki page.

We strongly recommend that you spend 40 minutes watching the [https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/7-habits-of-highly-effective-contributors 7 Habits of Highly Effective Contributors] video. This is Adrian Otto's philosophy on the behaviors that you should exhibit to become a valued member of our contributor community. Adrian is the founding PTL of Magnum.

== Sign Up for the OpenStack Development Mailing List ==
Head on over to [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack Dev Mailing List], fill out the fields under "Subscribing to OpenStack-dev" and click Subscribe.

== Learn About Gerrit ==
Be sure to read the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide] for information about how to submit your commit for review so it can be merged into the Magnum code base.

If you do not have a gerrit username setup or do not remember it,
verify and configure it here: https://review.openstack.org/#/settings/

Keep that handy for the "git review -s" command later in the https://wiki.openstack.org/wiki/Magnum/Contributing#Setting_up_your_git_review_settings and https://wiki.openstack.org/wiki/Magnum/Contributing#Set_up_your_local_branch sections below...

You'll also need to upload an SSH public key, specifically for Gerrit:
https://review.openstack.org/#/settings/ssh-keys

== Setting up your git review settings ==
New to git? Try the 15-minute high-level interactive Git demo [http://try.github.com/ GitHub Demo]

Need a git refresher? Download a git reference direct from the source: [https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf GitHub Git Cheat Sheet]

Then:

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"

In the event your launchpad and gerrit usernames are identical:
git config --global gitreview.username "your_launchpad_username"
In the event your launchpad and gerrit usernames are not identical:
git config --global gitreview.username "your_gerrit_username"

To check your git configuration:

git config --list

== Installing git-review ==
On Ubuntu, MacOSx, or most other Unix-like systems, it is as simple as:
pip install git-review

There are other installation options detailed in the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide]. You can now check out the Magnum code and begin working on it:

= Your first commit =

== Set up your local branch ==

git clone git://git.openstack.org/openstack/magnum
cd magnum
git checkout -b [branch name (see below...)]
git review -s

To find out what branch names are valid, try out one of the useful git branch commands here: http://gitready.com/intermediate/2009/02/13/list-remote-branches.html

If you receive the following error when running the "git review -s" command:
We don't know where your gerrit is. Please manually create a remote
named "gerrit" and try again.

Perform the following (substituting <your gerrit username> with your specific gerrit username...):
git remote add gerrit ssh://<your gerrit username>@review.openstack.org:29418/openstack/magnum.git
git review -s

If you receive the following error when running the "git review -s" command:
Agent admitted failure to sign using the key

See this support page: https://help.github.com/articles/error-agent-admitted-failure-to-sign/

== Identify bugs ==
Observe a bug? Report it here: https://launchpad.net/magnum
# Click the '''Report a Bug''' button.
# Enter a Summary in the field and click Next. Here's an example: Stale link to Gerrit Workflow
# Review the choices you've been given. If you spot your bug, click on the bug and review its status; proceed to the awesome code section below if there's more to do.. If you do not spot your bug, proceed to the next step.
# Click the '''No, I need to report a new bug''' button.
# Type in a detailed description of the bug in the "Further information" field and click '''Submit bug report'''. Here's an example description for our previous example: In doc/source/dev/dev-quickstart.rst the link to the Gerrit workflow is incorrect. It should be: http://docs.openstack.org/infra/manual/developers.html

== Write some awesome code ==

At this point can write your code and push it to Gerrit for review.

git add <list of files you added/changed>

If you submitted a bug in the previous section, be sure to add the bug link in the commit message.

Each commit line should conform with the OpenStack style guidelines. Some highlights:
# The first line of the commit message should be <=50 characters.
# The subsequent lines can be <= 78 characters.
# Lines 2 onward are a blank line followed by a more verbose description of the first commit line (as needed).
# The last commit line needs to link to either a blueprint or bug/task ticket number.
# There should be no whitespace at the end of all lines.
# The order these lines is important.

If you'd like specific details of how to assemble your commit message,
see the message structure guideline document here:
https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_Git_commit_message_structure

For the example case, a possible message might look like:
Adjust Gerrit workflow Link
<blank line>
The Gerrit workflow link in the previous version is no longer valid.
This patch updates documentation to the current link.
<blank line>
Closes-Bug: <some bug/task ticket number>
Change-Id: <some lengthy hexadecimal string>

Once you organize the above information, perform the following command to type it in:
git commit -a

Then, submit the review:
git review -v --draft

Once you are happy with your code and want it to be reviewed you want to convert it from a Draft. "Sign In" at https://review.openstack.org/ and after verifying the review yourself hit the "Publish" button on the page.

If you know you are ready for others to review your code, you can skip the draft step and just do:
git review -v

By this point, your code will be reviewed by the Openstack automatic testing frameworks and, potentially, your peers on the project.

If you want to revise your patchset in the review system in response to feedback, first navigate back to your development area:
cd ~/magnum [or wherever that is for your setup...]

Download the change. Be sure to use the review number and NOT the bug number:
git review -d <review number>

Then, make your changes, and update the commit message using the aforementioned commit guidelines:
git commit --amend

Then:
git review -v

Upon approval of the review your code will be automatically merged.

=== Need somewhere to start writing code? ===

You can also contribute to the quality of the code by looking at the coverage of current Magnum unit tests and improving the code coverage.
The following code has under 30% code coverage.

Name Stmts Miss Branch BrMiss Cover Missing
magnum/base 56 56 16 16 0% 13-113
magnum/cloud/nova_driver 20 20 0 0 0% 13-45
magnum/cmd/api 23 23 2 2 0% 15-54
magnum/cmd/conductor 28 28 3 3 0% 15-65
magnum/cmd/db_manage 42 42 2 2 0% 14-91
magnum/cmd/template_manage 49 49 15 15 0% 14-96
magnum/common/pythonk8sclient/client/ApivbetaApi 4570 4415 1656 1656 2% 30, 55-109, ...
magnum/common/pythonk8sclient/client/models/V1beta3_Binding 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Container 21 18 0 0 14% 29-179
magnum/common/pythonk8sclient/client/models/V1beta3_ContainerStateTerminated 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_ContainerStatus 13 10 0 0 23% 29-107
magnum/common/pythonk8sclient/client/models/V1beta3_Endpoints 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Event 24 21 0 0 13% 29-206
magnum/common/pythonk8sclient/client/models/V1beta3_LimitRange 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Namespace 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Node 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_NodeCondition 11 8 0 0 27% 29-89
magnum/common/pythonk8sclient/client/models/V1beta3_NodeSystemInfo 13 10 0 0 23% 29-105
magnum/common/pythonk8sclient/client/models/V1beta3_ObjectReference 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_PersistentVolume 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_PersistentVolumeClaim 19 16 0 0 16% 29-160
magnum/common/pythonk8sclient/client/models/V1beta3_Pod 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_PodSpec 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_PodStatus 11 8 0 0 27% 29-89
magnum/common/pythonk8sclient/client/models/V1beta3_PodTemplateSpec 16 13 0 0 19% 29-134
magnum/common/pythonk8sclient/client/models/V1beta3_ReplicationController 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_ResourceQuota 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Secret 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Service 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_ServiceSpec 11 8 0 0 27% 29-88
magnum/common/pythonk8sclient/client/models/V1beta3_Volume 13 10 0 0 23% 29-107
magnum/common/pythonk8sclient/client/swagger 154 125 74 74 13% 33-40, 44, 48, ...
magnum/common/service 5 5 0 0 0% 15-22
magnum/config 8 8 0 0 0% 15-78
magnum/db/migration 19 19 2 2 0% 17-52
magnum/opts 16 16 0 0 0% 16-34
TOTAL 10985 5975 2908 2063 42%

You can review the code coverage of your currently checked out code with:
$ tox -e cover

This will produce a '''cover''' directory that provides HTML output showing the code coverage as well as the specific lines of code that are not covered.

==== Low Hanging Fruit ====
Some bugs have been identified by the bug manager as appropriate for first time contributors. These bugs should require small patches, and don't require an extensive understanding of Magnum to work on. Find them [https://bugs.launchpad.net/magnum/+bugs?field.tag=low-hanging-fruit tagged with the low-hanging-fruit tag in the bug system].

= How to Resolve Merge Conflicts =

If another patch changes the same line of code as your patch, and it gets merged before yours, your patch may get a <code>patch in merge conflict</code> status in red. If that happens, here is how you can resolve it. You will need the patch number from the Gerrit URL https://review.openstack.org/NNNNN to make your rebase a revision of the previous review.

git clone https://github.com/openstack/magnum
cd magnum
git review -d NNNNN
git rebase master

Now edit all files with merge conflicts to resolve them by making the code look the way it should both with the recently merged code, and your own. Then <code>git add</code> each of the files you edited.

git add path/to/file/you/edited
git rebase --continue
git review -v

That will resubmit your patch with the original commit message, and the rebased code with your merge fix as a new patch set.

= Reviews =

The OpenStack CI system uses the concept of core reviewers. These are individuals who have consistently reviewed code for the project, and helped over a considerable period of time to improve the quality and consistency of what we merge into the code base. Project contributors will feel that this reviewer is a positive influence on the team and that they maintain the values and traditions of the OpenStack development community.

== Policies ==
Existing core reviewers may nominate new ones in an ML thread. Consent among the current reviewers shall result in the declaration of the new core reviewer by the PTL. Lack of unanimous consent shall be carefully considered, and a final decision informed by input from from active team members shall be made by the PTL. Core reviewers who are judged by their peers in the core review group to fall short of the expectations for contribution of a core reviewer may be nominated for return to regular reviewer status.

Patches require a core reviewer to mark a review as "Approved" before they are merged.

== Review Guidelines ==
=== Code Approval for Merge ===
* For Approval, two core reviewers shall supply a <code>+2</code>.
=== Continuing Someone Else's Contribution ===
* If a patch submitted by one contributor is picked up and completed by another contributor, [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg05998.html special handling] of the resolution should be used.
=== Advice for Reviewers ===
* A <code>-1</code> vote is an opportunity to make our code better before it is merged. Please do your best to make helpful, actionable -1 votes.
* Avoid the temptation to blindly <code>+1</code> code without reviewing it in sufficient detail to form an opinion.
* When voting <code>-1</code> on a patch, it means that you want the submitter to make a revision in accordance with your feedback before core reviewers should consider this code for merge.
* If you ask a question, you should vote <code>0</code> unless you anticipate that the answer to that question is likely to cause you to vote against the patch without further revisions.
* If you use a <code>-1</code> vote for a question, and the contributor answers the question, please respond acknowledging the question. Either change your vote or follow up with additional rationale for why this should remain a <code>-1</code> comment.
* A <code>-2</code> vote is a veto by a single core reviewer. It is sticky. That means that even if you revise your patch, that vote will persist. To allow your patch to merge, that same reviewer must clear the <code>-2</code> vote first. This vote is used when you have contributed something that is not in alignment with the current project vision, or is implemented in a way that can not be accepted. For example, security concerns that a core reviewer wants to individually re-evaluate before allowing the contribution to continue. It can also be used as a way to halt further gate testing of a patch, if something is included that may break the gate. It works even after a <code>2*+2,+A</code> approval for merge, but before the patch reaches MERGED state.
* To avoid a <code>-2</code> vote, discuss your plans with the development team prior to writing code, and post a WIP (workflow-1) patch while you are working on it, and ask for input before you submit it for merge review.

Magnum/Contributing

2015-06-28T07:11:01Z

P Rivera: /* Write some awesome code */

__TOC__

= Before You Begin =
To familiarize yourself with Magnum, try it out using the information in our [http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst Dev Quickstart Guide] and [https://github.com/openstack/magnum/blob/master/doc/source/dev/dev-manual-devstack.rst Manually Adding Magnum to DevStack Guide]. When you are ready to start contributing, you will need to execute an [[How_To_Contribute#Contributors_License_Agreement|OpenStack CLA]]. This is required before you can submit reviews to our [https://github.com/openstack/magnum Magnum Repo]. For information about how prepare for contribution, please consult the [[How_To_Contribute |How To Contribute]] wiki page.

We strongly recommend that you spend 40 minutes watching the [https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/7-habits-of-highly-effective-contributors 7 Habits of Highly Effective Contributors] video. This is Adrian Otto's philosophy on the behaviors that you should exhibit to become a valued member of our contributor community. Adrian is the founding PTL of Magnum.

== Sign Up for the OpenStack Development Mailing List ==
Head on over to [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack Dev Mailing List], fill out the fields under "Subscribing to OpenStack-dev" and click Subscribe.

== Learn About Gerrit ==
Be sure to read the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide] for information about how to submit your commit for review so it can be merged into the Magnum code base.

If you do not have a gerrit username setup or do not remember it,
verify and configure it here: https://review.openstack.org/#/settings/

Keep that handy for the "git review -s" command later in the https://wiki.openstack.org/wiki/Magnum/Contributing#Setting_up_your_git_review_settings and https://wiki.openstack.org/wiki/Magnum/Contributing#Set_up_your_local_branch sections below...

You'll also need to upload an SSH public key, specifically for Gerrit:
https://review.openstack.org/#/settings/ssh-keys

== Setting up your git review settings ==
New to git? Try the 15-minute high-level interactive Git demo [http://try.github.com/ GitHub Demo]

Need a git refresher? Download a git reference direct from the source: [https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf GitHub Git Cheat Sheet]

Then:

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"

In the event your launchpad and gerrit usernames are identical:
git config --global gitreview.username "your_launchpad_username"
In the event your launchpad and gerrit usernames are not identical:
git config --global gitreview.username "your_gerrit_username"

To check your git configuration:

git config --list

== Installing git-review ==
On Ubuntu, MacOSx, or most other Unix-like systems, it is as simple as:
pip install git-review

There are other installation options detailed in the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide]. You can now check out the Magnum code and begin working on it:

= Your first commit =

== Set up your local branch ==

git clone git://git.openstack.org/openstack/magnum
cd magnum
git checkout -b [branch name]
git review -s

If you receive the following error when running the "git review -s" command:
We don't know where your gerrit is. Please manually create a remote
named "gerrit" and try again.

Perform the following (substituting <your gerrit username> with your specific gerrit username...):
git remote add gerrit ssh://<your gerrit username>@review.openstack.org:29418/openstack/magnum.git
git review -s

If you receive the following error when running the "git review -s" command:
Agent admitted failure to sign using the key

See this support page: https://help.github.com/articles/error-agent-admitted-failure-to-sign/

== Identify bugs ==
Observe a bug? Report it here: https://launchpad.net/magnum
# Click the '''Report a Bug''' button.
# Enter a Summary in the field and click Next. Here's an example: Stale link to Gerrit Workflow
# Review the choices you've been given. If you spot your bug, click on the bug and review its status; proceed to the awesome code section below if there's more to do.. If you do not spot your bug, proceed to the next step.
# Click the '''No, I need to report a new bug''' button.
# Type in a detailed description of the bug in the "Further information" field and click '''Submit bug report'''. Here's an example description for our previous example: In doc/source/dev/dev-quickstart.rst the link to the Gerrit workflow is incorrect. It should be: http://docs.openstack.org/infra/manual/developers.html

== Write some awesome code ==

At this point can write your code and push it to Gerrit for review.

git add <list of files you added/changed>

If you submitted a bug in the previous section, be sure to add the bug link in the commit message.

Each commit line should conform with the OpenStack style guidelines. Some highlights:
# The first line of the commit message should be <=50 characters.
# The subsequent lines can be <= 78 characters.
# Lines 2 onward are a blank line followed by a more verbose description of the first commit line (as needed).
# The last commit line needs to link to either a blueprint or bug/task ticket number.
# There should be no whitespace at the end of all lines.
# The order these lines is important.

If you'd like specific details of how to assemble your commit message,
see the message structure guideline document here:
https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_Git_commit_message_structure

For the example case, a possible message might look like:
Adjust Gerrit workflow Link
<blank line>
The Gerrit workflow link in the previous version is no longer valid.
This patch updates documentation to the current link.
<blank line>
Closes-Bug: <some bug/task ticket number>
Change-Id: <some lengthy hexadecimal string>

Once you organize the above information, perform the following command to type it in:
git commit -a

Then, submit the review:
git review -v --draft

Once you are happy with your code and want it to be reviewed you want to convert it from a Draft. "Sign In" at https://review.openstack.org/ and after verifying the review yourself hit the "Publish" button on the page.

If you know you are ready for others to review your code, you can skip the draft step and just do:
git review -v

By this point, your code will be reviewed by the Openstack automatic testing frameworks and, potentially, your peers on the project.

If you want to revise your patchset in the review system in response to feedback, first navigate back to your development area:
cd ~/magnum [or wherever that is for your setup...]

Download the change. Be sure to use the review number and NOT the bug number:
git review -d <review number>

Then, make your changes, and update the commit message using the aforementioned commit guidelines:
git commit --amend

Then:
git review -v

Upon approval of the review your code will be automatically merged.

=== Need somewhere to start writing code? ===

You can also contribute to the quality of the code by looking at the coverage of current Magnum unit tests and improving the code coverage.
The following code has under 30% code coverage.

Name Stmts Miss Branch BrMiss Cover Missing
magnum/base 56 56 16 16 0% 13-113
magnum/cloud/nova_driver 20 20 0 0 0% 13-45
magnum/cmd/api 23 23 2 2 0% 15-54
magnum/cmd/conductor 28 28 3 3 0% 15-65
magnum/cmd/db_manage 42 42 2 2 0% 14-91
magnum/cmd/template_manage 49 49 15 15 0% 14-96
magnum/common/pythonk8sclient/client/ApivbetaApi 4570 4415 1656 1656 2% 30, 55-109, ...
magnum/common/pythonk8sclient/client/models/V1beta3_Binding 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Container 21 18 0 0 14% 29-179
magnum/common/pythonk8sclient/client/models/V1beta3_ContainerStateTerminated 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_ContainerStatus 13 10 0 0 23% 29-107
magnum/common/pythonk8sclient/client/models/V1beta3_Endpoints 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Event 24 21 0 0 13% 29-206
magnum/common/pythonk8sclient/client/models/V1beta3_LimitRange 18 15 0 0 17% 29-152
magnum/common/pythonk8sclient/client/models/V1beta3_Namespace 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Node 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_NodeCondition 11 8 0 0 27% 29-89
magnum/common/pythonk8sclient/client/models/V1beta3_NodeSystemInfo 13 10 0 0 23% 29-105
magnum/common/pythonk8sclient/client/models/V1beta3_ObjectReference 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_PersistentVolume 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_PersistentVolumeClaim 19 16 0 0 16% 29-160
magnum/common/pythonk8sclient/client/models/V1beta3_Pod 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_PodSpec 12 9 0 0 25% 29-98
magnum/common/pythonk8sclient/client/models/V1beta3_PodStatus 11 8 0 0 27% 29-89
magnum/common/pythonk8sclient/client/models/V1beta3_PodTemplateSpec 16 13 0 0 19% 29-134
magnum/common/pythonk8sclient/client/models/V1beta3_ReplicationController 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_ResourceQuota 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Secret 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_Service 19 16 0 0 16% 29-161
magnum/common/pythonk8sclient/client/models/V1beta3_ServiceSpec 11 8 0 0 27% 29-88
magnum/common/pythonk8sclient/client/models/V1beta3_Volume 13 10 0 0 23% 29-107
magnum/common/pythonk8sclient/client/swagger 154 125 74 74 13% 33-40, 44, 48, ...
magnum/common/service 5 5 0 0 0% 15-22
magnum/config 8 8 0 0 0% 15-78
magnum/db/migration 19 19 2 2 0% 17-52
magnum/opts 16 16 0 0 0% 16-34
TOTAL 10985 5975 2908 2063 42%

You can review the code coverage of your currently checked out code with:
$ tox -e cover

This will produce a '''cover''' directory that provides HTML output showing the code coverage as well as the specific lines of code that are not covered.

==== Low Hanging Fruit ====
Some bugs have been identified by the bug manager as appropriate for first time contributors. These bugs should require small patches, and don't require an extensive understanding of Magnum to work on. Find them [https://bugs.launchpad.net/magnum/+bugs?field.tag=low-hanging-fruit tagged with the low-hanging-fruit tag in the bug system].

= How to Resolve Merge Conflicts =

If another patch changes the same line of code as your patch, and it gets merged before yours, your patch may get a <code>patch in merge conflict</code> status in red. If that happens, here is how you can resolve it. You will need the patch number from the Gerrit URL https://review.openstack.org/NNNNN to make your rebase a revision of the previous review.

git clone https://github.com/openstack/magnum
cd magnum
git review -d NNNNN
git rebase master

Now edit all files with merge conflicts to resolve them by making the code look the way it should both with the recently merged code, and your own. Then <code>git add</code> each of the files you edited.

git add path/to/file/you/edited
git rebase --continue
git review -v

That will resubmit your patch with the original commit message, and the rebased code with your merge fix as a new patch set.

= Reviews =

The OpenStack CI system uses the concept of core reviewers. These are individuals who have consistently reviewed code for the project, and helped over a considerable period of time to improve the quality and consistency of what we merge into the code base. Project contributors will feel that this reviewer is a positive influence on the team and that they maintain the values and traditions of the OpenStack development community.

== Policies ==
Existing core reviewers may nominate new ones in an ML thread. Consent among the current reviewers shall result in the declaration of the new core reviewer by the PTL. Lack of unanimous consent shall be carefully considered, and a final decision informed by input from from active team members shall be made by the PTL. Core reviewers who are judged by their peers in the core review group to fall short of the expectations for contribution of a core reviewer may be nominated for return to regular reviewer status.

Patches require a core reviewer to mark a review as "Approved" before they are merged.

== Review Guidelines ==
=== Code Approval for Merge ===
* For Approval, two core reviewers shall supply a <code>+2</code>.
=== Continuing Someone Else's Contribution ===
* If a patch submitted by one contributor is picked up and completed by another contributor, [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg05998.html special handling] of the resolution should be used.
=== Advice for Reviewers ===
* A <code>-1</code> vote is an opportunity to make our code better before it is merged. Please do your best to make helpful, actionable -1 votes.
* Avoid the temptation to blindly <code>+1</code> code without reviewing it in sufficient detail to form an opinion.
* When voting <code>-1</code> on a patch, it means that you want the submitter to make a revision in accordance with your feedback before core reviewers should consider this code for merge.
* If you ask a question, you should vote <code>0</code> unless you anticipate that the answer to that question is likely to cause you to vote against the patch without further revisions.
* If you use a <code>-1</code> vote for a question, and the contributor answers the question, please respond acknowledging the question. Either change your vote or follow up with additional rationale for why this should remain a <code>-1</code> comment.
* A <code>-2</code> vote is a veto by a single core reviewer. It is sticky. That means that even if you revise your patch, that vote will persist. To allow your patch to merge, that same reviewer must clear the <code>-2</code> vote first. This vote is used when you have contributed something that is not in alignment with the current project vision, or is implemented in a way that can not be accepted. For example, security concerns that a core reviewer wants to individually re-evaluate before allowing the contribution to continue. It can also be used as a way to halt further gate testing of a patch, if something is included that may break the gate. It works even after a <code>2*+2,+A</code> approval for merge, but before the patch reaches MERGED state.
* To avoid a <code>-2</code> vote, discuss your plans with the development team prior to writing code, and post a WIP (workflow-1) patch while you are working on it, and ask for input before you submit it for merge review.

Magnum/Acronyms

2015-06-09T17:23:15Z

P Rivera: /* Table of Acronyms */

Magnum/Acronyms

2015-06-02T00:13:00Z

P Rivera: /* Table of Acronyms */

= Table of Acronyms =
{| class="wikitable sortable"
|-
! Acronym !! Full Name !! Notes / Helpful Links
|-
| API || Application Programmer Interface || [http://en.wikipedia.org/wiki/Application_programming_interface API as defined by Wikipedia]
|-
| ATC || Active Technical Contributor || [https://ask.openstack.org/en/question/1629/how-do-i-become-an-active-technical-contributor/ How do I become an Active Technical Contributor?]
|-
| IaaS || Infrastructure as a Service || [http://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29 IaaS as defined by Wikipedia]
|-
| IRC || Internet Relay Chat || Our way of communicating via instant messages
|-
| K8S || Kubernetes || [http://kubernetes.io/ Kubernetes by Google]
|-
| ML || Mailing List || [[Magnum/Contributing#Sign_Up_for_the_OpenStack_Development_Mailing_List|OpenStack_Development_Mailing_List]]
|-
| PBR || Python Build Reasonableness || [https://pypi.python.org/pypi/pbr Python Build Reasonableness]
|-
| PTL || Project Team Lead || [[PTL Guide]]
|-
| TLS || Transport Layer Security || [http://en.wikipedia.org/wiki/Transport_Layer_Security Transport_Layer_Security as defined by Wikipedia]
|}

Magnum/Contributing

2015-05-05T06:56:56Z

P Rivera: /* Before You Begin */

Magnum/Acronyms

2015-04-14T17:24:39Z

P Rivera: /* Table of Acronyms */

= Table of Acronyms =
{| class="wikitable sortable"
|-
! Acronym !! Full Name !! Notes / Helpful Links
|-
| API || Application Programmer Interface || [http://en.wikipedia.org/wiki/Application_programming_interface API as defined by Wikipedia]
|-
| ATC || Active Technical Contributor || [https://ask.openstack.org/en/question/1629/how-do-i-become-an-active-technical-contributor/ How do I become an Active Technical Contributor?]
|-
| IaaS || Infrastructure as a Service || [http://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29 IaaS as defined by Wikipedia]
|-
| IRC || Internet Relay Chat || Our way of communicating via instant messages
|-
| K8S || Kubernetes || [http://kubernetes.io/ Kubernetes by Google]
|-
| ML || Mailing List || [[Magnum/Contributing#Sign_Up_for_the_OpenStack_Development_Mailing_List|OpenStack_Development_Mailing_List]]
|-
| PBR || Python Build Reasonableness || [https://pypi.python.org/pypi/pbr Python Build Reasonableness]
|-
| TLS || Transport Layer Security || [http://en.wikipedia.org/wiki/Transport_Layer_Security Transport_Layer_Security as defined by Wikipedia]
|}

Magnum/Acronyms

2015-04-07T23:24:33Z

P Rivera: /* Table of Acronyms */

= Table of Acronyms =
{| class="wikitable sortable"
|-
! Acronym !! Full Name !! Notes / Helpful Links
|-
| API || Application Programmer Interface || [http://en.wikipedia.org/wiki/Application_programming_interface API as defined by Wikipedia]
|-
| ATC || Active Technical Contributor || [https://ask.openstack.org/en/question/1629/how-do-i-become-an-active-technical-contributor/ How do I become an Active Technical Contributor?]
|-
| IaaS || Infrastructure as a Service || [http://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29 IaaS as defined by Wikipedia]
|-
| IRC || Internet Relay Chat || Our way of communicating via instant messages
|-
| K8S || Kubernetes || [http://kubernetes.io/ Kubernetes by Google]
|-
| ML || Mailing List || [[Magnum/Contributing#Sign_Up_for_the_OpenStack_Development_Mailing_List|OpenStack_Development_Mailing_List]]
|-
| TLS || Transport Layer Security || [http://en.wikipedia.org/wiki/Transport_Layer_Security Transport_Layer_Security as defined by Wikipedia]
|}

Magnum/Acronyms

2015-03-31T17:20:21Z

P Rivera: /* Table of Acronyms */

Magnum/Acronyms

2015-03-31T16:30:42Z

P Rivera: /* Table of Acronyms */

Magnum/Contributing

2015-03-28T05:09:39Z

P Rivera: /* Before You Begin */

__TOC__

= Before You Begin =
To familiarize yourself with Magnum, try it out using the information in our [http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst Dev Quickstart Guide]. When you are ready to start contributing, you will need to execute an [[How_To_Contribute#Contributors_License_Agreement|OpenStack CLA]]. This is required before you can submit reviews to our [https://github.com/openstack/magnum Magnum Repo]. For information about how prepare for contribution, please consult the [[How_To_Contribute |How To Contribute]] wiki page.

== Sign Up for the OpenStack Development Mailing List ==
Head on over to [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack Dev Mailing List], fill out the fields under "Subscribing to OpenStack-dev" and click Subscribe.

== Learn About Gerrit ==
Be sure to read the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide] for information about how to submit your commit for review so it can be merged into the Magnum code base.

If you do not have a gerrit username setup or do not remember it,
verify and configure it here: https://review.openstack.org/#/settings/

Keep that handy for the "git review -s" command later in the https://wiki.openstack.org/wiki/Magnum/Contributing#Setting_up_your_git_review_settings and https://wiki.openstack.org/wiki/Magnum/Contributing#Set_up_your_local_branch sections below...

You'll also need to upload an SSH public key, specifically for Gerrit:
https://review.openstack.org/#/settings/ssh-keys

== Setting up your git review settings ==
New to git? Try the 15-minute high-level interactive Git demo [http://try.github.com/ GitHub Demo]

Need a git refresher? Download a git reference direct from the source: [https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf GitHub Git Cheat Sheet]

Then:

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"

In the event your launchpad and gerrit usernames are identical:
git config --global gitreview.username "your_launchpad_username"
In the event your launchpad and gerrit usernames are not identical:
git config --global gitreview.username "your_gerrit_username"

To check your git configuration:

git config --list

== Installing git-review ==
On Ubuntu, MacOSx, or most other Unix-like systems, it is as simple as:
pip install git-review

There are other installation options detailed in the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide]. You can now check out the Magnum code and begin working on it:

= Your first commit =

== Set up your local branch ==

git clone git://git.openstack.org/openstack/magnum
cd magnum
git checkout -b [branch name]
git review -s

If you receive the following error when running the "git review -s" command:
We don't know where your gerrit is. Please manually create a remote
named "gerrit" and try again.

Perform the following (substituting <your gerrit username> with your specific gerrit username...):
git remote add gerrit ssh://<your gerrit username>@review.openstack.org:29418/openstack/magnum.git
git review -s

If you receive the following error when running the "git review -s" command:
Agent admitted failure to sign using the key

See this support page: https://help.github.com/articles/error-agent-admitted-failure-to-sign/

== Identify bugs ==
Observe a bug? Report it here: https://launchpad.net/magnum
# Click the '''Report a Bug''' button.
# Enter a Summary in the field and click Next. Here's an example: Stale link to Gerrit Workflow
# Review the choices you've been given. If you spot your bug, click on the bug and review its status; proceed to the awesome code section below if there's more to do.. If you do not spot your bug, proceed to the next step.
# Click the '''No, I need to report a new bug''' button.
# Type in a detailed description of the bug in the "Further information" field and click '''Submit bug report'''. Here's an example description for our previous example: In doc/source/dev/dev-quickstart.rst the link to the Gerrit workflow is incorrect. It should be: http://docs.openstack.org/infra/manual/developers.html

== Write some awesome code ==

At this point can write your code and push it to Gerrit for review.

git add <list of files you added/changed>

If you submitted a bug in the previous section, be sure to add the bug link in the commit message.

Each commit line should conform with the OpenStack style guidelines. Some highlights:
# The first line of the commit message should be <=50 characters.
# The subsequent lines can be <= 78 characters.
# Lines 2 onward are a blank line followed by a more verbose description of the first commit line (as needed).
# The last commit line needs to link to either a blueprint or bug/task ticket number.
# There should be no whitespace at the end of all lines.

For the example case:
Adjust Gerrit workflow Link
<blank line>
The Gerrit workflow link in the previous version is no longer valid.
This patch updates documentation to the current link.
<blank line>
Closes-bug: <bug/task ticket number>

Then,

git commit -a
git review -v --draft

Once you are happy with your code and want it to be reviewed you want to convert it from a Draft. "Sign In" at https://review.openstack.org/ and after verifying the review yourself hit the "Publish" button on the page.

If you know you are ready for others to review your code, you can skip the draft step and just do:
git review -v

By this point, your code will be reviewed by the Openstack automatic testing frameworks and, potentially, your peers on the project.

If you want to revise your patchset in the review system in response to feedback, make your changes, then use:
git commit -a --amend
git review -v

Upon approval of the review your code will be automatically merged.

= How to Resolve Merge Conflicts =

If another patch changes the same line of code as your patch, and it gets merged before yours, your patch may get a <code>patch in merge conflict</code> status in red. If that happens, here is how you can resolve it. You will need the patch number from the Gerrit URL https://review.openstack.org/NNNNN to make your rebase a revision of the previous review.

git clone https://github.com/openstack/magnum
cd magnum
git review -d NNNNN
git rebase master

Now edit all files with merge conflicts to resolve them by making the code look the way it should both with the recently merged code, and your own. Then <code>git add</code> each of the files you edited.

git add path/to/file/you/edited
git rebase --continue
git review -v

That will resubmit your patch with the original commit message, and the rebased code with your merge fix as a new patch set.

= Reviews =

The OpenStack CI system uses the concept of core reviewers. These are individuals who have consistently reviewed code for the project, and helped over a considerable period of time to improve the quality and consistency of what we merge into the code base. Project contributors will feel that this reviewer is a positive influence on the team and that they maintain the values and traditions of the OpenStack development community.

== Policies ==
Existing core reviewers may nominate new ones in an ML thread. Consent among the current reviewers shall result in the declaration of the new core reviewer by the PTL. Lack of unanimous consent shall be carefully considered, and a final decision informed by input from from active team members shall be made by the PTL. Core reviewers who are judged by their peers in the core review group to fall short of the expectations for contribution of a core reviewer may be nominated for return to regular reviewer status.

Patches require a core reviewer to mark a review as "Approved" before they are merged.

== Review Guidelines ==
=== Code Approval for Merge ===
* For Approval, two core reviewers shall supply a <code>+2</code>.
=== Continuing Someone Else's Contribution ===
* If a patch submitted by one contributor is picked up and completed by another contributor, [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg05998.html special handling] of the resolution should be used.
=== Advice for Reviewers ===
* A <code>-1</code> vote is an opportunity to make our code better before it is merged. Please do your best to make helpful, actionable -1 votes.
* Avoid the temptation to blindly <code>+1</code> code without reviewing it in sufficient detail to form an opinion.
* When voting <code>-1</code> on a patch, it means that you want the submitter to make a revision in accordance with your feedback before core reviewers should consider this code for merge.
* If you ask a question, you should vote <code>0</code> unless you anticipate that the answer to that question is likely to cause you to vote against the patch without further revisions.
* If you use a <code>-1</code> vote for a question, and the contributor answers the question, please respond acknowledging the question. Either change your vote or follow up with additional rationale for why this should remain a <code>-1</code> comment.
* A <code>-2</code> vote is a veto by a single core reviewer. It is sticky. That means that even if you revise your patch, that vote will persist. To allow your patch to merge, that same reviewer must clear the <code>-2</code> vote first. This vote is used when you have contributed something that is not in alignment with the current project vision, or is implemented in a way that can not be accepted. For example, security concerns that a core reviewer wants to individually re-evaluate before allowing the contribution to continue. It can also be used as a way to halt further gate testing of a patch, if something is included that may break the gate. It works even after a <code>2*+2,+A</code> approval for merge, but before the patch reaches MERGED state.
* To avoid a <code>-2</code> vote, discuss your plans with the development team prior to writing code, and post a WIP (workflow-1) patch while you are working on it, and ask for input before you submit it for merge review.

Magnum/Acronyms

2015-03-22T09:03:12Z

P Rivera: /* Table of Acronyms */

Magnum

2015-03-22T08:45:26Z

P Rivera: /* Resources */

__TOC__

= News =

* 2015-03-20 We will be presenting [https://openstacksummitmay2015vancouver.sched.org/event/ec3936678ef22681408088ec52a4e80b a session on Magnum] at the 2015 OpenStack Summit in Vancouver on Thursday, May 21 9:00am - 9:40am US/Pacific.
* 2015-03-09 Our Kilo-2 release is now [https://github.com/stackforge/magnum/releases/tag/2015.1.0b2 available for download]
* 2015-01-20 We [http://lists.openstack.org/pipermail/openstack-dev/2015-January/054848.html have announced] Magnum's first release, now [https://github.com/stackforge/magnum/releases/tag/m1 available for download].

= Contributing =

* We want you to [[Magnum/Contributing|contribute to Magnum]]!

= Summary =

Magnum is an API service developed by the [[Teams/Containers|OpenStack Containers Team]] for OpenStack to make container management tools such as Docker and Kubernetes available as first class resources in OpenStack. Magnum uses Heat to orchestrate an OS image which contains Docker and Kubernetes and runs that image in either virtual machines or bare metal in a cluster configuration.

The project is under active development by our OpenStack Containers Team. We [[Meetings/Containers|meet weekly by IRC]]. Magnum's meetings are normally chaired by our PTL [https://launchpad.net/~aotto Adrian Otto].

= Resources =
* Launchpad Project Pages
** [http://launchpad.net/magnum Magnum Launchpad Project] for Blueprints
** [http://launchpad.net/python-magnumclient python-magnumclient Launchpad Project] for Blueprints
* Mailing List
** [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack Mailing List] for project related discussion
*** Add [Magnum] to the subject line of new posts about this project.
** [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing List Archives] for current discussion.
* Code Reviews
** [https://review.openstack.org/#/q/status:open+magnum,n,z Gerrit Reviews]
* Code Repository
** git clone git://git.openstack.org/stackforge/magnum
* Specification
** [https://review.openstack.org/136103 Containers Service Spec]
* References
**[[Magnum/Acronyms|Acronyms]]
**[http://eavesdrop.openstack.org/irclogs/%23openstack-containers/ IRC Logs - OpenStack Containers]
**[http://eavesdrop.openstack.org/meetings/containers/2015/ Meeting Minutes - OpenStack Containers]

= IRC =

Our developers use IRC in #openstack-containers on freenode for development discussion.

= Meetings =

* The weekly Containers [[Meetings/Containers|IRC meeting]] is held on Tuesdays at 1600 UTC and 2200 UTC on alternating weeks [[Meetings/Containers|[schedule]]].
* [http://eavesdrop.openstack.org/meetings/containers/2014/ 2014 Containers Meeting Archive]

= Frequently Asked Questions =
'''1) How is Magnum is different from Nova?'''

Magnum provides a purpose built API to manage application containers, which have a distinctly different life cycle and operations than Nova (machine) Instances. We actually use Nova instances to run our application containers.

'''2) How is Magnum different than Docker or Kubernetes?'''

Magnum offers an asynchronous API that's compatible with Keystone, and a complete multi-tenancy implementation. It does not perform orchestration
internally, and instead relies on OpenStack Orchestration. Magnum does leverage both Kubernetes and Docker as components.

'''3) Is this the same thing as Nova-Docker?'''

No, Nova-Docker is a virt driver for Nova that allows containers to be created as Nova instances. This is suitable for use cases when you want to treat a container like a lightweight machine. Magnum provides container specific features that are beyond the scope of Nova's API, and implements its own API to surface these features in a way that is consistent with other OpenStack services. Containers started by Magnum are run on top of Nova instances that are created using Heat.

'''4) Who is Magnum for?'''

Magnum is for OpenStack cloud operators (public or private) who want to offer a self-service solution to provide containers to their cloud users as a managed hosted service. Magnum simplifies the required integration with OpenStack, and allows for cloud users who can already launch cloud resources such as Nova Instances, Cinder Volumes, Trove Databases, etc. to also create application containers to run applications in an environment that provides advanced features that are beyond the scope of existing cloud resources. The same identity credentials used to create IaaS resources can be used to run containerized applications using Magnum. Some examples of advanced features available with Magnum are the ability to scale an application to a specified number of instances, to cause your application to automatically re-spawn an instance in the event of a failure, and to pack applications together more tightly than would be possible using Virtual Machines.

'''5) Will I get the same thing if I use the Docker resource in Heat?'''

No, the Docker Heat resource does not provide a resource scheduler, or a choice of container technology used. It is specific to Docker, and uses Glance to store container images. It does not currently allow for layered image features, which can cause containers to take longer to start than if layered images are used with a locally cached base image. Magnum leverages all of the speed benefits that Docker offers.

'''6) What does multi-tenancy mean in Magnum (Is Magnum Secure)?'''

Resources such as Containers, Services, Pods, Bays, etc. started by Magnum can only be viewed and accessed by users of the tenant that created them. Bays are not shared, meaning that containers will not run on the same kernel as neighboring tenants. This is a key security feature that allows containers belonging to the same tenant to be tightly packed within the same Pods and Bays, but runs separate kernels (in separate Nova Instances) between different tenants. This is different than using a system like Kubernetes without Magnum, which is intended to be used only by a single tenant, and leaves the security isolation design up to the implementer. Using Magnum provides the same level of security isolation as Nova provides when running Virtual Machines belonging to different tenants on the same compute nodes.

Magnum/Acronyms

2015-03-22T08:34:11Z

P Rivera: Creating Acronym subpage to Magnum main.

= Table of Acronyms =
{| class="wikitable sortable"
|-
! Acronym !! Full Name !! Notes / Helpful Links
|-
| IRC|| Internet Relay Chat || Our way of communicating via instant messages
|-
| ML || Mailing List || [[Magnum/Contributing#Sign_Up_for_the_OpenStack_Development_Mailing_List|OpenStack_Development_Mailing_List]]
|-
| TBD || To Be Determined ||
|}

Magnum

2015-03-22T08:17:43Z

P Rivera: /* Resources */

__TOC__

= News =

* 2015-03-20 We will be presenting [https://openstacksummitmay2015vancouver.sched.org/event/ec3936678ef22681408088ec52a4e80b a session on Magnum] at the 2015 OpenStack Summit in Vancouver on Thursday, May 21 9:00am - 9:40am US/Pacific.
* 2015-03-09 Our Kilo-2 release is now [https://github.com/stackforge/magnum/releases/tag/2015.1.0b2 available for download]
* 2015-01-20 We [http://lists.openstack.org/pipermail/openstack-dev/2015-January/054848.html have announced] Magnum's first release, now [https://github.com/stackforge/magnum/releases/tag/m1 available for download].

= Contributing =

* We want you to [[Magnum/Contributing|contribute to Magnum]]!

= Summary =

Magnum is an API service developed by the [[Teams/Containers|OpenStack Containers Team]] for OpenStack to make container management tools such as Docker and Kubernetes available as first class resources in OpenStack. Magnum uses Heat to orchestrate an OS image which contains Docker and Kubernetes and runs that image in either virtual machines or bare metal in a cluster configuration.

The project is under active development by our OpenStack Containers Team. We [[Meetings/Containers|meet weekly by IRC]]. Magnum's meetings are normally chaired by our PTL [https://launchpad.net/~aotto Adrian Otto].

= Resources =
* Launchpad Project Pages
** [http://launchpad.net/magnum Magnum Launchpad Project] for Blueprints
** [http://launchpad.net/python-magnumclient python-magnumclient Launchpad Project] for Blueprints
* Mailing List
** [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack Mailing List] for project related discussion
*** Add [Magnum] to the subject line of new posts about this project.
** [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing List Archives] for current discussion.
* Code Reviews
** [https://review.openstack.org/#/q/status:open+magnum,n,z Gerrit Reviews]
* Code Repository
** git clone git://git.openstack.org/stackforge/magnum
* Specification
** [https://review.openstack.org/136103 Containers Service Spec]
* References
**[[Magnum/Acronyms|Acronyms]]

= IRC =

Our developers use IRC in #openstack-containers on freenode for development discussion.

= Meetings =

* The weekly Containers [[Meetings/Containers|IRC meeting]] is held on Tuesdays at 1600 UTC and 2200 UTC on alternating weeks [[Meetings/Containers|[schedule]]].
* [http://eavesdrop.openstack.org/meetings/containers/2014/ 2014 Containers Meeting Archive]

= Frequently Asked Questions =
'''1) How is Magnum is different from Nova?'''

Magnum provides a purpose built API to manage application containers, which have a distinctly different life cycle and operations than Nova (machine) Instances. We actually use Nova instances to run our application containers.

'''2) How is Magnum different than Docker or Kubernetes?'''

Magnum offers an asynchronous API that's compatible with Keystone, and a complete multi-tenancy implementation. It does not perform orchestration
internally, and instead relies on OpenStack Orchestration. Magnum does leverage both Kubernetes and Docker as components.

'''3) Is this the same thing as Nova-Docker?'''

No, Nova-Docker is a virt driver for Nova that allows containers to be created as Nova instances. This is suitable for use cases when you want to treat a container like a lightweight machine. Magnum provides container specific features that are beyond the scope of Nova's API, and implements its own API to surface these features in a way that is consistent with other OpenStack services. Containers started by Magnum are run on top of Nova instances that are created using Heat.

'''4) Who is Magnum for?'''

Magnum is for OpenStack cloud operators (public or private) who want to offer a self-service solution to provide containers to their cloud users as a managed hosted service. Magnum simplifies the required integration with OpenStack, and allows for cloud users who can already launch cloud resources such as Nova Instances, Cinder Volumes, Trove Databases, etc. to also create application containers to run applications in an environment that provides advanced features that are beyond the scope of existing cloud resources. The same identity credentials used to create IaaS resources can be used to run containerized applications using Magnum. Some examples of advanced features available with Magnum are the ability to scale an application to a specified number of instances, to cause your application to automatically re-spawn an instance in the event of a failure, and to pack applications together more tightly than would be possible using Virtual Machines.

'''5) Will I get the same thing if I use the Docker resource in Heat?'''

No, the Docker Heat resource does not provide a resource scheduler, or a choice of container technology used. It is specific to Docker, and uses Glance to store container images. It does not currently allow for layered image features, which can cause containers to take longer to start than if layered images are used with a locally cached base image. Magnum leverages all of the speed benefits that Docker offers.

'''6) What does multi-tenancy mean in Magnum (Is Magnum Secure)?'''

Resources such as Containers, Services, Pods, Bays, etc. started by Magnum can only be viewed and accessed by users of the tenant that created them. Bays are not shared, meaning that containers will not run on the same kernel as neighboring tenants. This is a key security feature that allows containers belonging to the same tenant to be tightly packed within the same Pods and Bays, but runs separate kernels (in separate Nova Instances) between different tenants. This is different than using a system like Kubernetes without Magnum, which is intended to be used only by a single tenant, and leaves the security isolation design up to the implementer. Using Magnum provides the same level of security isolation as Nova provides when running Virtual Machines belonging to different tenants on the same compute nodes.

Magnum/Contributing

2015-03-19T03:11:56Z

P Rivera: /* Write some awesome code */

__TOC__

= Before You Begin =
To familiarize yourself with Magnum, try it out using the information in our [http://git.openstack.org/cgit/stackforge/magnum/tree/doc/source/dev/dev-quickstart.rst Dev Quickstart Guide]. When you are ready to start contributing, you will need to execute an [[How_To_Contribute#Contributors_License_Agreement|OpenStack CLA]]. This is required before you can submit reviews to our [https://github.com/stackforge/magnum Magnum Repo]. For information about how prepare for contribution, please consult the [[How_To_Contribute |How To Contribute]] wiki page.

== Sign Up for the OpenStack Development Mailing List ==
Head on over to [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack Dev Mailing List], fill out the fields under "Subscribing to OpenStack-dev" and click Subscribe.

== Learn About Gerrit ==
Be sure to read the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide] for information about how to submit your commit for review so it can be merged into the Magnum code base.

If you do not have a gerrit username setup or do not remember it,
verify and configure it here: https://review.openstack.org/#/settings/

Keep that handy for the "git review -s" command later in the https://wiki.openstack.org/wiki/Magnum/Contributing#Setting_up_your_git_review_settings and https://wiki.openstack.org/wiki/Magnum/Contributing#Set_up_your_local_branch sections below...

You'll also need to upload an SSH public key, specifically for Gerrit:
https://review.openstack.org/#/settings/ssh-keys

== Setting up your git review settings ==
New to git? Try the 15-minute high-level interactive Git demo [http://try.github.com/ GitHub Demo]

Need a git refresher? Download a git reference direct from the source: [https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf GitHub Git Cheat Sheet]

Then:

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"

In the event your launchpad and gerrit usernames are identical:
git config --global gitreview.username "your_launchpad_username"
In the event your launchpad and gerrit usernames are not identical:
git config --global gitreview.username "your_gerrit_username"

To check your git configuration:

git config --list

== Installing git-review ==
On Ubuntu, MacOSx, or most other Unix-like systems, it is as simple as:
pip install git-review

There are other installation options detailed in the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide]. You can now check out the Magnum code and begin working on it:

= Your first commit =

== Set up your local branch ==

git clone git://git.openstack.org/stackforge/magnum
cd magnum
git checkout -b [branch name]
git review -s

If you receive the following error when running the "git review -s" command:
We don't know where your gerrit is. Please manually create a remote
named "gerrit" and try again.

Perform the following (substituting <your gerrit username> with your specific gerrit username...):
git remote add gerrit ssh://<your gerrit username>@review.openstack.org:29418/stackforge/magnum.git
git review -s

If you receive the following error when running the "git review -s" command:
Agent admitted failure to sign using the key

See this support page: https://help.github.com/articles/error-agent-admitted-failure-to-sign/

== Identify bugs ==
Observe a bug? Report it here: https://launchpad.net/magnum
# Click the '''Report a Bug''' button.
# Enter a Summary in the field and click Next. Here's an example: Stale link to Gerrit Workflow
# Review the choices you've been given. If you spot your bug, click on the bug and review its status; proceed to the awesome code section below if there's more to do.. If you do not spot your bug, proceed to the next step.
# Click the '''No, I need to report a new bug''' button.
# Type in a detailed description of the bug in the "Further information" field and click '''Submit bug report'''. Here's an example description for our previous example: In doc/source/dev/dev-quickstart.rst the link to the Gerrit workflow is incorrect. It should be: http://docs.openstack.org/infra/manual/developers.html

== Write some awesome code ==

At this point can write your code and push it to Gerrit for review.

git add <list of files you added/changed>

If you submitted a bug in the previous section, be sure to add the bug link in the commit message.

Each commit line should conform with the OpenStack style guidelines. Some highlights:
# The first line of the commit message should be <=50 characters.
# The subsequent lines can be <= 78 characters.
# Lines 2 onward are a blank line followed by a more verbose description of the first commit line (as needed).
# The last commit line needs to link to either a blueprint or bug/task ticket number.
# There should be no whitespace at the end of all lines.

For the example case:
Adjust Gerrit workflow Link
<blank line>
The Gerrit workflow link in the previous version is no longer valid.
This patch updates documentation to the current link.
<blank line>
Closes-bug: <bug/task ticket number>

Then,

git commit -a
git review -v --draft

Once you are happy with your code and want it to be reviewed you want to convert it from a Draft. "Sign In" at https://review.openstack.org/ and after verifying the review yourself hit the "Publish" button on the page.

If you know you are ready for others to review your code, you can skip the draft step and just do:
git review -v

By this point, your code will be reviewed by the Openstack automatic testing frameworks and, potentially, your peers on the project.

If you want to revise your patchset in the review system in response to feedback, make your changes, then use:
git commit -a --amend
git review -v

Upon approval of the review your code will be automatically merged.

= How to Resolve Merge Conflicts =

If another patch changes the same line of code as your patch, and it gets merged before yours, your patch may get a <code>patch in merge conflict</code> status in red. If that happens, here is how you can resolve it. You will need the patch number from the Gerrit URL https://review.openstack.org/NNNNN to make your rebase a revision of the previous review.

git clone https://github.com/stackforge/magnum
cd magnum
git review -d NNNNN
git rebase master

Now edit all files with merge conflicts to resolve them by making the code look the way it should both with the recently merged code, and your own. Then <code>git add</code> each of the files you edited.

git add path/to/file/you/edited
git rebase --continue
git review -v

That will resubmit your patch with the original commit message, and the rebased code with your merge fix as a new patch set.

= Reviews =

The OpenStack CI system uses the concept of core reviewers. These are individuals who have consistently reviewed code for the project, and helped over a considerable period of time to improve the quality and consistency of what we merge into the code base. Project contributors will feel that this reviewer is a positive influence on the team and that they maintain the values and traditions of the OpenStack development community.

== Policies ==
Existing core reviewers may nominate new ones in an ML thread. Consent among the current reviewers shall result in the declaration of the new core reviewer by the PTL. Lack of unanimous consent shall be carefully considered, and a final decision informed by input from from active team members shall be made by the PTL. Core reviewers who are judged by their peers in the core review group to fall short of the expectations for contribution of a core reviewer may be nominated for return to regular reviewer status.

Patches require a core reviewer to mark a review as "Approved" before they are merged.

== Review Guidelines ==
=== Code Approval for Merge ===
* For Approval, two core reviewers shall supply a <code>+2</code>.
=== Continuing Someone Else's Contribution ===
* If a patch submitted by one contributor is picked up and completed by another contributor, [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg05998.html special handling] of the resolution should be used.
=== Advice for Reviewers ===
* A <code>-1</code> vote is an opportunity to make our code better before it is merged. Please do your best to make helpful, actionable -1 votes.
* Avoid the temptation to blindly <code>+1</code> code without reviewing it in sufficient detail to form an opinion.
* When voting <code>-1</code> on a patch, it means that you want the submitter to make a revision in accordance with your feedback before core reviewers should consider this code for merge.
* If you ask a question, you should vote <code>0</code> unless you anticipate that the answer to that question is likely to cause you to vote against the patch without further revisions.
* If you use a <code>-1</code> vote for a question, and the contributor answers the question, please respond acknowledging the question. Either change your vote or follow up with additional rationale for why this should remain a <code>-1</code> comment.
* A <code>-2</code> vote is a veto by a single core reviewer. It is sticky. That means that even if you revise your patch, that vote will persist. To allow your patch to merge, that same reviewer must clear the <code>-2</code> vote first. This vote is used when you have contributed something that is not in alignment with the current project vision, or is implemented in a way that can not be accepted. For example, security concerns that a core reviewer wants to individually re-evaluate before allowing the contribution to continue. It can also be used as a way to halt further gate testing of a patch, if something is included that may break the gate. It works even after a <code>2*+2,+A</code> approval for merge, but before the patch reaches MERGED state.
* To avoid a <code>-2</code> vote, discuss your plans with the development team prior to writing code, and post a WIP (workflow-1) patch while you are working on it, and ask for input before you submit it for merge review.

Magnum/Contributing

2015-03-19T02:36:05Z

P Rivera: /* Write some awesome code */

__TOC__

= Before You Begin =
To familiarize yourself with Magnum, try it out using the information in our [http://git.openstack.org/cgit/stackforge/magnum/tree/doc/source/dev/dev-quickstart.rst Dev Quickstart Guide]. When you are ready to start contributing, you will need to execute an [[How_To_Contribute#Contributors_License_Agreement|OpenStack CLA]]. This is required before you can submit reviews to our [https://github.com/stackforge/magnum Magnum Repo]. For information about how prepare for contribution, please consult the [[How_To_Contribute |How To Contribute]] wiki page.

== Sign Up for the OpenStack Development Mailing List ==
Head on over to [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack Dev Mailing List], fill out the fields under "Subscribing to OpenStack-dev" and click Subscribe.

== Learn About Gerrit ==
Be sure to read the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide] for information about how to submit your commit for review so it can be merged into the Magnum code base.

If you do not have a gerrit username setup or do not remember it,
verify and configure it here: https://review.openstack.org/#/settings/

Keep that handy for the "git review -s" command later in the https://wiki.openstack.org/wiki/Magnum/Contributing#Setting_up_your_git_review_settings and https://wiki.openstack.org/wiki/Magnum/Contributing#Set_up_your_local_branch sections below...

You'll also need to upload an SSH public key, specifically for Gerrit:
https://review.openstack.org/#/settings/ssh-keys

== Setting up your git review settings ==
New to git? Try the 15-minute high-level interactive Git demo [http://try.github.com/ GitHub Demo]

Need a git refresher? Download a git reference direct from the source: [https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf GitHub Git Cheat Sheet]

Then:

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"

In the event your launchpad and gerrit usernames are identical:
git config --global gitreview.username "your_launchpad_username"
In the event your launchpad and gerrit usernames are not identical:
git config --global gitreview.username "your_gerrit_username"

To check your git configuration:

git config --list

== Installing git-review ==
On Ubuntu, MacOSx, or most other Unix-like systems, it is as simple as:
pip install git-review

There are other installation options detailed in the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide]. You can now check out the Magnum code and begin working on it:

= Your first commit =

== Set up your local branch ==

git clone git://git.openstack.org/stackforge/magnum
cd magnum
git checkout -b [branch name]
git review -s

If you receive the following error when running the "git review -s" command:
We don't know where your gerrit is. Please manually create a remote
named "gerrit" and try again.

Perform the following (substituting <your gerrit username> with your specific gerrit username...):
git remote add gerrit ssh://<your gerrit username>@review.openstack.org:29418/stackforge/magnum.git
git review -s

If you receive the following error when running the "git review -s" command:
Agent admitted failure to sign using the key

See this support page: https://help.github.com/articles/error-agent-admitted-failure-to-sign/

== Identify bugs ==
Observe a bug? Report it here: https://launchpad.net/magnum
# Click the '''Report a Bug''' button.
# Enter a Summary in the field and click Next. Here's an example: Stale link to Gerrit Workflow
# Review the choices you've been given. If you spot your bug, click on the bug and review its status; proceed to the awesome code section below if there's more to do.. If you do not spot your bug, proceed to the next step.
# Click the '''No, I need to report a new bug''' button.
# Type in a detailed description of the bug in the "Further information" field and click '''Submit bug report'''. Here's an example description for our previous example: In doc/source/dev/dev-quickstart.rst the link to the Gerrit workflow is incorrect. It should be: http://docs.openstack.org/infra/manual/developers.html

== Write some awesome code ==

At this point can write your code and push it to Gerrit for review.

git add <list of files you added/changed>

If you submitted a bug in the previous section, be sure to add the bug link in the commit message.

Each commit line should conform with the OpenStack style guidelines. Some highlights:
# The first line of the commit message should be <=50 characters.
# The subsequent lines can be <= 78 characters.
# Lines 2 onward are a blank line followed by a more verbose description of the first commit line (as needed).
# The last commit line needs to link to either a blueprint or bug/task ticket number.
# There should be no whitespace at the end of all lines.

For the example case:
Adjust Gerrit workflow Link
<blank line>
The Gerrit workflow link in the previous version is no longer valid.
This patch updates documentation to the current link.
<blank line>
Closes-bug: 1433709

Then,

git commit -a
git review -v --draft

Once you are happy with your code and want it to be reviewed you want to convert it from a Draft. "Sign In" at https://review.openstack.org/ and after verifying the review yourself hit the "Publish" button on the page.

If you know you are ready for others to review your code, you can skip the draft step and just do:
git review -v

By this point, your code will be reviewed by the Openstack automatic testing frameworks and, potentially, your peers on the project.

If you want to revise your patchset in the review system in response to feedback, make your changes, then use:
git commit -a --amend
git review -v

Upon approval of the review your code will be automatically merged.

= How to Resolve Merge Conflicts =

If another patch changes the same line of code as your patch, and it gets merged before yours, your patch may get a <code>patch in merge conflict</code> status in red. If that happens, here is how you can resolve it. You will need the patch number from the Gerrit URL https://review.openstack.org/NNNNN to make your rebase a revision of the previous review.

git clone https://github.com/stackforge/magnum
cd magnum
git review -d NNNNN
git rebase master

Now edit all files with merge conflicts to resolve them by making the code look the way it should both with the recently merged code, and your own. Then <code>git add</code> each of the files you edited.

git add path/to/file/you/edited
git rebase --continue
git review -v

That will resubmit your patch with the original commit message, and the rebased code with your merge fix as a new patch set.

= Reviews =

The OpenStack CI system uses the concept of core reviewers. These are individuals who have consistently reviewed code for the project, and helped over a considerable period of time to improve the quality and consistency of what we merge into the code base. Project contributors will feel that this reviewer is a positive influence on the team and that they maintain the values and traditions of the OpenStack development community.

== Policies ==
Existing core reviewers may nominate new ones in an ML thread. Consent among the current reviewers shall result in the declaration of the new core reviewer by the PTL. Lack of unanimous consent shall be carefully considered, and a final decision informed by input from from active team members shall be made by the PTL. Core reviewers who are judged by their peers in the core review group to fall short of the expectations for contribution of a core reviewer may be nominated for return to regular reviewer status.

Patches require a core reviewer to mark a review as "Approved" before they are merged.

== Review Guidelines ==
=== Code Approval for Merge ===
* For Approval, two core reviewers shall supply a <code>+2</code>.
=== Continuing Someone Else's Contribution ===
* If a patch submitted by one contributor is picked up and completed by another contributor, [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg05998.html special handling] of the resolution should be used.
=== Advice for Reviewers ===
* A <code>-1</code> vote is an opportunity to make our code better before it is merged. Please do your best to make helpful, actionable -1 votes.
* Avoid the temptation to blindly <code>+1</code> code without reviewing it in sufficient detail to form an opinion.
* When voting <code>-1</code> on a patch, it means that you want the submitter to make a revision in accordance with your feedback before core reviewers should consider this code for merge.
* If you ask a question, you should vote <code>0</code> unless you anticipate that the answer to that question is likely to cause you to vote against the patch without further revisions.
* If you use a <code>-1</code> vote for a question, and the contributor answers the question, please respond acknowledging the question. Either change your vote or follow up with additional rationale for why this should remain a <code>-1</code> comment.
* A <code>-2</code> vote is a veto by a single core reviewer. It is sticky. That means that even if you revise your patch, that vote will persist. To allow your patch to merge, that same reviewer must clear the <code>-2</code> vote first. This vote is used when you have contributed something that is not in alignment with the current project vision, or is implemented in a way that can not be accepted. For example, security concerns that a core reviewer wants to individually re-evaluate before allowing the contribution to continue. It can also be used as a way to halt further gate testing of a patch, if something is included that may break the gate. It works even after a <code>2*+2,+A</code> approval for merge, but before the patch reaches MERGED state.
* To avoid a <code>-2</code> vote, discuss your plans with the development team prior to writing code, and post a WIP (workflow-1) patch while you are working on it, and ask for input before you submit it for merge review.

Magnum/Contributing

2015-03-19T02:16:53Z

P Rivera: /* Your first commit */

__TOC__

= Before You Begin =
To familiarize yourself with Magnum, try it out using the information in our [http://git.openstack.org/cgit/stackforge/magnum/tree/doc/source/dev/dev-quickstart.rst Dev Quickstart Guide]. When you are ready to start contributing, you will need to execute an [[How_To_Contribute#Contributors_License_Agreement|OpenStack CLA]]. This is required before you can submit reviews to our [https://github.com/stackforge/magnum Magnum Repo]. For information about how prepare for contribution, please consult the [[How_To_Contribute |How To Contribute]] wiki page.

== Sign Up for the OpenStack Development Mailing List ==
Head on over to [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack Dev Mailing List], fill out the fields under "Subscribing to OpenStack-dev" and click Subscribe.

== Learn About Gerrit ==
Be sure to read the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide] for information about how to submit your commit for review so it can be merged into the Magnum code base.

If you do not have a gerrit username setup or do not remember it,
verify and configure it here: https://review.openstack.org/#/settings/

Keep that handy for the "git review -s" command later in the https://wiki.openstack.org/wiki/Magnum/Contributing#Setting_up_your_git_review_settings and https://wiki.openstack.org/wiki/Magnum/Contributing#Set_up_your_local_branch sections below...

You'll also need to upload an SSH public key, specifically for Gerrit:
https://review.openstack.org/#/settings/ssh-keys

== Setting up your git review settings ==
New to git? Try the 15-minute high-level interactive Git demo [http://try.github.com/ GitHub Demo]

Need a git refresher? Download a git reference direct from the source: [https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf GitHub Git Cheat Sheet]

Then:

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"

In the event your launchpad and gerrit usernames are identical:
git config --global gitreview.username "your_launchpad_username"
In the event your launchpad and gerrit usernames are not identical:
git config --global gitreview.username "your_gerrit_username"

To check your git configuration:

git config --list

== Installing git-review ==
On Ubuntu, MacOSx, or most other Unix-like systems, it is as simple as:
pip install git-review

There are other installation options detailed in the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide]. You can now check out the Magnum code and begin working on it:

= Your first commit =

== Set up your local branch ==

git clone git://git.openstack.org/stackforge/magnum
cd magnum
git checkout -b [branch name]
git review -s

If you receive the following error when running the "git review -s" command:
We don't know where your gerrit is. Please manually create a remote
named "gerrit" and try again.

Perform the following (substituting <your gerrit username> with your specific gerrit username...):
git remote add gerrit ssh://<your gerrit username>@review.openstack.org:29418/stackforge/magnum.git
git review -s

If you receive the following error when running the "git review -s" command:
Agent admitted failure to sign using the key

See this support page: https://help.github.com/articles/error-agent-admitted-failure-to-sign/

== Identify bugs ==
Observe a bug? Report it here: https://launchpad.net/magnum
# Click the '''Report a Bug''' button.
# Enter a Summary in the field and click Next. Here's an example: Stale link to Gerrit Workflow
# Review the choices you've been given. If you spot your bug, click on the bug and review its status; proceed to the awesome code section below if there's more to do.. If you do not spot your bug, proceed to the next step.
# Click the '''No, I need to report a new bug''' button.
# Type in a detailed description of the bug in the "Further information" field and click '''Submit bug report'''. Here's an example description for our previous example: In doc/source/dev/dev-quickstart.rst the link to the Gerrit workflow is incorrect. It should be: http://docs.openstack.org/infra/manual/developers.html

== Write some awesome code ==

At this point can write your code and push it to Gerrit for review.

git add <list of files you added/changed>

If you submitted a bug in the previous section, be sure to add the bug link in the commit message.
Be sure to split the commit line so that it doesn't exceed 50 characters.

Then,

git commit -a
git review -v --draft

Once you are happy with your code and want it to be reviewed you want to convert it from a Draft. "Sign In" at https://review.openstack.org/ and after verifying the review yourself hit the "Publish" button on the page.

If you know you are ready for others to review your code, you can skip the draft step and just do:
git review -v

By this point, your code will be reviewed by the Openstack automatic testing frameworks and, potentially, your peers on the project.

If you want to revise your patchset in the review system in response to feedback, make your changes, then use:
git commit -a --amend
git review -v

Upon approval of the review your code will be automatically merged.

= How to Resolve Merge Conflicts =

If another patch changes the same line of code as your patch, and it gets merged before yours, your patch may get a <code>patch in merge conflict</code> status in red. If that happens, here is how you can resolve it. You will need the patch number from the Gerrit URL https://review.openstack.org/NNNNN to make your rebase a revision of the previous review.

git clone https://github.com/stackforge/magnum
cd magnum
git review -d NNNNN
git rebase master

Now edit all files with merge conflicts to resolve them by making the code look the way it should both with the recently merged code, and your own. Then <code>git add</code> each of the files you edited.

git add path/to/file/you/edited
git rebase --continue
git review -v

That will resubmit your patch with the original commit message, and the rebased code with your merge fix as a new patch set.

= Reviews =

The OpenStack CI system uses the concept of core reviewers. These are individuals who have consistently reviewed code for the project, and helped over a considerable period of time to improve the quality and consistency of what we merge into the code base. Project contributors will feel that this reviewer is a positive influence on the team and that they maintain the values and traditions of the OpenStack development community.

== Policies ==
Existing core reviewers may nominate new ones in an ML thread. Consent among the current reviewers shall result in the declaration of the new core reviewer by the PTL. Lack of unanimous consent shall be carefully considered, and a final decision informed by input from from active team members shall be made by the PTL. Core reviewers who are judged by their peers in the core review group to fall short of the expectations for contribution of a core reviewer may be nominated for return to regular reviewer status.

Patches require a core reviewer to mark a review as "Approved" before they are merged.

== Review Guidelines ==
=== Code Approval for Merge ===
* For Approval, two core reviewers shall supply a <code>+2</code>.
=== Continuing Someone Else's Contribution ===
* If a patch submitted by one contributor is picked up and completed by another contributor, [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg05998.html special handling] of the resolution should be used.
=== Advice for Reviewers ===
* A <code>-1</code> vote is an opportunity to make our code better before it is merged. Please do your best to make helpful, actionable -1 votes.
* Avoid the temptation to blindly <code>+1</code> code without reviewing it in sufficient detail to form an opinion.
* When voting <code>-1</code> on a patch, it means that you want the submitter to make a revision in accordance with your feedback before core reviewers should consider this code for merge.
* If you ask a question, you should vote <code>0</code> unless you anticipate that the answer to that question is likely to cause you to vote against the patch without further revisions.
* If you use a <code>-1</code> vote for a question, and the contributor answers the question, please respond acknowledging the question. Either change your vote or follow up with additional rationale for why this should remain a <code>-1</code> comment.
* A <code>-2</code> vote is a veto by a single core reviewer. It is sticky. That means that even if you revise your patch, that vote will persist. To allow your patch to merge, that same reviewer must clear the <code>-2</code> vote first. This vote is used when you have contributed something that is not in alignment with the current project vision, or is implemented in a way that can not be accepted. For example, security concerns that a core reviewer wants to individually re-evaluate before allowing the contribution to continue. It can also be used as a way to halt further gate testing of a patch, if something is included that may break the gate. It works even after a <code>2*+2,+A</code> approval for merge, but before the patch reaches MERGED state.
* To avoid a <code>-2</code> vote, discuss your plans with the development team prior to writing code, and post a WIP (workflow-1) patch while you are working on it, and ask for input before you submit it for merge review.