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

Reply via email to