8.3 KiB
Optional Placement Database
https://blueprints.launchpad.net/nova/+spec/optional-placement-database
Since its inception there's been a long term goal of extracting the placement services to its own repository from which it can be packaged and operated as an independent service. Work to make this happen has been in progress for quite some time, but one limiting factor is management of the placement database connection and the placement data. At the moment placement data is kept in the same database as the nova API.
Discussion at the Rocky PTG and elsewhere indicates that providing deployers with options for how to manage the placement data will ease migration. This spec proposes separating the configuration of the placement database connection to its own setting that falls back to the nova api database setting when not defined. This provides a variety of management options and also cleans up the code for eventual migration in a useful way (details below).
Problem description
We'd like to make it easy for deployers to manage their placement
data in whatever way they like. While there are many factors in this,
one thing that makes doing so more complicated now is that the
connection to the placement database is configured using the
[api_database]/connection
configuration setting, so
isolating placement database configuration is not easy. There are many
ways around this problem (see the alternatives
below) but using a distinct configuration
option is explicit and translates well into a future when the same
configuration setting can be used (limiting changes to the name of a
file, rather than the name of a configuration setting).
At the same time we'd like to make it easy for developers of placement to start limiting the extent to which other nova code is imported into code that is dedicated to placement. Using a separate configuration setting makes it possible to easily isolate establishing the database session (see the isolation work in progress).
Similarly, we'd like to provide opportunities for packagers to lay the groundwork for migrations where data management has a clearly identifiable entry point.
Use Cases
As a deployer, I want to configure my new placement service to save data to its own database because I know that in the future I will be able to use it separately.
As a different deployer, I want to configure my placement service to continue using the nova api database because I don't care about having separate databases.
As a packager, I want to allow my users to have granular control over the location of the placement database by using the "normal" method of setting configuration.
As a developer, I want to prepare for placement's extraction by limiting overlap between placement and nova code.
Proposed change
There are two main changes proposed here.
Placement database connection
One is to add a configuration group, placement_database
that operates in the same fashion (and with the same options) as the
existing api_database
group. If
[placement_database]/connection
is set, then its value is
used for an independent connection to the described database. If it is
not set, the connection string from
[api_database]/connection
is used, but it is identified as
a separate SQLAlchemy session.
This has the advantage of being reusable once placement is extracted. The same configuration group and names can continue to be used in the future.
There is a database connection work in progress.
Isolated placement database configuration
Once there is a separate SQLAlchemy session for the connection to whatever hosts the placement data, it is possible to manage that session independently of the main nova code. This is useful for centralizing the placement code into itself, easing the eventual extraction and supporting the ongoing cleanup of the placement code. There is an isolation work in progress.
Alternatives
The primary alternative here is to do nothing other than document the way that deployers can run the placement service with its own configuration file; one that sets the API database connection to whatever database the deployer would like to use for placement. This is definitely a workable solution but does not lay the foundation for a cleaner configuration, nor the isolation of the database configuration mentioned above.
Data model impact
This change does not involve changing the data model itself. For the time being migrations and database schema continue to be managed in the same way. If there is simultaneously both an API and placement database, they will create the same tables and run the same migrations (in different databases). Future work will address managing migrations and schema within placement.
REST API impact
None.
Security impact
If a new database is used, then deployments will need to adapt any security measures to be aware of it.
Notifications impact
None.
Other end user impact
Database management in placement should be invisible to end users of placement.
Performance Impact
Using a separate database increases options for managing scaling and performance. Presumably separating placement and nova API activity into different database servers could be useful.
Other deployer impact
Besides the configuration options already mentioned, deployers will need to be aware of the several different ways they can manage and migrate their placement data. At this time the plan is to document these things, based on experimentation that has not yet been done. These changes will enable some of that experimentation.
This spec explicitly does not provide definite guidance for how a deployer would upgrade from a placement-within-nova deployment to a placement-not-in-nova deployment. It is laying groundwork for that.
Developer impact
Other than being aware of it, there's no functional change to how developers will work on placement.
Upgrade impact
This spec explicitly does not address concerns related to upgrading come a system where placement is not extracted to one where it is. This work is a precursor to that.
If this configuration change is merged in Rocky but placement is not extracted in the S cycle, then there will be no upgrade concerns. Existing configurations will continue to work.
Implementation
Assignee(s)
- Primary assignee:
-
cdent
- Other contributors:
-
volunteers
Work Items
This work has started in database connection work in progress and isolation work in progress.
- Create the [placement_database] configuration group.
- Document that group.
- Update test fixtures to reflect the new placement database session.
- Update unit and functional tests to use the new session.
- Update placement database context managers to use the new session.
- Isolate session configuration within placement.
- Update contributor and user documentation that discusses the placement database.
Dependencies
None.
Testing
Existing functional tests will continue to exercise the use of the database. If we choose to do so, we can add or adjust an existing gate job to set and use a different placement database connection.
Documentation Impact
A medium term goal of this work is to make it easy to do experiments that will help create clear documentation for migration strategies when placement is extracted.
References
History
Release Name | Description |
---|---|
Rocky | Introduced |