Mailing List Archive: [nova][placement][upgrade][qa] Some upgrade-specific news on extraction

[nova][placement][upgrade][qa] Some upgrade-specific news on extraction

Sep 6, 2018, 1:58 PM

Post #1 of 6 (1161 views)

I wanted to recap some upgrade-specific stuff from today outside of the
other [1] technical extraction thread.

Chris has a change up for review [2] which prompted the discussion.

That change makes placement only work with placement.conf, not
nova.conf, but does get a passing tempest run in the devstack patch [3].

The main issue here is upgrades. If you think of this like deprecating
config options, the old config options continue to work for a release
and then are dropped after a full release (or 3 months across boundaries
for CDers) [4]. Given that, Chris's patch would break the standard
deprecation policy. Clearly one simple way outside of code to make that
work is just copy and rename nova.conf to placement.conf and voila. But
that depends on *all* deployment/config tooling to get that right out of
the gate.

The other obvious thing is the database. The placement repo code as-is
today still has the check for whether or not it should use the placement
database but falls back to using the nova_api database [5]. So
technically you could point the extracted placement at the same nova_api
database and it should work. However, at some point deployers will
clearly need to copy the placement-related tables out of the nova_api DB
to a new placement DB and make sure the 'migrate_version' table is
dropped so that placement DB schema versions can reset to 1.

With respect to grenade and making this work in our own upgrade CI
testing, we have I think two options (which might not be mutually
exclusive):

1. Make placement support using nova.conf if placement.conf isn't found
for Stein with lots of big warnings that it's going away in T. Then
Rocky nova.conf with the nova_api database configuration just continues
to work for placement in Stein. I don't think we then have any grenade
changes to make, at least in Stein for upgrading *from* Rocky. Assuming
fresh devstack installs in Stein use placement.conf and a
placement-specific database, then upgrades from Stein to T should also
be OK with respect to grenade, but likely punts the cut-over issue for
all other deployment projects (because we don't CI with grenade doing
Rocky->Stein->T, or FFU in other words).

2. If placement doesn't support nova.conf in Stein, then grenade will
require an (exceptional) [6] from-rocky upgrade script which will (a)
write out placement.conf fresh and (b) run a DB migration script, likely
housed in the placement repo, to create the placement database and copy
the placement-specific tables out of the nova_api database. Any script
like this is likely needed regardless of what we do in grenade because
deployers will need to eventually do this once placement would drop
support for using nova.conf (if we went with option 1).

That's my attempt at a summary. It's going to be very important that
operators and deployment project contributors weigh in here if they have
strong preferences either way, and note that we can likely do both
options above - grenade could do the fresh cutover from rocky to stein
but we allow running with nova.conf and nova_api DB in placement in
stein with plans to drop that support in T.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/subject.html#134184
[2] https://review.openstack.org/#/c/600157/
[3] https://review.openstack.org/#/c/600162/
[4]
https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html#requirements
[5]
https://github.com/openstack/placement/blob/fb7c1909/placement/db_api.py#L27
[6] https://docs.openstack.org/grenade/latest/readme.html#theory-of-upgrade

--

Thanks,

Matt

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [nova][placement][upgrade][qa] Some upgrade-specific news on extraction [ In reply to ]

doug at doughellmann

Sep 6, 2018, 2:16 PM

Post #2 of 6 (1160 views)

Permalink

Excerpts from Matt Riedemann's message of 2018-09-06 15:58:41 -0500:
> I wanted to recap some upgrade-specific stuff from today outside of the
> other [1] technical extraction thread.
>
> Chris has a change up for review [2] which prompted the discussion.
>
> That change makes placement only work with placement.conf, not
> nova.conf, but does get a passing tempest run in the devstack patch [3].
>
> The main issue here is upgrades. If you think of this like deprecating
> config options, the old config options continue to work for a release
> and then are dropped after a full release (or 3 months across boundaries
> for CDers) [4]. Given that, Chris's patch would break the standard
> deprecation policy. Clearly one simple way outside of code to make that
> work is just copy and rename nova.conf to placement.conf and voila. But
> that depends on *all* deployment/config tooling to get that right out of
> the gate.
>
> The other obvious thing is the database. The placement repo code as-is
> today still has the check for whether or not it should use the placement
> database but falls back to using the nova_api database [5]. So
> technically you could point the extracted placement at the same nova_api
> database and it should work. However, at some point deployers will
> clearly need to copy the placement-related tables out of the nova_api DB
> to a new placement DB and make sure the 'migrate_version' table is
> dropped so that placement DB schema versions can reset to 1.
>
> With respect to grenade and making this work in our own upgrade CI
> testing, we have I think two options (which might not be mutually
> exclusive):
>
> 1. Make placement support using nova.conf if placement.conf isn't found
> for Stein with lots of big warnings that it's going away in T. Then
> Rocky nova.conf with the nova_api database configuration just continues
> to work for placement in Stein. I don't think we then have any grenade
> changes to make, at least in Stein for upgrading *from* Rocky. Assuming
> fresh devstack installs in Stein use placement.conf and a
> placement-specific database, then upgrades from Stein to T should also
> be OK with respect to grenade, but likely punts the cut-over issue for
> all other deployment projects (because we don't CI with grenade doing
> Rocky->Stein->T, or FFU in other words).

Making placement read from both files should be pretty straightforward,
right? It's possible to pass default_config_files and default_config_dirs
to oslo.config, and the functions that build the original defaults
are part of the public API (find_config_files and find_config_dirs
in oslo_config.cfg) so the placement service can call them twice
(with different "project" arguments) and merge the results before
initializing the ConfigOpts instance.

Doug

>
> 2. If placement doesn't support nova.conf in Stein, then grenade will
> require an (exceptional) [6] from-rocky upgrade script which will (a)
> write out placement.conf fresh and (b) run a DB migration script, likely
> housed in the placement repo, to create the placement database and copy
> the placement-specific tables out of the nova_api database. Any script
> like this is likely needed regardless of what we do in grenade because
> deployers will need to eventually do this once placement would drop
> support for using nova.conf (if we went with option 1).
>
> That's my attempt at a summary. It's going to be very important that
> operators and deployment project contributors weigh in here if they have
> strong preferences either way, and note that we can likely do both
> options above - grenade could do the fresh cutover from rocky to stein
> but we allow running with nova.conf and nova_api DB in placement in
> stein with plans to drop that support in T.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/subject.html#134184
> [2] https://review.openstack.org/#/c/600157/
> [3] https://review.openstack.org/#/c/600162/
> [4]
> https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html#requirements
> [5]
> https://github.com/openstack/placement/blob/fb7c1909/placement/db_api.py#L27
> [6] https://docs.openstack.org/grenade/latest/readme.html#theory-of-upgrade
>

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction [ In reply to ]

rochelle.grober at huawei

Sep 6, 2018, 5:39 PM

Post #3 of 6 (1160 views)

Permalink

Sounds like an important discussion to have with the operators in Denver. Should put this on the schedule for the Ops meetup.

--Rocky

> -----Original Message-----
> From: Matt Riedemann [mailto:mriedemos@gmail.com]
> Sent: Thursday, September 06, 2018 1:59 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>; openstack-
> operators@lists.openstack.org
> Subject: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-
> specific news on extraction
>
> I wanted to recap some upgrade-specific stuff from today outside of the
> other [1] technical extraction thread.
>
> Chris has a change up for review [2] which prompted the discussion.
>
> That change makes placement only work with placement.conf, not
> nova.conf, but does get a passing tempest run in the devstack patch [3].
>
> The main issue here is upgrades. If you think of this like deprecating config
> options, the old config options continue to work for a release and then are
> dropped after a full release (or 3 months across boundaries for CDers) [4].
> Given that, Chris's patch would break the standard deprecation policy. Clearly
> one simple way outside of code to make that work is just copy and rename
> nova.conf to placement.conf and voila. But that depends on *all*
> deployment/config tooling to get that right out of the gate.
>
> The other obvious thing is the database. The placement repo code as-is
> today still has the check for whether or not it should use the placement
> database but falls back to using the nova_api database [5]. So technically you
> could point the extracted placement at the same nova_api database and it
> should work. However, at some point deployers will clearly need to copy the
> placement-related tables out of the nova_api DB to a new placement DB and
> make sure the 'migrate_version' table is dropped so that placement DB
> schema versions can reset to 1.
>
> With respect to grenade and making this work in our own upgrade CI testing,
> we have I think two options (which might not be mutually
> exclusive):
>
> 1. Make placement support using nova.conf if placement.conf isn't found for
> Stein with lots of big warnings that it's going away in T. Then Rocky nova.conf
> with the nova_api database configuration just continues to work for
> placement in Stein. I don't think we then have any grenade changes to make,
> at least in Stein for upgrading *from* Rocky. Assuming fresh devstack installs
> in Stein use placement.conf and a placement-specific database, then
> upgrades from Stein to T should also be OK with respect to grenade, but
> likely punts the cut-over issue for all other deployment projects (because we
> don't CI with grenade doing
> Rocky->Stein->T, or FFU in other words).
>
> 2. If placement doesn't support nova.conf in Stein, then grenade will require
> an (exceptional) [6] from-rocky upgrade script which will (a) write out
> placement.conf fresh and (b) run a DB migration script, likely housed in the
> placement repo, to create the placement database and copy the placement-
> specific tables out of the nova_api database. Any script like this is likely
> needed regardless of what we do in grenade because deployers will need to
> eventually do this once placement would drop support for using nova.conf (if
> we went with option 1).
>
> That's my attempt at a summary. It's going to be very important that
> operators and deployment project contributors weigh in here if they have
> strong preferences either way, and note that we can likely do both options
> above - grenade could do the fresh cutover from rocky to stein but we allow
> running with nova.conf and nova_api DB in placement in stein with plans to
> drop that support in T.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-
> September/subject.html#134184
> [2] https://review.openstack.org/#/c/600157/
> [3] https://review.openstack.org/#/c/600162/
> [4]
> https://governance.openstack.org/tc/reference/tags/assert_follows-
> standard-deprecation.html#requirements
> [5]
> https://github.com/openstack/placement/blob/fb7c1909/placement/db_api
> .py#L27
> [6] https://docs.openstack.org/grenade/latest/readme.html#theory-of-
> upgrade
>
> --
>
> Thanks,
>
> Matt
>
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction [ In reply to ]

emccormick at cirrusseven

Sep 6, 2018, 6:29 PM

Post #4 of 6 (1160 views)

Permalink

On Thu, Sep 6, 2018, 8:40 PM Rochelle Grober <rochelle.grober@huawei.com>
wrote:

> Sounds like an important discussion to have with the operators in Denver.
> Should put this on the schedule for the Ops meetup.
>
> --Rocky
>

We are planning to attend the upgrade sessions on Monday as a group. How
about we put it there?

-Erik

>
> > -----Original Message-----
> > From: Matt Riedemann [mailto:mriedemos@gmail.com]
> > Sent: Thursday, September 06, 2018 1:59 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > <openstack-dev@lists.openstack.org>; openstack-
> > operators@lists.openstack.org
> > Subject: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-
> > specific news on extraction
> >
> > I wanted to recap some upgrade-specific stuff from today outside of the
> > other [1] technical extraction thread.
> >
> > Chris has a change up for review [2] which prompted the discussion.
> >
> > That change makes placement only work with placement.conf, not
> > nova.conf, but does get a passing tempest run in the devstack patch [3].
> >
> > The main issue here is upgrades. If you think of this like deprecating
> config
> > options, the old config options continue to work for a release and then
> are
> > dropped after a full release (or 3 months across boundaries for CDers)
> [4].
> > Given that, Chris's patch would break the standard deprecation policy.
> Clearly
> > one simple way outside of code to make that work is just copy and rename
> > nova.conf to placement.conf and voila. But that depends on *all*
> > deployment/config tooling to get that right out of the gate.
> >
> > The other obvious thing is the database. The placement repo code as-is
> > today still has the check for whether or not it should use the placement
> > database but falls back to using the nova_api database [5]. So
> technically you
> > could point the extracted placement at the same nova_api database and it
> > should work. However, at some point deployers will clearly need to copy
> the
> > placement-related tables out of the nova_api DB to a new placement DB and
> > make sure the 'migrate_version' table is dropped so that placement DB
> > schema versions can reset to 1.
> >
> > With respect to grenade and making this work in our own upgrade CI
> testing,
> > we have I think two options (which might not be mutually
> > exclusive):
> >
> > 1. Make placement support using nova.conf if placement.conf isn't found
> for
> > Stein with lots of big warnings that it's going away in T. Then Rocky
> nova.conf
> > with the nova_api database configuration just continues to work for
> > placement in Stein. I don't think we then have any grenade changes to
> make,
> > at least in Stein for upgrading *from* Rocky. Assuming fresh devstack
> installs
> > in Stein use placement.conf and a placement-specific database, then
> > upgrades from Stein to T should also be OK with respect to grenade, but
> > likely punts the cut-over issue for all other deployment projects
> (because we
> > don't CI with grenade doing
> > Rocky->Stein->T, or FFU in other words).
> >
> > 2. If placement doesn't support nova.conf in Stein, then grenade will
> require
> > an (exceptional) [6] from-rocky upgrade script which will (a) write out
> > placement.conf fresh and (b) run a DB migration script, likely housed in
> the
> > placement repo, to create the placement database and copy the placement-
> > specific tables out of the nova_api database. Any script like this is
> likely
> > needed regardless of what we do in grenade because deployers will need to
> > eventually do this once placement would drop support for using nova.conf
> (if
> > we went with option 1).
> >
> > That's my attempt at a summary. It's going to be very important that
> > operators and deployment project contributors weigh in here if they have
> > strong preferences either way, and note that we can likely do both
> options
> > above - grenade could do the fresh cutover from rocky to stein but we
> allow
> > running with nova.conf and nova_api DB in placement in stein with plans
> to
> > drop that support in T.
> >
> > [1]
> > http://lists.openstack.org/pipermail/openstack-dev/2018-
> > September/subject.html#134184
> > [2] https://review.openstack.org/#/c/600157/
> > [3] https://review.openstack.org/#/c/600162/
> > [4]
> > https://governance.openstack.org/tc/reference/tags/assert_follows-
> > standard-deprecation.html#requirements
> > [5]
> > https://github.com/openstack/placement/blob/fb7c1909/placement/db_api
> > .py#L27
> > [6] https://docs.openstack.org/grenade/latest/readme.html#theory-of-
> > upgrade
> >
> > --
> >
> > Thanks,
> >
> > Matt
> >
> > __________________________________________________________
> > ________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> > request@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@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Re: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction [ In reply to ]

dms at danplanet

Sep 7, 2018, 8:17 AM

Post #5 of 6 (1160 views)

Permalink

> The other obvious thing is the database. The placement repo code as-is
> today still has the check for whether or not it should use the
> placement database but falls back to using the nova_api database
> [5]. So technically you could point the extracted placement at the
> same nova_api database and it should work. However, at some point
> deployers will clearly need to copy the placement-related tables out
> of the nova_api DB to a new placement DB and make sure the
> 'migrate_version' table is dropped so that placement DB schema
> versions can reset to 1.

I think it's wrong to act like placement and nova-api schemas are the
same. One is a clone of the other at a point in time, and technically it
will work today. However the placement db sync tool won't do the right
thing, and I think we run the major risk of operators not fully grokking
what is going on here, seeing that pointing placement at nova-api
"works" and move on. Later, when we add the next placement db migration
(which could technically happen in stein), they will either screw their
nova-api schema, or mess up their versioning, or be unable to apply the
placement change.

> With respect to grenade and making this work in our own upgrade CI
> testing, we have I think two options (which might not be mutually
> exclusive):
>
> 1. Make placement support using nova.conf if placement.conf isn't
> found for Stein with lots of big warnings that it's going away in
> T. Then Rocky nova.conf with the nova_api database configuration just
> continues to work for placement in Stein. I don't think we then have
> any grenade changes to make, at least in Stein for upgrading *from*
> Rocky. Assuming fresh devstack installs in Stein use placement.conf
> and a placement-specific database, then upgrades from Stein to T
> should also be OK with respect to grenade, but likely punts the
> cut-over issue for all other deployment projects (because we don't CI
> with grenade doing Rocky->Stein->T, or FFU in other words).

As I have said above and in the review, I really think this is the wrong
approach. At the current point of time, the placement schema is a clone
of the nova-api schema, and technically they will work. At the first point
that placement evolves its schema, that will no longer be a workable
solution, unless we also evolve nova-api's database in lockstep.

> 2. If placement doesn't support nova.conf in Stein, then grenade will
> require an (exceptional) [6] from-rocky upgrade script which will (a)
> write out placement.conf fresh and (b) run a DB migration script,
> likely housed in the placement repo, to create the placement database
> and copy the placement-specific tables out of the nova_api
> database. Any script like this is likely needed regardless of what we
> do in grenade because deployers will need to eventually do this once
> placement would drop support for using nova.conf (if we went with
> option 1).

Yep, and I'm asserting that we should write that script, make grenade do
that step, and confirm that it works. I think operators should do that
step during the stein upgrade because that's where the fork/split of
history and schema is happening. I'll volunteer to do the grenade side
at least.

Maybe it would help to call out specifically that, IMHO, this can not
and should not follow the typical config deprecation process. It's not a
simple case of just making sure we "find" the nova-api database in the
various configs. The problem is that _after_ the split, they are _not_
the same thing and should not be considered as the same. Thus, I think
to avoid major disaster and major time sink for operators later, we need
to impose the minor effort now to make sure that they don't take the
process of deploying a new service lightly.

Jay's original relatively small concern was that deploying a new
placement service and failing to properly configure it would result in a
placement running with the default, empty, sqlite database. That's a
valid concern, and I think all we need to do is make sure we fail in
that case, explaining the situation.

We just had a hangout on the topic and I think we've come around to the
consensus that just removing the default-to-empty-sqlite behavior is the
right thing to do. Placement won't magically find nova.conf if it exists
and jump into its database, and it also won't do the silly thing of
starting up with an empty database if the very important config step is
missed in the process of deploying placement itself. Operators will have
to deploy the new package and do the database surgery (which we will
provide instructions and a script for) as part of that process, but
there's really no other sane alternative without changing the current
agreed-to plan regarding the split.

Is everyone okay with the above summary of the outcome?

--Dan

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction [ In reply to ]

mnaser at vexxhost

Sep 7, 2018, 8:24 AM

Post #6 of 6 (1160 views)

Permalink

On Fri, Sep 7, 2018 at 11:18 AM Dan Smith <dms@danplanet.com> wrote:
>
> > The other obvious thing is the database. The placement repo code as-is
> > today still has the check for whether or not it should use the
> > placement database but falls back to using the nova_api database
> > [5]. So technically you could point the extracted placement at the
> > same nova_api database and it should work. However, at some point
> > deployers will clearly need to copy the placement-related tables out
> > of the nova_api DB to a new placement DB and make sure the
> > 'migrate_version' table is dropped so that placement DB schema
> > versions can reset to 1.
>
> I think it's wrong to act like placement and nova-api schemas are the
> same. One is a clone of the other at a point in time, and technically it
> will work today. However the placement db sync tool won't do the right
> thing, and I think we run the major risk of operators not fully grokking
> what is going on here, seeing that pointing placement at nova-api
> "works" and move on. Later, when we add the next placement db migration
> (which could technically happen in stein), they will either screw their
> nova-api schema, or mess up their versioning, or be unable to apply the
> placement change.
>
> > With respect to grenade and making this work in our own upgrade CI
> > testing, we have I think two options (which might not be mutually
> > exclusive):
> >
> > 1. Make placement support using nova.conf if placement.conf isn't
> > found for Stein with lots of big warnings that it's going away in
> > T. Then Rocky nova.conf with the nova_api database configuration just
> > continues to work for placement in Stein. I don't think we then have
> > any grenade changes to make, at least in Stein for upgrading *from*
> > Rocky. Assuming fresh devstack installs in Stein use placement.conf
> > and a placement-specific database, then upgrades from Stein to T
> > should also be OK with respect to grenade, but likely punts the
> > cut-over issue for all other deployment projects (because we don't CI
> > with grenade doing Rocky->Stein->T, or FFU in other words).
>
> As I have said above and in the review, I really think this is the wrong
> approach. At the current point of time, the placement schema is a clone
> of the nova-api schema, and technically they will work. At the first point
> that placement evolves its schema, that will no longer be a workable
> solution, unless we also evolve nova-api's database in lockstep.
>
> > 2. If placement doesn't support nova.conf in Stein, then grenade will
> > require an (exceptional) [6] from-rocky upgrade script which will (a)
> > write out placement.conf fresh and (b) run a DB migration script,
> > likely housed in the placement repo, to create the placement database
> > and copy the placement-specific tables out of the nova_api
> > database. Any script like this is likely needed regardless of what we
> > do in grenade because deployers will need to eventually do this once
> > placement would drop support for using nova.conf (if we went with
> > option 1).
>
> Yep, and I'm asserting that we should write that script, make grenade do
> that step, and confirm that it works. I think operators should do that
> step during the stein upgrade because that's where the fork/split of
> history and schema is happening. I'll volunteer to do the grenade side
> at least.
>
> Maybe it would help to call out specifically that, IMHO, this can not
> and should not follow the typical config deprecation process. It's not a
> simple case of just making sure we "find" the nova-api database in the
> various configs. The problem is that _after_ the split, they are _not_
> the same thing and should not be considered as the same. Thus, I think
> to avoid major disaster and major time sink for operators later, we need
> to impose the minor effort now to make sure that they don't take the
> process of deploying a new service lightly.

I think that's a valid different approach. I'd be okay with this if
the appropriate
scripts and documentation is out there. In this case, Grenade stuff
will be really
useful asset to look over upgrades with.

> Jay's original relatively small concern was that deploying a new
> placement service and failing to properly configure it would result in a
> placement running with the default, empty, sqlite database. That's a
> valid concern, and I think all we need to do is make sure we fail in
> that case, explaining the situation.

If it's a hard fail, that seems reasonable and ensures no surprises occur
during the upgrade or much later.

> We just had a hangout on the topic and I think we've come around to the
> consensus that just removing the default-to-empty-sqlite behavior is the
> right thing to do. Placement won't magically find nova.conf if it exists
> and jump into its database, and it also won't do the silly thing of
> starting up with an empty database if the very important config step is
> missed in the process of deploying placement itself. Operators will have
> to deploy the new package and do the database surgery (which we will
> provide instructions and a script for) as part of that process, but
> there's really no other sane alternative without changing the current
> agreed-to plan regarding the split.
>
> Is everyone okay with the above summary of the outcome?

I've dropped my -1 from this given the discussion

https://review.openstack.org/#/c/600157/

> --Dan
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser@vexxhost.com
W. http://vexxhost.com

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators