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