Re: [openstack-dev] [Group-Based-Policy] Fixing backward incompatible unnamed constraints removal
I believe that, on the stable branch at least, we need to fix the migrations so that upgrades are possible. This probably means fixing them the same way on the master branch first and backporting the fixes to stable/juno. All migrations that were present in the initial juno release need to be restored to the exact state they were in that release, and new migrations need to be added that make the needed schema changes, preserving state of existing deployments. I'm assuming there is more involved than just the constraint removal in Ivar's [2], but haven't checked yet. I think it would be OK to splice these new migrations into the chain on master just after the final migration that was present in the juno release, since we are not trying to support trunk chasers on master. Does this make sense? I do not think it should be difficult, unless schema changes were introduced for which deployment state cannot be preserved/defaulted. -Bob On 4/15/15 3:30 AM, Sumit Naiksatam wrote: Thanks Ivar for tracking this and bringing it up for discussion. I am good with taking approach (1). On Mon, Apr 13, 2015 at 1:10 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote: Hello Team, As per discussion in the latest GBP meeting [0] I'm hunting down all the backward incompatible changes made on DB migrations regarding the removal of unnamed constraints. In this report [1] you can find the list of affected commits. The problem is that some of the affected commits are already back ported to Juno! and others will be [2], so I was wondering what's the plan regarding how we want back port the compatibility fix to stable/juno. I see two possibilities: 1) We backport [2] as is (with the broken migration), but we cut the new stable release only once [3] is merged and back ported. This has the advantage of having a cleaner backport tree in which all the changes in master are cherry-picked without major changes. 2) We split [3] in multiple patches, and we only backport those that fix commits that are already in Juno. Patches like [2] will be changed to accomodate the fixed migration *before* being merged into the stable branch. This will avoid intra-release code breakage (which is an issue for people installing GBP directly from code). Please share your thoughts, Thanks, Ivar. [0] http://eavesdrop.openstack.org/meetings/networking_policy/2015/networking_policy.2015-04-09-18.00.log.txt [1] https://bugs.launchpad.net/group-based-policy/+bug/1443606 [2] https://review.openstack.org/#/c/170972/ [3] https://review.openstack.org/#/c/173051/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Group-Based-Policy] Fixing backward incompatible unnamed constraints removal
Thanks Ivar for tracking this and bringing it up for discussion. I am good with taking approach (1). On Mon, Apr 13, 2015 at 1:10 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote: Hello Team, As per discussion in the latest GBP meeting [0] I'm hunting down all the backward incompatible changes made on DB migrations regarding the removal of unnamed constraints. In this report [1] you can find the list of affected commits. The problem is that some of the affected commits are already back ported to Juno! and others will be [2], so I was wondering what's the plan regarding how we want back port the compatibility fix to stable/juno. I see two possibilities: 1) We backport [2] as is (with the broken migration), but we cut the new stable release only once [3] is merged and back ported. This has the advantage of having a cleaner backport tree in which all the changes in master are cherry-picked without major changes. 2) We split [3] in multiple patches, and we only backport those that fix commits that are already in Juno. Patches like [2] will be changed to accomodate the fixed migration *before* being merged into the stable branch. This will avoid intra-release code breakage (which is an issue for people installing GBP directly from code). Please share your thoughts, Thanks, Ivar. [0] http://eavesdrop.openstack.org/meetings/networking_policy/2015/networking_policy.2015-04-09-18.00.log.txt [1] https://bugs.launchpad.net/group-based-policy/+bug/1443606 [2] https://review.openstack.org/#/c/170972/ [3] https://review.openstack.org/#/c/173051/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Group-Based-Policy] Fixing backward incompatible unnamed constraints removal
Hello Team, As per discussion in the latest GBP meeting [0] I'm hunting down all the backward incompatible changes made on DB migrations regarding the removal of unnamed constraints. In this report [1] you can find the list of affected commits. The problem is that some of the affected commits are already back ported to Juno! and others will be [2], so I was wondering what's the plan regarding how we want back port the compatibility fix to stable/juno. I see two possibilities: 1) We backport [2] as is (with the broken migration), but we cut the new stable release only once [3] is merged and back ported. This has the advantage of having a cleaner backport tree in which all the changes in master are cherry-picked without major changes. 2) We split [3] in multiple patches, and we only backport those that fix commits that are already in Juno. Patches like [2] will be changed to accomodate the fixed migration *before* being merged into the stable branch. This will avoid intra-release code breakage (which is an issue for people installing GBP directly from code). Please share your thoughts, Thanks, Ivar. [0] http://eavesdrop.openstack.org/meetings/networking_policy/2015/networking_policy.2015-04-09-18.00.log.txt [1] https://bugs.launchpad.net/group-based-policy/+bug/1443606 [2] https://review.openstack.org/#/c/170972/ [3] https://review.openstack.org/#/c/173051/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
