Open Stack

There's been some progress on the technical side of extracting
placement to it own repo. The summary is:

* https://git.openstack.org/cgit/openstack/placement exists
* https://review.openstack.org/#/c/599416/ is at the top of a
   series of patches. That patch is passing and voting on unit and
   functional for py 2.7 and 3.5 and is passing pep8.

More below, in the steps.

On Tue, 28 Aug 2018, Chris Dent wrote:
> On Mon, 27 Aug 2018, melanie witt wrote:
>> 1. We copy the placement code into the openstack/placement repo and have it 
>> passing all of its own unit and functional tests.
>
> To break that down to more detail, how does this look?
> (note the ALL CAPS where more than acknowledgement is requested)
>
> 1.1 Run the git filter-branch on a copy of nova
>    1.1.1 Add missing files to the file list:
>          1.1.1.1 .gitignore
>          1.1.1.2 # ANYTHING ELSE?
> 1.2 Push -f that thing, acknowledge to be broken, to a seed repo on github
>    (ed's repo should be fine)
> 1.3 Do the repo creation bits described in
>    https://docs.openstack.org/infra/manual/creators.html
>    to seed openstack/placement
>    1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic
>    func and unit # INPUT DESIRED HERE
> 1.4 Once the repo exists with some content, incrementally bring it to
>    working
>    1.4.1 Update tox.ini to be placement oriented
>    1.4.2 Update setup.cfg to be placement oriented
>    1.4.3 Correct .stesr.conf
>    1.4.4 Move base of placement to "right" place
>    1.4.5 Move unit and functionals to right place
>    1.4.6 Do automated path fixings
>    1.4.7 Set up translation domain and i18n.py corectly
>    1.4.8 Trim placement/conf to just the conf settings required
>          (api, base, database, keystone, paths, placement)
>    1.4.9 Remove database files that are not relevant (the db api is
>          not used by placement)
>    1.4.10 Fix the Database Fixture to be just one database
>    1.4.11 Disable migrations that can't work (because of
>           dependencies on nova code, 014 and 030 are examples)
>           # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL

030 is okay as long as nothing goes wrong. If something does it
raises exceptions which would currently fail as the exceptions are
not there. See below for more about exceptions.

>    1.4.12 Incrementally get tests working
>    1.4.13 Fix pep8
> 1.5 Make zuul pep, unit and functional voting

This is where we are now at https://review.openstack.org/#/c/599416/

> 1.6 Create tools for db table sync/create

It made some TODOs about this in setup.cfg, also nothing that in
additional to a placement-manage we'll want a placement-status.

> 1.7 Concurrently go to step 2, where the harder magic happens.
> 1.8 Find and remove dead code (there will be some).

Some dead code has been removed, but there will definitely be plenty
more to find.

> 1.9 Tune up and confirm docs
> 1.10 Grep for remaining "nova" (as string and spirit) and fix

> Item 1.4.12 may deserve some discussion. When I've done this the
> several times before, the strategy I've used is to be test driven:
> run either functional or unit tests, find and fix one of the errors
> revealed, commit, move on.

In the patch set that ends with the review linked above, this is
pretty much what I did. Switching between a tox run of the full
suite and using testtools.run to run an individual test file.

>> 2. We have a stack of changes to zuul jobs that show nova working but 
>> deploying placement in devstack from the new repo instead of nova's repo. 
>> This includes the grenade job, ensuring that upgrade works.

Do people have the time or info needed to break this step down into
multiple steps like the '1' section above. Things I can think of:

* devstack patch to deploy placement from the new repo
   * and use placement.conf
* stripping of placement out of nova, a bit like
   https://review.openstack.org/#/c/596291/ , unless we leave that
   enitrely to step 4
* grenade tweaks (?)
* more

>> 3. When those pass, we merge them, effectively orphaning nova's copy of 
>> placement. Switch those jobs to voting.
>> 
>> 4. Finally, we delete the orphaned code from nova (without needing to make 
>> any changes to non-placement-only test code -- code is truly orphaned).

Some questions I have:

* Presumably we can trim the placement DB migrations to just stuff
   that is relevant to placement and renumber accordingly?

* Could we also make it so we only run the migrations if we are not
   in a fresh install? In a fresh install we ought to be able to skip
   the migrations entirely and create the tables by reflection with
   the class models [1].

* I had another but I forgot.

[1] I did something similar to placedock for when starting from
scratch:
https://github.com/cdent/placedock/blob/b5ca753a0d97e0d9a324e196349e3a19eb62668b/sync.py#L68-L73


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent