Dougal, I forgot to mention that explicitly but, yes, #1 is needed only not to break the sequence of migrations. We can manually fix the migration number in #2 just for stable/pike but I somewhat don’t like the idea of having different migration numbers in different branches.
It’s a good news that we’re not going to break TripleO. Thanks Renat Akhmerov @Nokia On 17 Oct 2017, 20:21 +0700, Dougal Matthews <dou...@redhat.com>, wrote: > > > > On 17 October 2017 at 09:19, Renat Akhmerov <renat.akhme...@gmail.com> > > wrote: > > > Hi, > > > > > > We have two patches in Mistral that we need to back port to stable/pike. > > > However, they are against of stable branch management policy because they > > > slightly change the DB schema. The patches are the following: > > > > > > 1. https://review.openstack.org/#/c/512528/ > > > 2. https://review.openstack.org/#/c/512256/ > > > > > > > > > #2 is a critically important fix that fixes a problem of decreasing > > > Mistral performance when DB becomes heavy (has lots of execution > > > objects). This is a blocker issue for us (Nokia) preventing us using > > > Mistral in production. It also seriously optimizes performance in general. > > > > > > So hereby I'm asking your advice on what we can do in this situation. Can > > > we merge these patches if we make sure that we don't break anyone in the > > > community? For example, TripleO. > > > > As far as I am aware, this wont be a problem for TripleO. These patches are > > both additive (new db column and new db index). > > > > The first patch (512528) is only a candidate for backport to avoid breaking > > the migration history order, it isn't otherwise needed in Pike. How is this > > normally handled in other projects? i.e. we need to backport migration 24 > > to Pike, but 23 is in master only. I assume this problem has came up before > > and been solved, but I can't find any examples. > > > > > > > > > > Thanks > > > > > > Renat Akhmerov > > > @Nokia > > > > > > __________________________________________________________________________ > > > 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
