stable/icehouse frozen in preparation for 2014.1.3
Hey All- Just letting everyone know I added a -2 to all unapproved changes as part of the 2014.1.3 freeze. As I write this, we still have have 53 (!) approved changes queued in the gate for merging. I would like to let this flush through before sending out a call for testing. Hopefully on Monday? Any later than that and I propose we bump the release till the following week to allow those interested in testing the proposed tarballs a chance to do so. If others would like to keep an eye on the pending changes and kick them with a recheck when needed, it would be appreciated. I'd like to thank everyone who helped out getting the patch queue down this week, we've got quite a team helping out with stable maintenance now! Cheers, Adam
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 26/09/14 07:37, Adam Gandelman wrote:
Hey All-
Just letting everyone know I added a -2 to all unapproved changes as part of the 2014.1.3 freeze. As I write this, we still have have 53 (!) approved changes queued in the gate for merging. I would like to let this flush through before sending out a call for testing. Hopefully on Monday? Any later than that and I propose we bump the release till the following week to allow those interested in testing the proposed tarballs a chance to do so. If others would like to keep an eye on the pending changes and kick them with a recheck when needed, it would be appreciated.
Do we have freeze exception process in terms of stable branches documented anywhere on wiki? /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUJRttAAoJEC5aWaUY1u57+ncIALkvDuEbV5H6EUkZ5KVOBczz /n0prdOX2oXmyOlwRJF+8e4VU2oj0Ji6StUqQkri5YoGN1nE4lXz8JGD3tAAf7T9 4ZOQ98/3q6CWem5vT8AV5nxoqlxxTsYolQghP2VvT1WC+kR6G//Bx+33mpS6cr0Z liGheXFGGh/99ns3mTx+gI5J7KUTMrM1uVxntlFqKElpxsZjP/uG3D711OBdQetO VD0Pp43FxBBigj3Zldn3AaDtZjA/G6Zl7n+hgkRRqA2zaLGSd6b4q1Ndr3Xgh23b w1KiboAMBtD8Z7+v6Du0srwmO70CkyvUWHczo+2Qio1eQzcTSyywb7HT16Hy7M8= =qBYs -----END PGP SIGNATURE-----
Do we have freeze exception process in terms of stable branches documented anywhere on wiki?
We don't, the whole freeze and exception process existed only as a lore on the mailing list, I guess it's time to codify it. Here's proposal to put under https://wiki.openstack.org/wiki/StableBranch#Releases The stable-maint and release teams work together to publish point releases from the stable branch. SeeStableBranchRelease for details about how these releases are prepared. + +One week before the planned point release, stable release manager will announce that stable branch is frozen +to allow testing before the release. Freeze exceptions can be proposed on openstack-stable-maint list where +stable-maint team will try to reach consensus. + Also not codified is the exception process for rule-breaking changes, what about this at the end of https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes * Incompatible config file changes + +Proposed backports breaking any of above guidelines can be discussed as an exception requests on +openstack-stable-maint list where stable-maint team will try to reach consensus. + Cheers, Alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 LGTM. On 26/09/14 10:45, Alan Pevec wrote:
Do we have freeze exception process in terms of stable branches documented anywhere on wiki?
We don't, the whole freeze and exception process existed only as a lore on the mailing list, I guess it's time to codify it.
Here's proposal to put under https://wiki.openstack.org/wiki/StableBranch#Releases
The stable-maint and release teams work together to publish point releases from the stable branch. SeeStableBranchRelease for details about how these releases are prepared. + +One week before the planned point release, stable release manager will announce that stable branch is frozen +to allow testing before the release. Freeze exceptions can be proposed on openstack-stable-maint list where +stable-maint team will try to reach consensus. +
Also not codified is the exception process for rule-breaking changes, what about this at the end of https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes
* Incompatible config file changes + +Proposed backports breaking any of above guidelines can be discussed as an exception requests on +openstack-stable-maint list where stable-maint team will try to reach consensus. +
Cheers, Alan
_______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUJTHqAAoJEC5aWaUY1u57rIMH+wb/xQG/1jX7o12ZERNLQsGj WZ8wA8FUp7oNUwm8XFqIY0z7aZ0pKKnoaINJWVXYG1ooTriKS1miPcdA1g6+6fzH w2Ly0oBJ/u/bXT2262rB3CaYiiTM8gSmA+cOG0J1lNJ52KCTygN+bEWB/xH1q/IT khgjdeYLkmimfdCHLYdroVrBmkfgUrbvwQmgGYtKdCBz7bs9s9R8pSr+8DYaxrTM sNFxtQHDBHhNmaQjJiuSl2bPOunPpulTQYLFp2/sfDV4nErgJ8+/vcqM7c3E50Vx +vbcYBDqCGrFAltTLCdnWs/Kloi9pcP2UMwo/tW915iJIMFdXd6nAV0kCCT2/1s= =+07i -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FYI I went forward and updated the wiki page with the proposed text. /Ihar On 26/09/14 10:45, Alan Pevec wrote:
Do we have freeze exception process in terms of stable branches documented anywhere on wiki?
We don't, the whole freeze and exception process existed only as a lore on the mailing list, I guess it's time to codify it.
Here's proposal to put under https://wiki.openstack.org/wiki/StableBranch#Releases
The stable-maint and release teams work together to publish point releases from the stable branch. SeeStableBranchRelease for details about how these releases are prepared. + +One week before the planned point release, stable release manager will announce that stable branch is frozen +to allow testing before the release. Freeze exceptions can be proposed on openstack-stable-maint list where +stable-maint team will try to reach consensus. +
Also not codified is the exception process for rule-breaking changes, what about this at the end of https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes
* Incompatible config file changes + +Proposed backports breaking any of above guidelines can be discussed as an exception requests on +openstack-stable-maint list where stable-maint team will try to reach consensus. +
Cheers, Alan
_______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUJtDVAAoJEC5aWaUY1u571xIH/3/k+mHDIPnNLmqWGbkiPG9z JEQzxGL7y4zki3cSF1yWsXmSb+p3BOU7Cy188TtjmUfjfS7M8cpJzA4OVb8p1409 ZyqgvZdURaNzEv3MOOMWJNuaodFBFvBGVa3vctmckEgoNYTxFnq1NH93lKGANfCT uNYczUh6BXxF11OagcuFel8hM0+zJt7i65NLvzFo+H+NHf4Pt5GW3L2t4yJ1DZQm SgWspz7IjwqsVJd6sWLEPuU+H1d/C1PeSRIoAWTN55y7T8hTeYqgY+0u8q5IqGdZ A67HArAnHJrOVlVmktpg/bG/govHuNaOQZSpqWJ4KJ/tAgZ9DWdHIVLnum9XHT0= =Gm3m -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Adam, can we have draft release notes page created so that we may start to fill it? Among things that I have to mention there are: - - the force_gateway_on_subnet issue we had noted for stable/havana should also be covered for all the next icehouse releases; - - one of the patches currently in the queue [1] has the following comment from Neutron core that we probably want to mention in release notes: """ We could also update the release notes indicating that existing deployments will need to manually modify their schema if they're already at Icehouse. """ [1]: https://review.openstack.org/#/c/110642/ /Ihar On 26/09/14 07:37, Adam Gandelman wrote:
Hey All-
Just letting everyone know I added a -2 to all unapproved changes as part of the 2014.1.3 freeze. As I write this, we still have have 53 (!) approved changes queued in the gate for merging. I would like to let this flush through before sending out a call for testing. Hopefully on Monday? Any later than that and I propose we bump the release till the following week to allow those interested in testing the proposed tarballs a chance to do so. If others would like to keep an eye on the pending changes and kick them with a recheck when needed, it would be appreciated.
I'd like to thank everyone who helped out getting the patch queue down this week, we've got quite a team helping out with stable maintenance now!
Cheers, Adam
_______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUJtHPAAoJEC5aWaUY1u57CUQIAIDQ0IdsFK27Wi7mTcrRUnfZ yTLa1eQhiAWDetLr+GQv5lZPdEvv6Fh2411Cv8zVpvLqxy3xwlJ9TmGeS1ARlezx SL4mkDZTjnifbXpI3b7tQwlY5vev1XIjErP8UM0CRwQ0ZHxBK/nyZCXJbRwToZ+R OrPNjL/fBXrBkpsKttPwXLOFlH7vOwVrDrkq0PJ27AXthialgdkwDuiYF77ld+g9 pDCbRh/CDAoyVWeiFgbPMm6fFLZx2QKtse6jn0Hzx28rRNqM9vGwu9DTBH63z8oD WRDzo1Upq/YMdVin9BOdEaonj1y/PZtfcVJ+i9CwzXEoABTmICsx26p+aYTT4VU= =bw0t -----END PGP SIGNATURE-----
can we have draft release notes page created so that we may start to fill it?
It's a wiki :) https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.3#Neutron
""" We could also update the release notes indicating that existing deployments will need to manually modify their schema if they're already at Icehouse. """ [1]: https://review.openstack.org/#/c/110642/
Hmm, what was the outcome of discussion about backporting db migrations with Alembic? Isn't there a way to insert db migration so that admin could just run neutron-db-manage upgrade ? In any case, exact commands to run need to be documented, like similar example from the past: https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.2#Keystone Cheers, Alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 27/09/14 18:05, Alan Pevec wrote:
can we have draft release notes page created so that we may start to fill it?
It's a wiki :) https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.3#Neutron
Sure. Do we have the draft somewhere to copy-paste from? Or do you copy-paste it from the previous one manually removing unneeded lines?
""" We could also update the release notes indicating that existing deployments will need to manually modify their schema if they're already at Icehouse. """ [1]: https://review.openstack.org/#/c/110642/
Hmm, what was the outcome of discussion about backporting db migrations with Alembic? Isn't there a way to insert db migration so that admin could just run neutron-db-manage upgrade ?
I think there is no way to introduce trees in migration chains until the following alembic is implemented and released: https://bitbucket.org/zzzeek/alembic/issue/167/multiple-heads-branch-resolut... Mike, is it correct?
In any case, exact commands to run need to be documented, like similar example from the past: https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.2#Keystone
The SQL statement for this is: "ALTER TABLE agents ADD CONSTRAINT uniq_agents0agent_type0host UNIQUE (agent_type, host);" Will it be enough, or should we instead implement some script using sqlalchemy to stay on portable side (and maybe even place it in tools/ directory shipping with the package)? [Note: I have no idea how portable the statement above is.]
Cheers, Alan
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEbBAEBCgAGBQJUKUFHAAoJEC5aWaUY1u57QJQH9REs0S3R0Vrx4/m25XrzjqI3 WN50ko2SpygzlDySvJZuOddVvG7RfK98aidkF46O8wU/4NovDF9G0JKwRBbBLIAr OhHCT/RHFVM/ng/zcUuF1/DPfkTQTRDGLY0kUksFVstPGPlr9uLtLPJNlX/5fMsV xE1VRXtEhnDUTzXsbeSovUeKfvu3K3FHN8RpcxxMJiiU3h1TXzSA6ox7lcVqL2jv k1s3rTUtHvTaiYdnD1JTGG+pqANo/CavPHIqauPb9Hz1mECYaE9e2fCv0kvKj7mY 1/xsMgHVr87bnJeSgRIB1LfqdaE15Tn5HF3gBl4307NCh5o1YpCU5UwjjSbq5A== =FUYv -----END PGP SIGNATURE-----
On Sep 29, 2014, at 7:23 AM, Ihar Hrachyshka <ihrachys@redhat.com> wrote:
""" We could also update the release notes indicating that existing deployments will need to manually modify their schema if they're already at Icehouse. """ [1]: https://review.openstack.org/#/c/110642/
Hmm, what was the outcome of discussion about backporting db migrations with Alembic? Isn't there a way to insert db migration so that admin could just run neutron-db-manage upgrade ?
I think there is no way to introduce trees in migration chains until the following alembic is implemented and released:
https://bitbucket.org/zzzeek/alembic/issue/167/multiple-heads-branch-resolut...
Mike, is it correct?
You can absolutely insert migrations in the middle of the existing series, that was one of the key design goals of Alembic vs. Migrate. The issue mentioned above would allow three new things. The main one is that individual migrations would be run independently of any others except the ones they were dependent on, relative to the state of an particular database. This means that in the scenario where there are two target databases, where database A was migrated along branch X and database B was migrated along branch Y, could both be made to arrive at merge point Z using the same set of migration files - database A would receive just the Y migrations and database B would receive just the X migrations. This is the most important aspect of the change, however the case to which this applies is fairly rare, where two databases that hold production data or data that can’t be rebuilt have been migrated along two divergent schema branches, and need to be resolved to a common merge point. Some of our users have this case going on but I don’t think it typically applies to openstack (but let me know if I’m mistaken there). The second thing it provides, which is more applicable to openstack, is that the multiple branches can optionally be made to remain independent of each other, so that you can upgrade along branches without impacting the others - this would allow a scenario such as, one branch adds all the new columns and tables to the database, then the app code is upgraded, then another branch is run to remove all the old columns and old tables. However again, this is something openstack could do in the future to allow migrations with no downtime, but my understanding is that this is not an available feature right now. Finally, the third feature is that when you do have multiple branches that you want to merge, they can be resolved automatically by adding a merge revision, just like any other VCS, since the migrations don’t have to be manually linked in series. As it stands right now, Alembic wants to see a single series of revision files, however you can rearrange and mutate this ordering any way you’d like, insertions are not a problem. As we are targeting systems that are working along a linear release scheme, this should be all we ultimately need. The resolution of branches is manual but simple, and is documented here: http://alembic.readthedocs.org/en/latest/tutorial.html#working-with-branches.
participants (4)
-
Adam Gandelman
-
Alan Pevec
-
Ihar Hrachyshka
-
Mike Bayer