Open Stack

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 <ivarlazzaro at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev