Repropose spec for updating user data
Change-Id: Id094d9846c52191e541b91beecf00ee1b073773c Signed-off-by: Jan Hartkopf <jhartkopf@inovex.de> Co-Authored-By: Christian Rohmann <christian.rohmann@inovex.de>
This commit is contained in:
Jan Hartkopf
Christian Rohmann
parent
ae9a0631ea
commit
8162e70bd3
|
|
@ -0,0 +1,223 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================================
|
||||
Update userdata
|
||||
==========================================
|
||||
|
||||
https://blueprints.launchpad.net/nova/+spec/update-userdata
|
||||
|
||||
It should be possible to update an instance's user data without
|
||||
the need to rebuild the corresponding instance.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Currently, it is not possible to update an instance's user data without
|
||||
rebuilding it.
|
||||
|
||||
Rebuilding takes much more time than just propagating updated user data,
|
||||
e. g. via cloud-init, and may be unfavorable in production.
|
||||
|
||||
Additionally, other public cloud providers like Azure [1] have the
|
||||
functionality to update user data for an existing instance, so
|
||||
end users may expect this to work in Nova as well.
|
||||
|
||||
AWS requires the instance to be powered off [2] before updating user data
|
||||
and Google also allows updates at any time [3][4].
|
||||
|
||||
| [1] https://docs.microsoft.com/en-us/azure/virtual-machines/user-data#what-is-user-data
|
||||
| [2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html#user-data-view-change
|
||||
| [3] https://cloud.google.com/container-optimized-os/docs/how-to/create-configure-instance#using_cloud-init_with_the_cloud_config_format
|
||||
| [4] https://cloud.google.com/compute/docs/reference/rest/v1/instances/setMetadata
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
As a user, I want to dynamically reconfigure the time and name servers used
|
||||
by my instance via user data in order to update theses settings using the
|
||||
same interface (user data) I initially used to bootstrap the instance.
|
||||
|
||||
As a user with experience at provisioning ephemeral workloads with tools like
|
||||
cloud-init, I would like to manage my stateful workload via user data and
|
||||
metadata on each boot. Metadata is used to store my external configuration
|
||||
while user data is used to perform operations like rejoining a cluster when the
|
||||
update has been applied.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
A new server action (``POST /servers/{server_id}/action``) called
|
||||
``userdata_update`` should be added.
|
||||
This endpoint can be called by the user to request a change in user data.
|
||||
Like with other actions, the status of the action can be viewed via
|
||||
``GET /servers/{server_id}/os-instance-actions/{request_id}``, and an
|
||||
according instance action event will be recorded in the database.
|
||||
|
||||
The handling of updates will be different, depending on whether the
|
||||
instance is configured via metadata service or via config drive.
|
||||
|
||||
If the instance uses the metadata service, user data will be updated
|
||||
directly and is then available to the instance. The according action state
|
||||
will be set to ``compute_userdata_updated``, indicating that the user data
|
||||
update has been successfully applied.
|
||||
|
||||
Otherwise, if the instance uses a config drive, the config drive,
|
||||
holding the user data, requires regeneration.
|
||||
As this is dependent on the configured compute driver, user data updates
|
||||
for config drives will only be available with compute drivers implementing
|
||||
config drive regeneration.
|
||||
|
||||
When the action is called, the following will be executed in order:
|
||||
|
||||
* If instance state is not ``STOPPED``, ``SHELVED`` or ``SHELVED_OFFLOADED``,
|
||||
return 409.
|
||||
|
||||
* If instance state is ``SHELVED`` or ``SHELVED_OFFLOADED``, user data can be
|
||||
directly updated in the database since ``UNSHELVE`` will automatically
|
||||
(re-)create the config drive. Update metadata and return 202.
|
||||
|
||||
* Otherwise, instance state is ``STOPPED``. Check if compute driver supports
|
||||
config drive regeneration. If not, return 409 and update action
|
||||
state to ``Failed``.
|
||||
|
||||
* Call a new RPC method which starts the config drive regeneration.
|
||||
If successful, update action state to ``compute_userdata_updated``, or
|
||||
``Failed`` otherwise.
|
||||
|
||||
The new RPC method will be used to ensure that only updated compute hosts
|
||||
can start config drive regeneration. This will be accompanied by a RPC version
|
||||
increase.
|
||||
|
||||
The new user data will be sent along with the RPC request, starting the
|
||||
config drive regeneration. Only if it was successful, the new user data will
|
||||
also be updated in the database and the action state will be set to
|
||||
``compute_userdata_updated``. Thus, if regeneration failed, the database will
|
||||
not be updated and the action state will be set to ``Failed``.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
None
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
The ``POST /servers/{server_id}/action`` API is extended by the
|
||||
``userdata_update`` parameter. This is added in a new microversion.
|
||||
|
||||
* POST /servers/{server_id}/action
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"userdata_update": {
|
||||
"userdata": "data",
|
||||
}
|
||||
}
|
||||
|
||||
The above is an example of a request which changes the user data
|
||||
to ``data``.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
The new instance action will send start and end notifications for the action.
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
The option to update user data with openstackclient is required:
|
||||
``openstack server set --user-data {data} {server_id}``
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Upgrade impact
|
||||
--------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
jhartkopf
|
||||
|
||||
Feature Liaison
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Implement API changes
|
||||
* Add tests
|
||||
* Add docs
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
* openstackclient needs to be updated to implement this change
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
* Add unit tests (positive and negative)
|
||||
* Add functional test (API samples)
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
The API reference needs to be updated to reflect the new microversion's
|
||||
feature.
|
||||
|
||||
In addition, make clear that user data is mutable but also that it does not
|
||||
replace proper config management.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Yoga
|
||||
- Introduced
|
||||
* - Zed
|
||||
- Reproposed
|
||||
* - Antelope
|
||||
- Reproposed
|
||||
Loading…
Reference in New Issue