Nope, this won't be necessary. 0.8.10 - allows us to create pk on alembic_version table automatically, but only for new deployments.
I propose manually add pk on this table if it is not existing. On Tue, Jan 24, 2017 at 7:25 PM Davanum Srinivas <dava...@gmail.com> wrote: > Ann, > > Don't you still need alembic>=0.8.10 to be present? > > -- Dims > > On Tue, Jan 24, 2017 at 10:05 AM, Anna Taraday > <akamyshnik...@mirantis.com> wrote: > > We do not backport db changes, but if the existing migration does not > work > > in certain circumstances, should not we fix it to make it work if it is > > possible? > > This will allow to deploy new deployments with Newton code on Galera. > > > > On Tue, Jan 24, 2017 at 6:45 PM Davanum Srinivas <dava...@gmail.com> > wrote: > >> > >> Please see > >> > http://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines > >> > >> On Tue, Jan 24, 2017 at 9:34 AM, Davanum Srinivas <dava...@gmail.com> > >> wrote: > >> > Newton is already shipped! > >> > > >> > -- Dims > >> > > >> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin > >> > <kprosku...@mirantis.com> wrote: > >> >> Galera only supported since Ocata? > >> >> > >> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas <dava...@gmail.com > > > >> >> wrote: > >> >>> > >> >>> Kirill, > >> >>> > >> >>> "If OS wants support Galera, it needs to comply with the Galera > >> >>> requirements" <<< This is true for master/ocata NOT Newton. > >> >>> > >> >>> Ihar's response is perfectly acceptable thing to do for Newton in > the > >> >>> community to highlight the possibility of this situation. Downstream > >> >>> folks can do what they need/have to do for Newton. > >> >>> > >> >>> Thanks, > >> >>> Dims > >> >>> > >> >>> On Tue, Jan 24, 2017 at 4:49 AM, Kirill Proskurin > >> >>> <kprosku...@mirantis.com> wrote: > >> >>> > HI! > >> >>> > > >> >>> > Thing is, running Galera without enforcing it very bad idea for > >> >>> > production > >> >>> > use. Permissive mode was added more or less for testing purposes, > >> >>> > running > >> >>> > real production with it is dangerous, since it's not enforcing the > >> >>> > mandatory > >> >>> > Galera requirement, one of them is a "All tables must have a > primary > >> >>> > key". > >> >>> > You cant disable a single check, you could only disable them all > and > >> >>> > this > >> >>> > could lead to some serious problems, like data loss or corruption. > >> >>> > > >> >>> > If OS wants support Galera, it needs to comply with the Galera > >> >>> > requirements. > >> >>> > > >> >>> > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka > >> >>> > <ihrac...@redhat.com> > >> >>> > wrote: > >> >>> >> > >> >>> >> An alternative could also be, for Newton and earlier, to release > a > >> >>> >> note saying that operators should not run the code against > >> >>> >> ENFORCING > >> >>> >> galera mode. What are the reasons to enable that mode in > OpenStack > >> >>> >> scope that would not allow operators to live without it for > another > >> >>> >> cycle? > >> >>> >> > >> >>> >> Ihar > >> >>> >> > >> >>> >> On Mon, Jan 23, 2017 at 10:12 AM, Anna Taraday > >> >>> >> <akamyshnik...@mirantis.com> wrote: > >> >>> >> > Hello everyone! > >> >>> >> > > >> >>> >> > Guys in our team faced an issue when they try to run alembic > >> >>> >> > migrations > >> >>> >> > on > >> >>> >> > Galera with ENFORCING mode. [1] > >> >>> >> > > >> >>> >> > This was an issue with Alembic [2], which was quickly fixed by > >> >>> >> > Mike > >> >>> >> > Bayer > >> >>> >> > (many thanks!) and new version of alembic was resealed [3]. > >> >>> >> > The global requirements are updated [4]. > >> >>> >> > > >> >>> >> > I think that it is desired to fix this for Newton at least. We > >> >>> >> > cannot > >> >>> >> > bump > >> >>> >> > requirements for Newton, so hot fix can be putting pk on this > >> >>> >> > table > >> >>> >> > in > >> >>> >> > the > >> >>> >> > first migration like proposed [5]. Any other ideas? > >> >>> >> > > >> >>> >> > [1] - https://bugs.launchpad.net/neutron/+bug/1655610 > >> >>> >> > [2] - https://bitbucket.org/zzzeek/alembic/issues/406 > >> >>> >> > [3] - > >> >>> >> > > >> >>> >> > > >> >>> >> > > http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.10 > >> >>> >> > [4] - https://review.openstack.org/#/c/423118/ > >> >>> >> > [5] - https://review.openstack.org/#/c/419320/ > >> >>> >> > > >> >>> >> > > >> >>> >> > -- > >> >>> >> > Regards, > >> >>> >> > Ann Taraday > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > __________________________________________________________________________ > >> >>> >> > 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 > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > Best regards, > >> >>> > Proskurin Kirill > >> >>> > > >> >>> > > >> >>> > > >> >>> > > __________________________________________________________________________ > >> >>> > 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 > >> >>> > > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Davanum Srinivas :: https://twitter.com/dims > >> >>> > >> >>> > >> >>> > __________________________________________________________________________ > >> >>> 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 > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> Best regards, > >> >> Proskurin Kirill > >> >> > >> >> > >> >> > __________________________________________________________________________ > >> >> 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 > >> >> > >> > > >> > > >> > > >> > -- > >> > Davanum Srinivas :: https://twitter.com/dims > >> > >> > >> > >> -- > >> Davanum Srinivas :: https://twitter.com/dims > >> > >> > __________________________________________________________________________ > >> 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 > > > > -- > > Regards, > > Ann Taraday > > > > > __________________________________________________________________________ > > 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 > > > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __________________________________________________________________________ > 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 > -- Regards, Ann Taraday
__________________________________________________________________________ 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
