Open Stack

On Wed, Mar 15, 2017 at 1:44 PM, John Garbutt <john at johngarbutt.com> 
wrote:
> On 13 March 2017 at 17:14, Balazs Gibizer 
> <balazs.gibizer at ericsson.com> 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: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev