This patch add share information to the InstancePayload that can be sent
if the include_share_mapping configuration parameter is enabled.
Manila is the OpenStack Shared Filesystems service.
These series of patches implement changes required in Nova to allow the shares
provided by Manila to be associated with and attached to instances using
virtiofs.
Implements: blueprint libvirt-virtiofs-attach-manila-shares
Change-Id: I3d5005eab9e3f23be149e955e8cb4608a6ee1312
Finish up removing these entries from the versioned instance
notifications. They're useless since we dropped support for the XenAPI
virt driver. The underlying model is retained for now: that will be
handled separately.
Change-Id: I774c50fca99bc655ca5010e3b9d8247b739293b3
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This one is a little more involved because there are persistent objects
and versioned notifications to worry about, neither of which we can
remove right now.
Change-Id: Ic7c330ee1cccdc44a2a555c16cb6090eecbf6ce1
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This patch adds a new parameter ``locked_reason`` to
``POST /servers/{server_id}/action`` request where the
action is lock. It enables the user to specify a reason when locking
a server.
The locked_reason will be exposed through ``GET servers/{server_id}``,
``GET /servers/detail``, ``POST /servers/{server_id}/action`` where
the action is rebuild and ``PUT servers/{server_id}`` requests' responses.
The InstanceActionNotification will emit the locked_reason
along with the other instance details. This patch hence changes the
payload object to include the "locked_reason" field.
Note that "locked" will be allowed as a valid filtering/sorting parameter
for ``GET /servers/detail`` and ``GET /servers`` from this new microversion.
Implements blueprint add-locked-reason
Change-Id: I46edd595e7417c584106487123774a73c6dbe65e
The instance action notifications contain the user id and the
project id of the owner of the instance. However an instance
action might be initiated by another user. It could be another
user from the same project or can be an admin from the admin project.
To be able to distinguish between the user who initiated the instance
action from the user owning the instance we need to add two new
fields to the instance action notifications, action_initiator_user
and action_initiator_project
Change-Id: I649d8a27baa8840bc1bb567fef027c749c663432
Closes-bug: #1744658
Blueprint: add-action-initiator-to-instance-action-notifications
This patch contains the instance.exists related notification
transformation. The functional test for instance_usage_audit
periodic task case is added in a subsequent patch.
Change-Id: I1a0afa0e8740c229db77c18b932e316196880de5
Implements: bp versioned-notification-transformation-rocky
René Ribaud