Open Stack

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 <davanum at 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 <davanum at gmail.com>
> wrote:
> > Newton is already shipped!
> >
> > -- Dims
> >
> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
> > <kproskurin at mirantis.com> wrote:
> >> Galera only supported since Ocata?
> >>
> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas <davanum at 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
> >>> <kproskurin at 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 <
> ihrachys at 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
> >>> >> <akamyshnikova at 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-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
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Best regards,
> >>> > Proskurin Kirill
> >>> >
> >>> >
> >>> >
> __________________________________________________________________________
> >>> > 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
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Davanum Srinivas :: https://twitter.com/dims
> >>>
> >>>
> __________________________________________________________________________
> >>> 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
> >>
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Proskurin Kirill
> >>
> >>
> __________________________________________________________________________
> >> 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
> >>
> >
> >
> >
> > --
> > Davanum Srinivas :: https://twitter.com/dims
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __________________________________________________________________________
> 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
>
-- 
Regards,
Ann Taraday
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170124/4c5992cd/attachment-0001.html>