Re: [openstack-dev] [nova] [notification] BlockDeviceMapping in InstancePayload

[Balazs Gibizer]

On Wed, Mar 15, 2017 at 1:44 PM, John Garbutt  
wrote:
On 13 March 2017 at 17:14, Balazs Gibizer 
 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-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [notification] BlockDeviceMapping in InstancePayload

[John Garbutt]

On 13 March 2017 at 17:14, Balazs Gibizer  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)
}

Thanks,
John

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [notification] BlockDeviceMapping in InstancePayload

[Balazs Gibizer]

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.


What do you think, which direction we should go?

Cheers,
gibi


[1] 
https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev