[openstack-dev] [Group-Based-Policy] Fixing backward incompatible unnamed constraints removal
kukura at noironetworks.com
Wed Apr 15 15:19:43 UTC 2015
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 , 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.
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 <ivarlazzaro at gmail.com> wrote:
>> Hello Team,
>> As per discussion in the latest GBP meeting  I'm hunting down all the
>> backward incompatible changes made on DB migrations regarding the removal of
>> unnamed constraints.
>> In this report  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 , 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  as is (with the broken migration), but we cut the new
>> stable release only once  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  in multiple patches, and we only backport those that fix
>> commits that are already in Juno. Patches like  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,
>>  https://bugs.launchpad.net/group-based-policy/+bug/1443606
>>  https://review.openstack.org/#/c/170972/
>>  https://review.openstack.org/#/c/173051/
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev