OpenStack - User contributions [en]

Meetings

2014-01-21T22:11:53Z

Dripton: removed DB team meeting, which hasn't been happening, to free up the time slot

The OpenStack project holds its various public meetings on '''IRC''', in the <code><nowiki>#openstack-meeting</nowiki></code> and <code><nowiki>#openstack-meeting-alt</nowiki></code> channels on Freenode. Everyone is encouraged to attend.

You can also access the [https://www.google.com/calendar/ical/bj05mroquq28jhud58esggqmh4@group.calendar.google.com/public/basic.ics iCal feed for all OpenStack meetings].

== OpenStack Project & Release Status meeting ==
* Weekly on Tuesdays at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[ThierryCarrez]]
* See [[Meetings/ProjectMeeting]] for details

== Technical Committee meeting ==
* Weekly on Tuesdays at 2000 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[ThierryCarrez]]
* See [[Governance/TechnicalCommittee]] for details

== OpenStack Compute (Nova) ==
=== Nova team Meeting ===
* Weekly on Thursdays, alternating times - 1400 UTC and 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> (1400 UTC)
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> (2100 UTC)
* Chair (to contact for more information): Russell Bryant
* See [[Meetings/Nova]] for an agenda

=== XenAPI team meeting ===
* Weekly on Wednesdays at 1500 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by: [[JohnGarbutt]]
* See [[Meetings/XenAPI]] for agenda

=== Nova Hyper-V team meeting ===
* Weekly on Tuesdays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by primeministerp (Peter Pouliot)

=== Scheduler Sub-group meeting ===
* Weekly on Tuesdays at 1500 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): n0ano (Don Dugger)
* See [[Meetings/Scheduler]] for details

=== VMwareAPI team meeting ===
* Weekly on Wednesdays at 1700 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: [[ShawnHartsock]]
* See [[Meetings/VMwareAPI]] for details

=== PCI Passthrough Meeting ===
* Weekly on Monday, Tuesday, Wednesday and Thursday at [http://www.worldclock.com/world_clock.html 1300 UTC]
* Will change back to once weekly after agreements are reached.
* IRC channel: #openstack-meeting-alt
* Chair: baoli (Robert Li)
* See [[Meetings/Passthrough]] for details

== Documentation team meeting ==
* Every other Tuesday at 1300 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[AnneGentle]]
* See [[Meetings/DocTeamMeeting]] for an agenda

== Project Infrastructure team meeting ==
* Weekly on Tuesdays at 1900 UTC
* IRC channel: #openstack-meeting
* Chair (to contact for more information): [[User:Corvus|James E. Blair (jeblair)]]
* See [[Meetings/InfraTeamMeeting]] for an agenda

== QA team meeting ==
* Weekly on Thursdays at 1700/2200 UTC (alternating)
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): Matt Treinish
* See [[Meetings/QATeamMeeting]] for an agenda

== State management team meeting ==
* Weekly on Thursdays at 2000 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130502T2000)
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[Harlowja]]
* See [[Meetings/StateManagement]] for an agenda

== Keystone team meeting ==
* Weekly on Tuesdays at 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[DolphMathews]]
* See [[Meetings/KeystoneMeeting]] for an agenda

== Ironic (Bare Metal) team meeting ==
* Weekly on Mondays at 1900 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more infomation) Devananda van der Veen
* see [[Meetings/Ironic]] for agenda

== TripleO team meeting ==
* Weekly on Tuesdays at 1900 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more infomation) Robert Collins (lifeless)
* see [[Meetings/TripleO]] for agenda

== OpenStack Networking (Neutron) ==
=== Neutron team meeting ===
* Weekly on Mondays at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more infomation) Mark McClain
* see [[Network/Meetings]] for agenda

=== LBaaS meeting ===
* Weekly on Thursdays at 1400 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>

=== ML2 Network sub-team meeting ===
* Weekly on Wednesdays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): mestery (Kyle Mestery)
* See [[Meetings/ML2]] for details

=== Firewall as a Service (FWaaS) team meeting ===
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1800 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: snaiksat (Sumit Naiksatam)
* See [[Meetings/FWaaS]] for details

=== Neutron Advanced Services' Common requirements team meeting ===
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1900 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: snaiksat (Sumit Naiksatam)
* See [[Meetings/AdvancedServices]] for details

=== Neutron IPv6 sub-team Meeting ===
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1400 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sc68cal (Sean M. Collins)
* See [[Meetings/Neutron-IPv6-Subteam]] for details

=== Neutron Group Policy Sub-Team Meeting ===
* Weekly on Thursdays at 1600 UTC
* IRC channel: #openstack-meeting-alt
* Chair: mestery (Kyle Mestery)
* See [[Meetings/Neutron_Group_Policy]] for details

=== Neutron Distributed Virtual Router meeting ===
* Weekly on Mondays at [http://www.worldclock.com/world_clock.html 2200 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* To accomodate people in Asia
* Alternate meetings on Wednesdays at [http://www.worldclock.com/world_clock.html 1500 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair:Swami (Swaminathan Vasudevan)
* See [[Meetings/Distributed-Virtual-Router]] for details

=== Neutron blueprint ovs-firewall-driver Meeting ===
* Tentative: Monday, December 16 at 2000 UTC
* IRC channel: #openstack-meeting
* Chair: asadoughi (Amir Sadoughi)
* Agenda: See [[Meetings/Neutron_blueprint_ovs-firewall-driver]]

== Cinder team meeting ==
* Weekly on Wednesdays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by [[JohnGriffith]]
* see [[CinderMeetings]] for agenda

== Ceilometer team meeting ==
* Even weeks on Thursdays at 1500 UTC.
* Odd weeks on Wednesdays at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by jd__ (Julien Danjou)
* see [[Meetings/Ceilometer]] for details

== Designate (DNSaaS) meeting ==
* Weekly Wednesdays at 1700 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): Kiall Mac Innes (kiall)
* See [[Meetings/Designate]] for details

== Trove (DBaaS) meeting ==
* Weekly on Wednesdays at 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): Michael Basnight (hub_cap) / Vipul Sabhaya (vipul) / Nikhil Manchanda (SlickNik) / Tim Simpson (grapex)
* See [[Meetings/TroveMeeting]] for details

== Marconi (queues) team meeting ==
* Weekly on Tuesday at 1500 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: kgriffs (Kurt Griffiths)
* See [[Meetings/Marconi]] for details

== Savanna team meeting ==
* Weekly on Thursdays at 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more info): SergeyLukjanov (Sergey Lukjanov)
* See [[Meetings/SavannaAgenda]] for details

== Mistral meeting ==
* Weekly on Mondays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: rakhmerov (Renat Akhmerov)
* See [[Meetings/MistralAgenda]] for details

== Murano meeting ==
* Weekly on Tuesday at 1700 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: Georgiy Okrokvertskhov (Georgy_Ok)
* See [[Meetings/MuranoAgenda]] for details

== Heat (orchestration) team meeting ==
* Weekly on Wednesdays at 2000 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): Steve Baker (stevebaker)
* See [[Meetings/HeatAgenda]] for details

== Horizon team meeting ==
* Weekly on Tuesdays at 2200 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: David Lyle (david-lyle)
* See [[Meetings/Horizon]] for details

== Swift team meeting ==
* Bi-Weekly (every other week) on Wednesdays at 1900 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: notmyname (John Dickinson)
* See [[Meetings/Swift]] for details

== OpenStack Security Group (OSSG) meeting ==
* Weekly on Thursdays at 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): bdpayne (Bryan Payne)
* See [[Meetings/OpenStackSecurity]] for an agenda

== Python3 Compatibility Team meeting ==
* Not planned anymore
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): jd_ (Julien Danjou)
* See [[Meetings/Python3]] for details

== Glance Team meeting ==
* Weekly on Thursdays at 1400/2000 UTC (alternating)
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): markwash (Mark Washenberger)
* See [[Meetings/Glance]] for details

== Oslo Team meeting ==
* On demand on Fridays at 1400 UTC (see [http://www.doodle.com/vbs7ux7m4pa3c6c5 this doodle])
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): markmc (Mark McLoughlin)
* See [[Meetings/Oslo]] for details

== OpenStack Community team meeting ==
* Weekly on Wednesday at [http://www.worldclock.com/world_clock.html 2300 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: reed ([http://www.openstack.org/community/members/profile/1372 Stefano Maffulli])
* See [[Meetings/Community]] for details

== I18N Team meeting ==
* Weekly on Thursday, alternating between 0100 UTC and 0700 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: daisy
* See [[Meetings/I18nTeamMeeting]] for details

== Training-manuals Team meeting ==
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 1700 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sarob
* See [[Meetings/training-manuals]] for details

== Manila Team meeting ==
* Weekly on Thursday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 1500 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: bswartz
* See [[ManilaMeetings]] for details

== Stackalytics team meeting ==
* Be-Weekly on Mondays (starting from October 21st) at [http://www.worldclock.com/world_clock.html 1500 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: ilyashakhat (Ilya Shakhat)
* See [[Meetings/Stackalytics]] for details

== Climate (Reservations) team meeting ==
* Weekly on Fridays at [http://www.worldclock.com/world_clock.html 1500 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: bauzas (Sylvain Bauza), DinaBelova (Dina Belova)
* See [[Meetings/Climate]] for details

== Rally meeting ==
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1700 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair:boris-42 (Boris Pavlovic)
* See [[Meetings/Rally]] for details

== Solum Team Meeting ==
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1600 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: adrian_otto (Adrian Otto)
* See [[Meetings/Solum]] for details

== Congress Team Meeting ==
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1800 UTC]
* IRC channel: #openstack-meeting-alt
* Chair: pballand (Pete Balland)
* See [[Meetings/Congress]] for details

== Barbican Meeting ==
* Weekly on Mondays at [http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130502T2000 2000 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): jraim (#openstack-barbican @ Freenode)
* See [[Meetings/Barbican]] for an agenda

== Chef Cookbook meeting ==
* Weekly on Mondays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-chef</nowiki></code>
* Chair: mattray (Matt Ray)
* See [[Meetings/ChefCookbook]] for details

== Milk Meeting ==
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 2000 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sarob
* See [[Meetings/milk]] for details

== StoryBoard Meeting ==
* Weekly on Thursdays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: cody-somerville or ttx
* See [[StoryBoard]] for details

Obsolete:GerritJenkinsGit

2013-11-15T14:59:54Z

Dripton: check that PyPI is up before pushing a release tag, to avoid problems

= Gerrit, Jenkins, and Git =
For a quick reference, please see [[GerritWorkflow]] instead.

We use [http://git-scm.com/ Git] for managing code repositories and interacting with other developers. [http://jenkins-ci.org/ Jenkins] is used to continuously test all of the components of [[OpenStack]] to ensure functionality and to verify that each change to the code base works as intended. [http://code.google.com/p/gerrit/ Gerrit] is a code review system originally developed for use by the Android Open Source Project and allows us to build a workflow where every change is peer-reviewed and tested by Jenkins before being merged into the main repository.

After making a change in their local Git repository, developers can easily push that change to Gerrit as a proposed change for the project. Jenkins will automatically run functional tests on the code and provide feedback on the change in Gerrit. Any [[OpenStack]] developer can provide feedback (in the form of a comment, or even line-by-line annotations) using Gerrit, and the core developers of the project can indicate whether they approve of the patch as is, or would like to see changes before it is integrated. Once patches are merged by Gerrit, the repository is mirrored to the canonical public repository at [https://git.openstack.org/cgit/ git.openstack.org] and to GitHub.

== Using Gerrit ==
The next sections describe how Gerrit fits into the developer workflow.

=== Gerrit Accounts ===
Gerrit lives at https://review.openstack.org/. Visit and click the '''Sign In''' link at the top-right corner of the page. Log in with your Launchpad ID.

Because Gerrit uses Launchpad OpenID single sign-on, you won't need a separate password for Gerrit, and once you log in to one of Launchpad, Gerrit, or Jenkins, you won't have to enter your password for the others.

Gerrit accounts are automatically synchronized with Launchpad, so your Gerrit account should already have the same username, full name, email address, ssh keys, and group membership.

Some information in Launchpad is not publicly available and so may not be copied over. The first time you log into Gerrit, you should click the '''Settings''' link at the top of the page, and then make sure that your '''Contact Information''', '''SSH Public Keys''', and '''Groups''' look correct. If not, please register your email address and SSH keys. If your group membership is not correct, please email openstack-ci-admins@lists.launchpad.net .

Ensure that you have run these steps to let git know about your email address:

<pre><nowiki>
git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"
</nowiki></pre>

=== Setting up Git for Use with Gerrit ===
For a more comprehensive look at using Gerrit, see [https://review.openstack.org/Documentation/user-upload.html the Gerrit manual].

==== Change-Id Hook ====
Gerrit uses a '''Change-Id''' footer in commits so that it can link Git commits to changes stored in its database. When you upload a revised change (to correct a problem or respond to code review comments), Gerrit will use the Change-Id footer to attach the commit as a new patchset on the existing gerrit change. This works best if the Change-Id is already in the original commit message, before it is even sent to Gerrit.

"git review" installs a commit hook into your repository that automatically adds Change-Id lines to your commits..

The Gerrit manual goes into more detail about [https://review.openstack.org/Documentation/user-changeid.html change IDs].

Install the git-review tool, which is the tool [[OpenStack]] uses to simplify submission of reviews to Gerrit.

<pre><nowiki>
sudo pip install git-review
</nowiki></pre>

==== Pushing Changes from Git ====
Simply running '''git review''' should be sufficient to push your changes to Gerrit, assuming your repository is set up as described above, you don't need to read the rest of this section unless you want to use an alternate workflow.

If you want to push your changes without using git-review, you can push changes to gerrit like you would any other git repository, using the following syntax (assuming "gerrit" is configured as a remote repository):

<pre><nowiki>
git push gerrit HEAD:refs/for/$BRANCH[/$TOPIC]
</nowiki></pre>

Where $BRANCH is the name of the Gerrit branch to push to (usually "master"), and you may optionally specify a Gerrit topic by appending it after a slash character.

==== Git SSH Commands ====
If you find you are frequently executing Gerrit commands via SSH, you may wish to add something like the following to your '''~/.ssh/config''' file:

<pre><nowiki>
Host review
Hostname review.openstack.org
Port 29418
User USERNAME
</nowiki></pre>

Which may shorten some SSH commands; the following are equivalent:

<pre><nowiki>
ssh -p 29418 review.openstack.org gerrit ls-projects
ssh review gerrit ls-projects
</nowiki></pre>

== Reviewing a Change ==
Log in to https://review.openstack.org/ to see proposed changes, and review them.

To provide a review for a proposed change in the Gerrit UI, click on the Review button (it will be next to the buttons that will provide unified or side-by-side diffs in the browser). In the code review, you can add a message, as well as a vote (+1,0,-1).

Any Openstack developer may propose or comment on a change (including voting +1/0/-1 on it). Openstack projects have a policy requiring two positive reviews from core reviewers. A vote of +2 is allowed from core reviewers, and should be used to indicate that they are a core reviewer and are leaving a vote that should be counted as such.

When a review has two +2 reviews and one of the core team believes it is ready to be merged, he or she should leave a +1 vote in the "Approved" category. You may do so by clicking the "Review" button again, with or without changing your code review vote and optionally leaving a comment. When a +1 Approved review is received, Jenkins will run tests on the change, and if they pass, it will be merged.

A green checkmark indicates that the review has met the requirement for that category. Under "Code-Review", only one +2 gets the green check.

=== Gerrit Best Practices ===
If you are working on unrelated changes, you should use a [http://progit.org/book/ch3-4.html topic branch] so that there isn't a dependency between the changes.

When you start working on a new change, make sure you have the current repository head from git.openstack.org (or GitHub).

For more information about uploading changes to gerrit, see the [https://review.openstack.org/Documentation/user-upload.html Uploading Changes] section of the Gerrit manual.

=== Gerrit Errors ===
==== missing Change-Id in commit message ====
If you see an error like this:

<pre><nowiki>
! [remote rejected] HEAD -> refs/for/master (missing Change-Id in commit message)
</nowiki></pre>

Make sure that you have the [[#Change-Id_Hook|Change-Id hook]] installed. If you don't, install it now, and the run '''git commit --amend''' and re-save your commit message. The hook will then add a Change-Id line.

If you did have the hook installed, there may be a syntax error with the Change-Id line. It must be in the last paragraph of the commit message, and it must be at the beginning of the line. Your commit message should look like this in your editor:

<pre><nowiki>
The text of your commit message is here.

Change-Id: I5f55e68d1bdb42a0fa6f0b1a5432786d0395da51
</nowiki></pre>

==== squash commits first ====
If you see this message:

<pre><nowiki>
! [remote rejected] HEAD -> refs/for/master (squash commits first)
</nowiki></pre>

It means that you are trying to update an existing change in Gerrit, but you created two separate commits. Normally to update a change you should amend an existing commit (see [[GerritWorkflow#Updating_a_Change|Updating a Change]]). If you have already made a second commit, you will need squash the last two commits in your tree. To do that, run:

<pre><nowiki>
git rebase -i HEAD~2
</nowiki></pre>

Your editor should appear with two commits listed, one per line. Change the word "pick" on the second line to "squash", so that it looks like:

<pre><nowiki>

pick 1458567 Fix bug 1014727
pick 7284e97 Document underlying technologies
pick fac4698 Clean up on section
pick xxxxxxx 2nd commit back
squash yyyyyyy head

</nowiki></pre>

And save. You should then be able to upload your commit with '''git review'''.

==== can not create new references ====

If you try to send a draft with '''git review -D''' and it fails like this:

<pre><nowiki>
! [remote rejected] HEAD -> refs/draft/master (can not create new references)
</nowiki></pre>

Then check that you are running git-review version 1.16 or later. You can install the lastest version with pip:

<pre><nowiki>
pip install git-review
</nowiki></pre>

=== Gerrit Merge Problems ===
Gerrit will fast-forward or merge changes as necessary when they are approved. If a conflict would be created by a merge, gerrit will not merge the change and will record an error message in the comments for the change. In these cases, you may need to [http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html rebase] or [http://www.kernel.org/pub/software/scm/git/docs/git-merge.html merge] the change, or if the repository head has changed significantly, you may need to change the patch.

If you don't already have the patch in your local repository, Gerrit provides commands on the web page for each change indicating how to download that change. You can then use git to correct the problem.

If you encounter other error messages from Gerrit, the [https://review.openstack.org/Documentation/error-messages.html Error Messages] section of the Gerrit manual may offer some tips.

=== Test Failures ===
When a new patchset is uploaded to Gerrit, that project's "check" tests are run on the patchset by Jenkins. Once completed the test results are reported to Gerrit by Jenkins in the form of a Verified: +/-1 vote. After code reviews have been completed and a change receives an Approved: +1 vote that project's "gate" tests are run on the change by Jenkins. Jenkins reports the results of these tests back to Gerrit in the form of a Verified: +/-2 vote. Code merging will only occur after the gate tests have passed successfully and received a Verified: +2. You can view the state of tests currently being run on the [http://status.openstack.org/zuul/ Zuul Status].

If a change fails tests in Jenkins, please follow the steps below:

# Jenkins leaves a comment in the review with links to the log files for the test run. Follow those links and examine the output from the test. It will include a console log, and in the case of unit tests, HTML output from the test runner, or in the case of a devstack-gate test, it may contain quite a large number of system logs.
# Examine the console log or other relevant log files to determine the cause of the error. If it is related to your change, you should fix the problem and upload a new patchset. Do not use "recheck" or "reverify".
# If the problem is due to non-deterministic behavior already merged, and is unrelated to your change, you should do the following to help other developers who may be affected by the same issue, and to focus attention of QA, CI, and other developers working to fix high-impact bugs and improve test systems:
#* Visit http://status.openstack.org/rechecks/ to see if one of the bugs listed there matches the error you've seen. If your error isn't there, then:
#* Identify which project(s) are affected, and search for a related bug on [https://bugs.launchpad.net/ Launchpad]. If you do not find an existing bug, file a new one (and be sure to include the error message). If the problem is due to an infrastructure problem (such as Jenkins, Gerrit, etc.), file (or search for) the bug against the [https://bugs.launchpad.net/openstack-ci/+bugs openstack-ci project].
# Leave a comment on the review referencing the bug causing the transient failure (not the bug you're attempting to fix with your patch):
#* To re-run the check jobs (before a change has been approved), leave a comment with the form "recheck bug ####".
#* To re-run the gate jobs (after a change has been approved), leave a comment with the form "reverify bug ####".
# This will update the [http://status.openstack.org/rechecks/ rechecks status page] to help others prioritize fixes for transient issues.

If you need to re-run tests and it does not make sense to include a bug number (perhaps there is no error, you've just made a draft change visible and want it tested or you're updating test results because you know that a related branch has changed since the last time they were run), you may leave a comment with the form "recheck no bug" (or "reverify no bug"). ''Please only do this if you are certain there is no bug that needs to be addressed.''

==== Test failures due to changes in the code ====

There might be some cases in which the submitted patch changes the way a tempest test behaves. In this case, the tempest test needs to be modified, so that it tests the new behaviour instead of the old one. The route for this is propose the tempest change, and get core contributors from the core project to +1 it, saying that they agree with the change. Once the tempest change has been accepted and merged, the original change could be tested again.

=== Merge Commits ===
When a branch is pushed to gerrit (either manually, or via git-review), each commit in the branch that is not in Gerrit's copy of the tree is turned into a new change for review (unless that commit has a Change-Id that corresponds to an existing change, in which case, the change is updated). This means that if a developer merges a branch from another source into their local repository and pushes to Gerrit, hundreds of new changes may be created. This is almost certainly not what was intended. For that reason, Gerrit is configured not to accept merge commits in the general case.

'''Caution: The following describes an experimental process and is not generally applicable yet:'''

However, merge commits are very useful for feature branches -- development branches that fork from the main line of development, occasionally receiving updates from the main line, and when development is complete, merging back into the main line. For these purposes, members of the $PROJECT-milestone group are permitted to upload merge commits to Gerrit. These users must take special care when dealing with merge commits to avoid the problems mentioned above. The following tips will help avoid problems with merge commits:

* Don't merge branches from gerrit and outside of gerrit (eg, GitHub or personal branches).
* When developing, follow the branching model described in [[GerritWorkflow]], this will avoid creating merge commits locally.
* Use git-review to upload your changes to Gerrit. By default, if git-review would create or update more than one commit, it will list the commits and ask you if that is what you intend to do. Pay attention to that, and if you see that too many commits are being uploaded, say "no" and clean up your local branch.
* To merge master into a feature branch, do the following:

<pre><nowiki>
git checkout feature-branch
git pull --ff-only origin feature-branch
git checkout -b merge-branch
git merge origin/master
# Amend the merge commit to automatically add a Change-ID to the commit message:
GIT_EDITOR=/bin/true git commit --amend
git review -R feature-branch
git checkout master
git branch -D merge-branch
</nowiki></pre>

Note that follows the same model described in [[GerritWorkflow]] of using a topic branch for each independent unit of local development. In this case, the "merge-branch" branch is being used to generate the merge commit, and once submitted, is no longer needed and can be (optionally) removed. You may continue to use your local copy of the feature-branch as normal, pulling fast-forward only commits from Gerrit. The following similar process may be used to merge the feature branch into master, terminating development on that branch:

<pre><nowiki>
git checkout master
git pull --ff-only origin master
git checkout -b merge-branch
git merge origin/feature-branch
# Amend the merge commit to automatically add a Change-ID to the commit message:
GIT_EDITOR=/bin/true git commit --amend
git review -R
git checkout master
git branch -D merge-branch
</nowiki></pre>

= Release Management =
== Milestones ==
Between the Milestone Branch Point and the release of the corresponding milestone, there needs to be a separate branch in Gerrit for changes destined for the milestone release. Meanwhile, development on the master branch should continue as normal (with the addition that changes proposed for the milestone should also be proposed for master, and some changes for master may need to be applied to milestone-proposed).

This process creates an ephemeral milestone-proposed branch that is only available in Gerrit during the milestone process. When the milestone is released, a tag is applied to the final commit to record the state of the branch at the time.

=== Create milestone-proposed Branch ===
This step should be performed by the [[OpenStack]] Release Manager at the Release Branch Point.

* Go to https://review.openstack.org/ and sign in
* Select '''Admin''', '''Projects''', then the project
* Select '''Branches'''
* Enter '''milestone-proposed''' in the '''Branch Name''' field, and '''HEAD''' as the Initial Revision, then press '''Create Branch'''

In your local checkout:

<pre><nowiki>
git checkout master
git pull
git checkout milestone-proposed
</nowiki></pre>

=== Authoring Changes for milestone-proposed ===
Create topic branches as normal, but branch them from milestone-proposed rather than master.

<pre><nowiki>
git checkout milestone-proposed
git pull
git checkout -b MY-TOPIC-BRANCH
</nowiki></pre>

Changes for milestone-proposed should be submitted with:

<pre><nowiki>
git push gerrit HEAD:refs/for/milestone-proposed
</nowiki></pre>

=== Submit Changes in master to milestone-proposed ===
If a change to master should also be included in milestone-proposed, use this procedure to cherry-pick that change and submit it for review.

<pre><nowiki>
git checkout milestone-proposed
git pull
git checkout -b master-to-mp
git cherry-pick -x <SHA1 or "master">
git push gerrit HEAD:refs/for/milestone-proposed
git branch -D master-to-mp
</nowiki></pre>

'''git cherry-pick master''' will pick the most recent commit from master to apply, if you want a different patch, use the SHA1 of the commit instead.

The '-x' flag will ensure the commit message records the SHA1 hash of the original commit in master.

If there are conflicts when cherry-picking, do not delete the 'Conflicts' lines GIT adds to the commit message. These are valuable to reviewers to identify files which need extra attention.

=== Submitting Changes in milestone-proposed to master ===
Changes that originate in milestone-proposed should also be submitted to master. Use these commands to make an up-to-date topic branch from master, then cherry-pick changes from milestone-proposed to be applied to master.

<pre><nowiki>
git checkout master
git pull
git checkout -b mp-to-master
git cherry-pick <SHA1 or milestone-proposed>
git review
git branch -D mp-to-master
</nowiki></pre>

'''git cherry-pick milestone-proposed''' will pick the most recent commit from milestone-proposed to apply, if you want a different patch, use the SHA1 of the commit instead.

=== Tagging a Release ===
This step should be performed by the [[OpenStack]] Release Manager when the release is made.

To tag the tip of the milestone-proposed branch with a release tag and push that tag to gerrit, git.openstack.org and GitHub, run the following commands:

<pre><nowiki>
git checkout milestone-proposed
git pull
git tag -s RELEASE-TAG-NAME
git push gerrit RELEASE-TAG-NAME
</nowiki></pre>

Running `git tag -s` signs the tag using GPG, so it's important to ensure that the person making the release have a valid GPG key.

Make sure you're only adding a single tag when pushing to gerrit.

Note: Pushing a release tag to gerrit causes an automatic update to PyPI. This will fail if PyPI is down, which it sometimes is. So it makes sense to check that PyPI is up before doing this.

=== End of Milestone ===
This step should be performed by the [[OpenStack]] Release Manager after the release is tagged.

When the milestone process is complete and the released commit is tagged, remove the milestone-proposed branch. The tag will persist, even after the branch is deleted, making it possible to restore the state of the tree.

* Go to https://review.openstack.org/ and sign in
* Select '''Admin''', '''Projects''', then the project
* Select '''Branches'''
* Select the checkbox next to '''milestone-proposed''' and hit '''Delete'''

= Resources =
See the [https://review.openstack.org/Documentation/index.html Gerrit documentation], especially the User Guide, for more information on how to use Gerrit. It is also available within Gerrit by clicking on the '''Documentation''' link on the top of the page.

The Mahara Project also [https://wiki.mahara.org/index.php/Developer_Area/Developer_Tools uses Git, Gerrit, and Jenkins] in a similar manner.

A description of many of the elements of the [http://sandofsky.com/blog/git-workflow.html git workflow]

Nova/ReleaseChecklist

2013-11-12T20:21:29Z

Dripton: /* Post-release Checklist */

This page is for tracking things that we should be doing in the code before or after each release.

=== Pre-release Checklist ===

* Merge latest translations

=== Post-release Checklist ===

* Add database migration placeholders to allow backportable DB migrations
* Bump rpc major versions to drop old compat code.
* Update version aliases for rpc outbound version control

Cinder/GuestAssistedSnapshotting

2013-07-17T10:59:35Z

Dripton: typo

= QEMU guest-assisted snapshotting =

==== Related blueprints ====

* https://blueprints.launchpad.net/nova/+spec/qemu-assisted-snapshots
* https://blueprints.launchpad.net/cinder/+spec/qemu-assisted-snapshots

==== Goals ====

1. Add snapshot support for Cinder backing stores which lack internal snapshots (NFS, Gluster, etc.)

==== Prerequisites ====

* QEMU/libvirt live snapshot support
* QEMU guest agent installed (for quiescing)

==== Overview ====

Currently, GlusterFS + Cinder does not support snapshots. Snapshot support can be enabled by storing volume data as QCOW2 files on Cinder volumes rather than as flat raw files (as is done today), and leveraging QCOW2's snapshot functionality.

Creation of Snapshot:
# User calls new nova API call to execute an assisted snapshot
# Nova will quiesce guest (use existing pause functionality if guest assisted quiesce is not available)
# Nova will execute snapshot API call in Cinder for each Cinder Volume
# Cinder creates snapshot(s)
# Nova resumes VM on completion of the snapshot(s)

The snapshot can then be managed like any other Cinder snapshot.

Changes required for Cinder QCOW2 volumes:
* Cinder code to create them (per-driver code & options)
* Cinder code to translate/process them for operations like upload-to-image, backup_create, clone
* Possibly DB information tracking type (qcow2 or raw) - if needed

== Related Notes ==

* Some examples on libvirt's blockcommit and blockpull -- http://kashyapc.fedorapeople.org/virt/lc-2012/snapshots-handout.html
* More notes on libvirt qcow2 based block operations -- http://kashyapc.fedorapeople.org/virt/lc-2012

== API Details ==

===New APIs===

====Cinder====
new API "create-snapshot-metadata"
(Note: this may actually need to be two APIs, or use different parameters to specify "creating" vs "done, created successfully".)

- Allow creation of a snapshot by providing metadata rather than Cinder creating snapshot. (i.e. it was created by Nova.) Cinder driver snapshot code is not called.
- Metadata:
volume_id
created_at
display_name (maybe?)
display_description (optional?)
size
- Leave snapshot in "creating" status
- This will be implemented as a volume_action

new API "finalize-snapshot-metadata"
- Finalize snapshot creation process, set status to available or failed
- This will be implemented as a volume_action

new API "snapshot-delete-metadata"
- Deletes a snapshot without performing any real storage operation
- Is this needed? Maybe not if the GlusterFS driver's snapshot-delete is smart enough.

====Nova====
New API to create snapshots of multiple volumes
- Allow "all volumes" or a subset of volumes to be specified
- Available via nova client CLI

===Snapshot creation===
Currently, it is assumed that file names are:
volume-<UUID> for the original volume (as is done today), and volume-<UUID>.<snap-UUID> where snap-UUID is the snapshot which depends directly on this qcow2 file as a backing file.
The offline Cinder case works this way, ideally Nova can match the same behavior.

Case 1: Nova-driven snaps (attached)

Nova:
Create multiple-snapshots Nova API called, specifying which volumes, or all volumes
Determine which volumes are local files, which are iSCSI/FC-attached
Call libvirt create-snapshot-as for each local file (on Gluster volume)
For other attached Cinder volumes, call Cinder snapshot API
Create a Cinder snapshot for each snapshot created (cinder create-snapshot-from-metadata API call)
Done

Case 2: Cinder-driven snapshot
Only works if volume not attached
create-snapshot goes through GlusterFS driver like a typical Cinder driver snapshot
Snapshot created via qemu-img manipulation

===Snapshot deletion===

Case 1: Nova-driven (attached)

Nova (method 1 - should work today):
Create libvirt snapshot from metadata retrieved from Cinder
Call libvirt blockpull operation (merge base into snapshot)
Rename snapshot file to previous base name (libvirt operation: ?)
Delete snapshot from Cinder (snapshot-delete-metadata, or maybe just snapshot-delete)

Nova (method 2 - more efficient, may not work today):
Create libvirt snapshot from metadata retrieved from Cinder
Call libvirt blockcommit operation (merge snapshot into base)
- In current (or at least recent) libvirt, live blockcommit is not supported. Should be added in the future.
Delete snapshot from Cinder (snapshot-delete-metadata, or maybe just snapshot-delete)

Case 2: Cinder-driven
Only works if volume not attached
Delete via qemu-img manipulation, works like a typical Cinder driver

Nova/BugTriage

2013-05-24T16:27:24Z

Dripton: /* Step 2: Triage Tagged Bugs */

= Nova Bug Triage =

The triage of Nova bugs follows the OpenStack-wide process documented on [[BugTriage]]. Since Nova is such an active project with a high number of incoming bug reports, we have a separate process for categorizing bugs and distributing the load of triage to a larger group of people.

=== Step 1: Tagging ===

All new bugs should be tagged to reflect which part of Nova they are related to. The current list of tags can be found on [[BugTags]]. Note that it is fine for a bug to receive more than one tag if appropriate.

Launchpad Query: [https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW Untriaged Bugs Without Tags]

Anyone is welcome to help with tagging bugs. However, the following people have committed to checking this on a regular basis to keep the untagged bug queue under control:
* russellb
* mikal

=== Step 2: Triage Tagged Bugs ===

Once new bugs have been tagged, they should be triaged as described on [[BugTriage]]. To help make sure that the triage queue stays under control, the following table lists the people that have committed to regularly triaging bugs for a given tag.

{| class="wikitable"
|-
! Bug tag !! Owner(s) !! Untriaged Query !! All Query
|-
| api || cyeoh || [https://bugs.launchpad.net/nova/+bugs?field.tag=api+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=api+ All]
|-
| baremetal || || [https://bugs.launchpad.net/nova/+bugs?field.tag=baremetal+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=baremetal+ All]
|-
| cells || || [https://bugs.launchpad.net/nova/+bugs?field.tag=cells+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=cells+ All]
|-
| db || dripton || [https://bugs.launchpad.net/nova/+bugs?field.tag=db+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=db+ All]
|-
| ec2 || || [https://bugs.launchpad.net/nova/+bugs?field.tag=ec2+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=ec2+ All]
|-
| hyper-v || || [https://bugs.launchpad.net/nova/+bugs?field.tag=hyper-v+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=hyper-v+ All]
|-
| libvirt || kchamart || [https://bugs.launchpad.net/nova/+bugs?field.tag=libvirt+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=libvirt+ All]
|-
| network || arosen || [https://bugs.launchpad.net/nova/+bugs?field.tag=network+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=network+ All]
|-
| postgresql || dripton || [https://bugs.launchpad.net/nova/+bugs?field.tag=postgresql+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=postgresql+ All]
|-
| powervm || mriedem || [https://bugs.launchpad.net/nova/+bugs?field.tag=powervm+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=powervm All]
|-
| rootwrap || ttx || [https://bugs.launchpad.net/nova/+bugs?field.tag=rootwrap+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=rootwrap+ All]
|-
| lxc || || [https://bugs.launchpad.net/nova/+bugs?field.tag=lxc+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=lxc+ All]
|-
| vmware || || [https://bugs.launchpad.net/nova/+bugs?field.tag=vmware+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=vmware+ All]
|-
| volumes || || [https://bugs.launchpad.net/nova/+bugs?field.tag=volumes+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=volumes+ All]
|-
| [http://a.tgcdn.net/images/products/additional/large/ec82_horse_head_mask_on_boat.jpg wat] || russellb || [https://bugs.launchpad.net/nova/+bugs?field.tag=wat+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=wat+ All]
|-
| xenserver || johnthetubaguy || [https://bugs.launchpad.net/nova/+bugs?field.tag=xenserver+&field.status%3Alist=NEW Untriaged] || [https://bugs.launchpad.net/nova/+bugs?field.tag=xenserver All]
|}

Nova/BugTriage

2013-05-23T21:15:57Z

Dripton: take db

'''''*** Note that this process is still a work in progress and has not yet been implemented. ***'''''

= Nova Bug Triage =

The triage of Nova bugs follows the OpenStack-wide process documented on [[BugTriage]]. Since Nova is such an active project with a high number of incoming bug reports, we have a separate process for categorizing bugs and distributing the load of triage to a larger group of people.

=== Step 1: Tagging ===

All new bugs should be tagged to reflect which part of Nova they are related to. The current list of tags can be found on [[BugTags]]. Note that it is fine for a bug to receive more than one tag if appropriate.

TODO: Launchpad query for untriaged and untagged bugs.

Anyone is welcome to help with tagging bugs. However, the following people have committed to checking this on a regular basis to keep the untagged bug queue under control:
* russellb

=== Step 2: Triage Tagged Bugs ===

Once new bugs have been tagged, they should be triaged as described on [[BugTriage]]. To help make sure that the triage queue stays under control, the following table lists the people that have committed to regularly triaging bugs for a given tag.

{| class="wikitable"
|-
! Bug tag !! Owner(s) !! Launchpad Query
|-
| api || ||
|-
| baremetal || ||
|-
| cells || ||
|-
| db || dripton ||
|-
| ec2 || ||
|-
| hyper-v || ||
|-
| libvirt || ||
|-
| network || ||
|-
| postgresql || ||
|-
| powervm || ||
|-
| rootwrap || ttx ||
|-
| lxc || ||
|-
| vmware || ||
|-
| xenserver || ||
|}

Meetings

2013-05-17T13:44:45Z

Dripton:

Meetings/DBTeamMeeting

2013-05-16T22:07:20Z

Dripton: change meeting time from 2200 to 1900 UTC, to be more friendly to European time zones

{{:Header}}

= Weekly team meeting =

There is a public weekly meeting held in <code><nowiki>#openstack-meeting</nowiki></code>, Thursdays at 19:00 UTC, to discuss database usage within Openstack. This is not the DBaaS meeting. Historically, this was the NovaDB team meeting, but other projects share the same concerns, and with Grizzly there is ongoing work to create a shared db-common project. Everyone interested in database-related topics (API, consistency, performance, HA, etc) is encouraged to attend.

== Agenda for next meeting ==

Things we should discuss at the next meeting. Anyone is welcome to suggest discussion topics.

* Action items from last week
**
* Agenda
**

== Ongoing projects ==

Sometimes, we just talk about the stuff everyone is doing, without any specific agenda.

* [https://blueprints.launchpad.net/nova/+spec/db-reconnect db-reconnect]
* [https://blueprints.launchpad.net/nova/+spec/db-session-cleanup db-session-cleanup]
* [https://blueprints.launchpad.net/nova/+spec/db-api-tests db-api-tests]
* [https://blueprints.launchpad.net/nova/+spec/db-mysqldb-impl db-mysqldb-impl]
* [https://blueprints.launchpad.net/nova/+spec/db-enforce-unique-keys db-enforce-unique-keys]
* [https://blueprints.launchpad.net/nova/+spec/backportable-db-migrations backportable-db-migrations]
* [https://blueprints.launchpad.net/nova/+spec/db-cleanup db-cleanup (parent blueprint)]

== Previous meetings ==
Previous meetings, with their notes and logs, can be found under http://eavesdrop.openstack.org/meetings/db/.

Obsolete:Alembic

2013-03-28T13:54:24Z

Dripton:

Nova has historically used [http://code.google.com/p/sqlalchemy-migrate/ SQLAlchemy-migrate] for database migrations. We should consider switching to [https://pypi.python.org/pypi/alembic Alembic].

A problem with SQLAlchemy-migrate is that migration scripts have a fixed order, with a version number embedded at the beginning of each script's filename. For example, 158_add_networks_uc.py is hardcoded to run before 159_revert_ip_column_length.py SQLAlchemy-migrate stores the current version number in the migrate_version table of the database, and requires that migration scripts use consecutive version numbers with none missing.

This is fine for straight-line development, but a problem when selectively backporting only a few features or bugfixes to a stable branch. One option would be to renumber scripts in the stable branch, but that's error-prone. Another option, which we have gone with so far, is creating a range of do-nothing placeholder scripts (currently versions 162-171 for backporting from Havana to Grizzly), and then filling in the content of those scripts with whatever we need to backport later.

Alembic has a better design for backports. Each Alembic migration script gets a uuid rather than a fixed integer version number. And then Alembic has the concept of branches, which are ordered chains of these uuids. So it's possible to have a "master" branch with all the migrations in their original order, and then a "stable" branch with only a subset of the migrations. The design of Alembic mirrors the design of Git here, and so is a better match to Nova's development model.

Of course, neither tool can perform miracles. To support backports, we need to write good migration scripts that are as robust as possible and make as few assumptions as possible. If scripts only work if all of the preceding scripts have already run, then they'll fail when backported to an environment where that assumption does not hold, regardless of how nice the backporting scheme is.

Switching tools would involve some pain. At the beginning of the Havana cycle, Nova has 39 migration scripts, of which 10 are placeholders. If we switch to Alembic, the 29 non-trivial scripts would need to be converted to Alembic syntax. There's an autoconversion tool at https://review.openstack.org/#/c/15196/, but it only does most of the work, not all. If we made the change later in the Havana cycle, there would presumably be other changes to migration scripts in flight, and we'd have to convert those as well. So if we make the switch, we should do it as soon as possibly, and as atomically as possible, and with loud advance warning to all Nova developers so they know about the disruption to their own migration scripts.

2013-02-27T17:54:46Z

Dripton: /* DB Migration Change Guidelines */

= DB Migration Change Guidelines =

We use sqlalchemy-migrate to enable step-wise and reversible changes to database schemata. (Note: Quantum uses Alembic.)

Given the centrality of schema migration to any OpenStack upgrade, it is important that all projects agree on what type of changes to the migration scripts should be allowed or red-flagged in reviews.

== Invariants ==

* DB schemas '''must''' always be migrate-able across milestone releases
* migrations '''must''' be structurally reversible, but not necessarily data-preserving

== Aspirational ==

* migration '''should''' also be maintained across individual commits, to avoid causing unnecessary issues for trunk-chasing deployments

== Unacceptable changes ==

* re-ordering of migration indices
* modificationss to ''existing'' scripts that could cause later migrations to fail (ruling out pretty much any structural change)

== Acceptable changes ==

* compaction of adjacent scripts, coinciding with major releases (as per the nova practice over the last couple cycles)
** This practice also poses potential issues for deployers tracking trunk, so I propose we stop doing it. -- dhellmann
* trivial modifications to existing scripts that do not result in structural change
** We need a concrete example of something that would meet these criteria and that could not also be accomplished with a new migration. -- dhellmann