Open Stack

On Thu, Sep 6, 2018, 8:40 PM Rochelle Grober <rochelle.grober at 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 at gmail.com]
> > Sent: Thursday, September 06, 2018 1:59 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > <openstack-dev at lists.openstack.org>; openstack-
> > operators at 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180906/fb058890/attachment.html>