Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-30 Thread Mike Bayer 



On 01/24/2017 04:49 AM, Kirill Proskurin 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".


Any application that wishes to run Galera in PK-enforcing mode may do 
so, by simply adding a primary key constraint to the alembic_version 
table beforehand if one is not already present.   Openstack applications 
may add a migration that does this automatically as well.


But beyond that, I disagree with this characterization.  Galera's 
documentation does not state "All tables must have a primary key", it 
states, "Do not use tables without a primary key", and the reasons they 
list do not affect Alembic's use case except in one potential edge case 
(although the documentation is too vague to know if it's real or not), 
for which the above workaround that the Openstack application add a PK 
constraint up front would mitigate.



Reviewing Galera's documentation on this subject:


http://galeracluster.com/documentation-webpages/limitations.html

"Do not use tables without a primary key."

OK, nevertheless they are giving us the choice.   Let's see why that is:


"When tables lack a primary key, rows can appear in different order on 
different nodes in your cluster. "


The Alembic versioning table typically stores exactly one row, or in the 
case of an Openstack application using multiple branches like Neutron 
may store several rows, however there is no ordering requirement on this 
table when they are SELECTed.  Additionally, relational database tables 
have no defined ordering in *any* case, so a SELECT that has no ORDER BY 
yet which expects a specific ordering is already broken.


The other case for intrinsic ordering is that concurrent UPDATE 
statements on a table may produce different row locking behavior; so 
that an UPDATE applied to a table may apply differently depending on 
which galera node is accessed.   This is a non-issue for the alembic 
version table because this table is only accessed by a single process 
during an upgrade operation and is not subject to any concurrency.


"As such, queries like SELECT...LIMIT... can return different results."

You should *never* run SELECT..LIMIT without an ORDER BY on any 
relational database so this point is moot.


"Additionally, on such tables the DELETE statement is unsupported."

Here we have the first issue that can be a problem.   The 
alembic_version table is normally not subject to a DELETE operation. 
The feature in which DELETE is used is if a project is using branches 
that merge together - when an upgrade across a merge point is made, the 
additional rows in the table for the merged points are DELETEd.


Currently, I'm not sure if any openstack project is merging any branches 
together.   If they are, they should include a migration that manually 
adds a primary key constraint to the alembic_version table.  That is, 
each Openstack project can address this issue directly just by including 
a migration that adds a primary key constraint to the alembic_version table.


In my testing, I cannot locate the nature of the "is unsupported" 
statement.   The DELETE statement does in fact work "fine" on a Galera 
cluster table that has no primary key, the correct row is deleted and 
the correct result is replicated to the other nodes.   So if 
"unsupported" means, "may fail under load", "doesn't work with the 
AUTO_INCREMENT feature" (which Alembic does not use) "may fail 
randomly", or simply, "works fine we just don't want to test it", is not 
clear.   But again, the upstream Alembic fix isn't as essential as much 
as it is that a project that is merging branches together makes sure 
they perform an ALTER against the alembic_version table to add a primary 
key constraint if one does not exist already.



"Note - If you have a table without a primary key, it is always possible 
to add an AUTO_INCREMENT column to the table without breaking your 
application. "


this cryptic statement suggests that perhaps Galera's AUTO_INCREMENT 
feature is the concern they have with DELETE.  Alembic does not use the 
AUTO_INCREMENT feature on this table.


Overall, Galera's notes on this subject do not indicate that an 
application with an un-constrained alembic_version table is dangerous in 
any way, with the possible exception of a branch merge operation for 
which the risk can be mitigated by adding the primary key constraint to 
the table.Additional detail as to the "DELETE is not supported" 
comment would be helpful.






 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

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-25 Thread Anna Taraday 
Change against master merged.
Backport for Newton - https://review.openstack.org/#/c/419320/

On Tue, Jan 24, 2017 at 7:44 PM Davanum Srinivas  wrote:

> Cool. Then i'd support a backport when the review against master
> merges. Thanks Ann and Kirill.
>
> -- Dims
>
> On Tue, Jan 24, 2017 at 10:33 AM, Anna Taraday
>  wrote:
> > 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 
> 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
> >>  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 
> >> > 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  >
> >> >> wrote:
> >> >> > Newton is already shipped!
> >> >> >
> >> >> > -- Dims
> >> >> >
> >> >> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
> >> >> >  wrote:
> >> >> >> Galera only supported since Ocata?
> >> >> >>
> >> >> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas
> >> >> >> 
> >> >> >> 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
> >> >> >>>  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
> >> >> >>> > 
> >> >> >>> > 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
> >> >> >>> >>  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
> >> >>

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-24 Thread Davanum Srinivas 
Cool. Then i'd support a backport when the review against master
merges. Thanks Ann and Kirill.

-- Dims

On Tue, Jan 24, 2017 at 10:33 AM, Anna Taraday
 wrote:
> 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  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
>>  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 
>> > 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 
>> >> wrote:
>> >> > Newton is already shipped!
>> >> >
>> >> > -- Dims
>> >> >
>> >> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
>> >> >  wrote:
>> >> >> Galera only supported since Ocata?
>> >> >>
>> >> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas
>> >> >> 
>> >> >> 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
>> >> >>>  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
>> >> >>> > 
>> >> >>> > 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
>> >> >>> >>  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
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>>

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-24 Thread Anna Taraday 
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  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
>  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 
> 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 
> >> wrote:
> >> > Newton is already shipped!
> >> >
> >> > -- Dims
> >> >
> >> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
> >> >  wrote:
> >> >> Galera only supported since Ocata?
> >> >>
> >> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas  >
> >> >> 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
> >> >>>  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
> >> >>> > 
> >> >>> > 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
> >> >>> >>  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
> >> >>> >> >
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
>

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-24 Thread Davanum Srinivas 
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
 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  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 
>> wrote:
>> > Newton is already shipped!
>> >
>> > -- Dims
>> >
>> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
>> >  wrote:
>> >> Galera only supported since Ocata?
>> >>
>> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas 
>> >> 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
>> >>>  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
>> >>> > 
>> >>> > 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
>> >>> >>  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)
>> >>> >

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-24 Thread Anna Taraday 
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  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 
> wrote:
> > Newton is already shipped!
> >
> > -- Dims
> >
> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
> >  wrote:
> >> Galera only supported since Ocata?
> >>
> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas 
> 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
> >>>  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
> >>> >>  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

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-24 Thread Davanum Srinivas 
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  wrote:
> Newton is already shipped!
>
> -- Dims
>
> On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
>  wrote:
>> Galera only supported since Ocata?
>>
>> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas  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
>>>  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 
>>> > 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
>>> >>  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 ::

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-24 Thread Davanum Srinivas 
Newton is already shipped!

-- Dims

On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
 wrote:
> Galera only supported since Ocata?
>
> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas  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
>>  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 
>> > 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
>> >>  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

__
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

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-24 Thread Kirill Proskurin 
Galera only supported since Ocata?

On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas  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
>  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 
> > 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
> >>  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

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-24 Thread Davanum Srinivas 
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
 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 
> 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
>>  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

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-24 Thread Kirill Proskurin 
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 
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
>  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

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-23 Thread Ihar Hrachyshka 
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
 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

[openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-23 Thread Anna Taraday 
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