Extending versioned notifications for searchlight integration
The Searchlight project reported multiple bugs [1],[2],[3] on nova about
missing data in nova's notifications. Searchlight treats nova notifications
as a complete record of the state of nova entities especially servers.
However the current nova notifications missing some of the fields
therefor Searchlight today needs to query the Nova API to get the full
picture. The current API polling solution does not scale well in Searchlight
therefore we are proposing the following additions to the nova versioned
notifications.
Let's try the following steps
Step1: Add simple fields to instance.create and instance.update
* The list of Tag objects based on instance.tags
* The list of KeyPair objects containing at least the
name field of the original KeyPair objects based on instance.keypairs
* The instance's display_description field
* The instance's locked field
* The instance's auto_disk_config field
This technically means that the InstancePayload needs to be extended with new
fields. This will automatically makes both the instance.create and
instance.update (and all the instance.<action>) content extended.
Step2 Add BDM related data to instance.create and instance.update
The following fields from the BlockDeviceMapping object where
the instance_uuid of the BDM matches the instance's uuid the notification
is sent about:
* volume_id
* delete_
Only include a BDM into the notification payload if the volume_id of the BDM
is not None. This is needed to keep the notification content consistent
with the nova API response.
To be able to initialize the BDM part of the notifications the BDM needs
to be available in the context of the notification sending. In case of
instance.create it is already available but in case of instance.update this
needs to be queried. So to avoid unnecessary performance impact make sending
the BDM data configurable. Default the new config parameter to False as
far as including BDMs in notifications in the cases that we need to query
them from the database.
[1] https:/
[2] https:/
[3] https:/
Blueprint information
- Status:
- Complete
- Approver:
- Matt Riedemann
- Priority:
- High
- Drafter:
- Balazs Gibizer
- Direction:
- Approved
- Assignee:
- Balazs Gibizer
- Definition:
- Approved
- Series goal:
- Accepted for pike
- Implementation:
-
Implemented
- Milestone target:
-
pike-3
- Started by
- Matt Riedemann
- Completed by
- Matt Riedemann
Related branches
Related bugs
Sprints
Whiteboard
(mriedem): I have a couple of concerns with the BDM part of this. Today the REST API shows attached volumes when showing details on a given server, but only if the volume_id is set (which it should be for an attached volume after it's attached, but might not be during boot from volume where nova is creating the volume and it's not yet attached but you're polling the server for status):
You can create a server using boot from volume with an image_id or a volume snapshot_id in which case the volume_id on the incoming block_device_
The other thing is when showing volume attachments for a given server, we only show volume id, server id and mountpoint (device_name) in the response:
We've been talking about removing device_name from the server create request as we can't honor it in most cases anyway (the libvirt driver ignores it), and unless nova creates the volume the volume_size is optional when creating a server, so I'm not sure why those are necessary in the notification.
Finally, for the case where we need to send instance.update notifications, if we don't have the BlockDeviceMapp
--
My recommendation would be to start working on the non-BDM parts of this blueprint and then we can hash out the BDM parts when we get there but save that for the end of the series.
--
(gibi): I agree with mriedem's comments so I update the BP text accordingly
--
(mriedem): 2016-11-28: I see that the additional instance fields are coming from bug [1] but I'm wondering about some other fields returned when getting server details with microversion >= 2.3:
http://
For example, launch_index, root_device_name and userdata. Those were added for the ec2 API split out of nova, but I'm wondering if we want those in the notifications also for parity with the REST API. If Searchlight doesn't need those right now, then I'm fine with just making incremental changes to the instance notification payload as needed so we don't over-complicate this.
Overall I'm OK with this as a starting point though so I'm approving it for Ocata.
Gerrit topic: https:/
Addressed by: https:/
Add instance's locked field in InstancePayload
Gerrit topic: https:/
Addressed by: https:/
Adding tags to InstancePayload
Addressed by: https:/
Add key_name field to InstancePayload
Addressed by: https:/
Change tags to default field in Instance object.
Gerrit topic: https:/
Gerrit topic: https:/
Addressed by: https:/
Adding auto_disk_config field to InstancePayload
Addressed by: https:/
Add keypairs field to InstancePayload
We're now past the feature freeze for Ocata so I've deferred this to Pike. -- mriedem 20170128
Addressed by: https:/
This patch is followup for https:/
Bumping this to high priority since this is needed for nova integrating with Searchlight for listing instances across multiple cells. -- mriedem 20170222
ML thread aboutt the BDM modelling: http://
Addressed by: https:/
[WIP] Add BDM to InstancePayload
Gerrit topic: https:/
Addressed by: https:/
Using max api version in notification sample test
Addressed by: https:/
Add tags to instance.create Notification
Addressed by: https:/
Add separate instance.create payload type
Addressed by: https:/
Add key_name field to InstancePayload
Addressed by: https:/
use already loaded BDM in instance.<action>
Gerrit topic: https:/
Addressed by: https:/
use already loaded BDM in instance.<action> (2)
Addressed by: https:/
use already loaded BDM in instance.create
Now that server tags are included in the instance.create notifications, I'm going to mark this complete for Pike. -- mriedem 20170724
Work Items
Dependency tree
* Blueprints in grey have been implemented.
