Track user_id/project_id for migrations¶
https://blueprints.launchpad.net/nova/+spec/add-user-id-field-to-the-migrations-table
The blueprint proposes tracking the user_id and project_id of the user that initiated a server migration and exposing those values in the API.
Problem description¶
By default, all server actions which create a migration record (live migration, cold migration, resize, evacuate) except resize are initiated by an admin who might not own the server. There could be multiple users within the same admin project who migrate (or evacuate) servers. The migrations APIs do not expose information about who actually migrated the server which is important for auditing. The instance actions API does record the initiating user/project but trying to correlate the instance actions to the migrations can be complicated and error prone, especially if multiple migrations occur on the same server in the same day.
Use Cases¶
As an (admin) user, I would like to know who operates the instance through the instance migration history without having to try and stitch that information together from the migrations and instance actions APIs.
Proposed change¶
When creating a Migration record, store the user_id
and project_id
from the request context, similar to an InstanceAction record.
In a new microversion, expose the user_id
and project_id
fields in the
following APIs:
GET /os-migrations
GET /servers/{server_id}/migrations
GET /servers/{server_id}/migrations/{migration_id}
In addition, the GET /os-migrations
request will add optional user_id
and project_id
query parameters for filtering migrations by user or
project.
Alternatives¶
As noted above, each operation that generates a migration record will also have an instance action and the instance action records the user_id and project_id of who made the request. However, there is no other direct link between the instance action record and the migration record so trying to use the actions to correlate that information to the migrations can be complicated and error prone, especially if a server is moved multiple times in the same day. Since migration records are a top-level resource in the API like servers, it makes sense for them to include the user_id/project_id like servers when they are created and by whom.
Data model impact¶
Add user_id
and project_id
columns to the migrations
table. The
schema will be the same as in the instances
and instance_actions
tables:
user_id = Column(String(255))
project_id = Column(String(255))
The columns will be nullable since existing records would not have values for those columns.
REST API impact¶
In a new microversion, expose the user_id
and project_id
parameters
in the following API responses:
GET /os-migrations
{ "migrations": [ { "created_at": "2012-10-29T13:42:02.000000", "dest_compute": "compute2", "dest_host": "1.2.3.4", "dest_node": "node2", "id": 1234, "instance_uuid": "8600d31b-d1a1-4632-b2ff-45c2be1a70ff", "new_instance_type_id": 2, "old_instance_type_id": 1, "source_compute": "compute1", "source_node": "node1", "status": "done", "updated_at": "2012-10-29T13:42:02.000000", "migration_type": "migration", "uuid": "42341d4b-346a-40d0-83c6-5f4f6892b650", "user_id": "ef9d34b4-45d0-4530-871b-3fb535988394", "project_id": "011ee9f4-8f16-4c38-8633-a254d420fd54" } ] }
GET /servers/{server_id}/migrations
{ "migrations": [ { "created_at": "2016-01-29T13:42:02.000000", "dest_compute": "compute2", "dest_host": "1.2.3.4", "dest_node": "node2", "id": 1, "server_uuid": "4cfba335-03d8-49b2-8c52-e69043d1e8fe", "source_compute": "compute1", "source_node": "node1", "status": "running", "memory_total_bytes": 123456, "memory_processed_bytes": 12345, "memory_remaining_bytes": 111111, "disk_total_bytes": 234567, "disk_processed_bytes": 23456, "disk_remaining_bytes": 211111, "updated_at": "2016-01-29T13:42:02.000000", "uuid": "12341d4b-346a-40d0-83c6-5f4f6892b650", "user_id": "ef9d34b4-45d0-4530-871b-3fb535988394", "project_id": "011ee9f4-8f16-4c38-8633-a254d420fd54" } ] }
GET /servers/{server_id}/migrations/{migration_id}
{ "migration": { "created_at": "2016-01-29T13:42:02.000000", "dest_compute": "compute2", "dest_host": "1.2.3.4", "dest_node": "node2", "id": 1, "server_uuid": "4cfba335-03d8-49b2-8c52-e69043d1e8fe", "source_compute": "compute1", "source_node": "node1", "status": "running", "memory_total_bytes": 123456, "memory_processed_bytes": 12345, "memory_remaining_bytes": 111111, "disk_total_bytes": 234567, "disk_processed_bytes": 23456, "disk_remaining_bytes": 211111, "updated_at": "2016-01-29T13:42:02.000000", "uuid": "12341d4b-346a-40d0-83c6-5f4f6892b650", "user_id": "ef9d34b4-45d0-4530-871b-3fb535988394", "project_id": "011ee9f4-8f16-4c38-8633-a254d420fd54" } }
The key will always be returned but the value could be null for older records.
The GET /os-migrations
API will also have optional user_id
and
project_id
query parameters for filtering migrations by user and/or
project:
GET /os-migrations?user_id=ef9d34b4-45d0-4530-871b-3fb535988394
GET /os-migrations?project_id=011ee9f4-8f16-4c38-8633-a254d420fd54
GET /os-migrations?user_id=ef9d34b4-45d0-4530-871b-3fb535988394&project_id=011ee9f4-8f16-4c38-8633-a254d420fd54
Security impact¶
None
Notifications impact¶
None. InstanceActionPayload
already contains action_initiator_user
and action_initiator_project
fields.
Other end user impact¶
Update python-novaclient for the new microversion (and python-openstackclient if it grows server migration resource CLIs in the future).
Performance Impact¶
None
Other deployer impact¶
None
Developer impact¶
None
Upgrade impact¶
None. The new columns in the database will be nullable as will the fields on the Migration object and the API response can return null values. A data migration to populate the values for existing migrations will not be added.
Implementation¶
Assignee(s)¶
- Primary assignee:
Brin Zhang
Feature Liaison¶
- Feature liaison:
mriedem
Work Items¶
Add
user_id
andproject_id
to themigrations
table and Migration versioned object.Modify the API to expose the
user_id
andproject_id
fields in GET responses that expose migration resources. Also adduser_id
andproject_id
query parameters toGET /os-migrations
for filtering the results.Add related tests
Docs for the new microversion.
Dependencies¶
None
Testing¶
Add related unit test for negative scenarios.
Add related functional test (API samples).
Tempest testing should not be necessary for this change.
Documentation Impact¶
Update the API reference for the new microversion.
References¶
None
History¶
Release Name |
Description |
---|---|
Train |
Introduced |
Ussuri |
Re-proposed |