Persist RequestSpec object¶
Persist the RequestSpec object used for scheduling an instance.
There are a few times that it would be useful to have the RequestSpec used for originally scheduling an instance where it is not currently available, such as during a resize/migrate. In order to have later scheduling requests operate under the same constraints as the original we should retain the RequestSpec for these later scheduling calls.
Going forward with cells it will be necessary to store a RequestSpec before an instance is created so that the API can return details on the instance before it has been scheduled.
Operators/users want to move an instance through a migration or resize and want the destination to satisfy the same requirements as the source.
A save() method will be added to the RequestSpec object. This will store the RequestSpec in the database. Since this is also a part of the cells effort it will be possible to stor in both the api and regular nova database. Which database it’s stored in on save() will be determined by the context used.
Parts of it could be put into the instance_extra table. Because later this will be persisted in the api database before scheduling and then moved to the cell database after scheduling it is beneficial to just store it in a table that can exist in both.
Data model impact¶
A new database table will be added to both the api and cell database. The schema will match what is necessary for the RequestSpec object to be stored. Since it is not yet implemented it’s of little use to finalize the design here.
REST API impact¶
Other end user impact¶
None here, but this will allow for resizes to be scheduled like the original boot request.
An additional database write will be incurred.
Other deployer impact¶
Same as for users, nothing here but this opens up future changes.
- Primary assignee:
Add a new table to the api and cell/current database
Add the save() method to the RequestSpec object
Call the save() method in the code at the appropriate place
New unit tests will be added. This is not externally facing in a way that Tempest can test.
Devref documentation will be added explaining the existence of this data for use in scheduling.