Open Stack

tl;dr: I'd prefer not to be Placement PTL for the U cycle. I've
accomplished most of what I set out to do and I think we have
other members of the team who would make excellent PTLs (notably
tetsuro and gibi).

Longer version:

Getting placement standing on its own feet, with a mostly reasonable
architecture, reasonable performance, and a fairly complete set of
features has pretty much been my single focus since the start of
2016. From both a personal and professional standpoint I need to
focus some energy elsewhere, lest the deep ruts in my brain become
permanent.

I think it is important to not be shy about the goal of that three
and a half year process: Get placement out of nova and get nova out
of placement. The architectural differences necessary to make
placement work well, be maintainable, and easily deployable [1]
we're difficult to do within nova (for many reasons), but once
extracted took a matter of days.

Nova, neutron, blazar, zun, watcher, and cyborg all use, or are in
the process of starting to use, placement. Ironic is thinking about
it.

So: some success.

But it's not all gravy, there are still some things left to do:

While the fundamental concept of placement (presenting and keeping
track of inventory of resources) is pretty straightforward, using it
most effectively can be complicated, especially if nested resource
providers are involved. There's a lot of work to be done to
document how to best model data and queries. As the number of
resources in the cloud grows it becomes increasingly important to 
"ask better questions"; knowing how to do that shouldn't require 3
years of experience.

The "consumer types" feature is in flight. It will allow placement
to be used to keep track of resource usage for some types of quota,
which makes good sense: If we're already tracking "user X is using N
VCPU" in placement it's wasteful tracking it somewhere else as well.

Placement sharding, so that one placement can track multiple
domains, is a feature that we've discussed in the last couple of
years, thinking perhaps it could be useful to edge setups. Until the
recent performance improvements it wouldn't have worked well, but
now it might. However, until real users present themselves with a
need for this feature, there's not much point moving forward with
it.

We should continue to do benchmarking and profiling. That work has
done wonders to reveal unexpected areas for improvement. Being
willing and able to analyse and adjust the system and the code,
continuously, is key to ensuring the project does not become
moribund or calcified.

Thanks to everyone who has helped get placement to a healthy place.

[1] For some examples: We've taken a common benchmark from 17s to
.5s. It's now possible to run placement without a config file or
without a manual database sync. Every module has a maintainability
index of "A". Placement doesn't use eventlet (and is not
accidentally infected by it) so it can benefit from whatever
threading or multi-processing model whatever chosen WSGI server
provides. Placement is a simple web app over a (not so simple)
persistence and query layer. The web app and the associated database
server(s) can be scaled independently, up and out.


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