On Wed, Mar 15, 2017 at 1:44 PM, John Garbutt <[email protected]>
wrote:
On 13 March 2017 at 17:14, Balazs Gibizer
<[email protected]> wrote:
Hi,
As part of the Searchlight integration we need to extend our
instance
notifications with BDM data [1]. As far as I understand the main
goal is to
provide enough data about the instance to Searchlight so that Nova
can use
Searchlight to generate the response of the GET /servers/{server_id}
requests based on the data stored in Searchlight.
I checked the server API response and I found one field that needs
BDM
related data: os-extended-volumes:volumes_attached. Only the uuid
of the
volume and the value of delete_on_terminate is provided in the API
response.
I have two options about what to add to the InstancePayload and I
want to
get some opinions about which direction we should go with the
implementation.
Option A: Add only the minimum required information from the BDM to
the
InstancePayload
additional InstancePayload field:
block_devices: ListOfObjectsField(BlockDevicePayload)
class BlockDevicePayload(base.NotificationPayloadBase):
fields = {
'delete_on_termination': fields.BooleanField(default=False),
'volume_id': fields.StringField(nullable=True),
}
This payload would be generated from the BDMs connected to the
instance
where the BDM.destination_type == 'volume'.
Option B: Provide a comprehensive set of BDM attributes
class BlockDevicePayload(base.NotificationPayloadBase):
fields = {
'source_type':
fields.BlockDeviceSourceTypeField(nullable=True),
'destination_type': fields.BlockDeviceDestinationTypeField(
nullable=True),
'guest_format': fields.StringField(nullable=True),
'device_type': fields.BlockDeviceTypeField(nullable=True),
'disk_bus': fields.StringField(nullable=True),
'boot_index': fields.IntegerField(nullable=True),
'device_name': fields.StringField(nullable=True),
'delete_on_termination': fields.BooleanField(default=False),
'snapshot_id': fields.StringField(nullable=True),
'volume_id': fields.StringField(nullable=True),
'volume_size': fields.IntegerField(nullable=True),
'image_id': fields.StringField(nullable=True),
'no_device': fields.BooleanField(default=False),
'tag': fields.StringField(nullable=True)
}
In this case Nova would provide every BDM attached to the instance
not just
the volume ones.
I intentionally left out connection_info and the db id as those
seems really
system internal.
I also left out the instance related references as this
BlockDevicePayload
would be part of an InstancePayload which has an the instance uuid
already.
+1 leaving those out.
What do you think, which direction we should go?
There are discussions around extending the info we give out about BDMs
in the API.
What about in between, list all types of BDMs, so include a touch more
info so you can tell which one is a volume for sure.
class BlockDevicePayload(base.NotificationPayloadBase):
fields = {
'destination_type': fields.BlockDeviceDestinationTypeField(
nullable=True), # Maybe just called
"type"?
'boot_index': fields.IntegerField(nullable=True),
'device_name': fields.StringField(nullable=True), # do we
ignore that now?
'delete_on_termination': fields.BooleanField(default=False),
'volume_id': fields.StringField(nullable=True),
'tag': fields.StringField(nullable=True)
}
This payload is OK for me.
I agree to use 'type' instead of 'destination_type' as destination
doesn't have too much meaning after the device is attached.
The libvirt driver ignores the device_name but I'm not sure about the
other virt drivers.
Cheers,
gibi
Thanks,
John
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
