This is a followup to Placement Container Playground

Since its inception there's been a plan that the OpenStack Placement service will be extracted from the nova code repository into a repository of its own. There are a variety of reasons for this, including:

• Nova is already huge.

• It could help to ensure that Placement evolves as a service that is useful to all OpenStack services, not just Nova.

• A different set of core reviewers and leaders could build up around the system who don't need expertise in all of Nova to be effective caretakers of Placement.

• Small things are easier to maintain and reason about.

• An independent Placement can be architecturally different from Nova without causing complexity within a shared repo.

It was with these ideas in mind that Placement was born, but inside of Nova. The choice to start in Nova was one of pragramtism and expediency. Awareness of an eventual departure allowed some differences in how things are done:

• Placement uses its own WSGI framework.

• Placement does not use a paste.ini file.

• Placement uses gabbi for functional API testing.

But some things were done the same:

• Objects that represent the entities in the Placement system are based on and within the nova.objects versioned objects hierarchy. Initially the objects were versioned and made available for RPC, but eventually that was turned off as it wasn't required.

• Placement data are persisted in the nova_api database.

• A few pieces of WSGI middleware were borrowed from Nova.

• Placement shares its configuration file with nova, using nova.conf.

Recently I've started exploring what it will take to change things so that Placement either can be extracted, or if not extracted, at least run with minimal nova code imported into the Placement service.

Placement is designed to be run in a lightweight and distributed fashion with many small web services running against the same data store. The earlier Placement Container Playground describes some of the work that started that.

Through that exploration several areas of future work were discovered:

• Throughout Nova, the __init__.py file in some packages includes code that causes a cascade of imports. Any sub-package which is "below" one of these busy __init__.py is subject to those imports, even if it doesn't need them.

  One particular area of concern for this is near the top of the nova.api.openstack package. I've explored some options for resolving this with Refactor WSGI apps and utils to limit imports.

  Of course nova/__init__.py itself imports code, including eventlet, which is not used by Placement, so that remains to be resolved. Even without being concerned about Placement, this is something that should be fixed as Nova is made up of multiple processes: they don't all need all the code.

  Fixing these things "simply" requires attention to the problem and recognition that it needs to be fixed.

• By existing within the nova.objects hierarchy, the Placement-related versioned objects must co-exist with all of the nova versioned objects, none of which are used by Placement, but all of which are automatically loaded by nova/objects/__init__.py. Move resource provider objects into placement hierarchy explores moving the objects within the Placement hierarchy.

  In the process the ResourceClass field has to be made independent as it is used by both the Nova and Placement sides of their interaction.

• The Nova FaultWrapper was being used, but it turns out it is doing more work that it needs to and a simpler version can be used instead.

• All of the interaction with the database that Placement does is done within the objects. The code that comes from elsewhere is the api_context_manager, resource_class_cache, the table models, and database migrations.

  Long time ago and far away the idea of an Optional separate database for placement API was declared worth exploring. I've been maintaining that branch ever since. It's lets people use a different configuration setting for the database URL for placement.

  In the container experiments that configuration setting is used, but it points to the nova_api database.

Migrations are considered a significant challenge for extracting Placement to an independent repository and service. I'm not certain this has to be the case, especially if we are willing to consider:

• Letting Placement point to the nova_api database for people who prefer to do things that way.

• Freezing the schema for Placement-related data entities for some amount of time.

• Allowing, and in fact encouraging, the Placement service to be capable of reconstructing itself. This means:

  • Any resource provider regularly checks for its own existence and recreates itself as required (this is already true).
  • Any resource provider can be caused to correct its own allocations (this is not currently true).

  If we have that, then the content of a Placement database can be remade. This makes it capable of recovering from a catastrophe, or just making itself right when for some reason the datastore gets out of sync with reality.

The way to make progress on this is to experiment, iterate, and communicate.