Open Stack

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
<akamyshnikova at mirantis.com> 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 <davanum at 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
>> <akamyshnikova at 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 <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
>> >
>> >
>> > __________________________________________________________________________
>> > 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
>
> --
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims