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
