I understand that searchlight wants to get as much information in the notification as possible to avoid polling the API. However the goal to have exactly the same information in the notification than in the API answer is not easily doable right now as the notifications are coming from different nova services while the API answers always come from the nova-api service.
Anyhow adding some extra bits and pieces to the notifications should not be too hard.
There is an ongoing effort to transform the nova notifications to a well defined format [1] and I think the extension of the notification shall be done on the transformed and versioned payload.
The instance.create notification transformation is currently proposed in [2]. The additional fields can be added on top of that patch.
The instance.update notification is already transformed in [3]. An example of the versioned payload is visible in [4] so additional fields can already be proposed.
* tag: seems easy to add based on the tags field of the Instance object.
* description: I guess description is the same as Instance.display_description, so it is super easy to add
* key_name: It seems it is the name of the KeyPair attached to the instance. Do searchlight only needs the name of the KeyPair which is not unique or would it be better adding the whole KeyPair object to the notification? (user_id + key_name is unique together, and the id field of the KeyPair alone is unique)
* locked: It is Instance.locked so it is super easy
* OS-DCF:diskConfig: The related data is available in Instance.auto_disk_config but that is a boolean field and not a AUTO / MANUAL enum. Does searchlight needs the exact values in the notification? Here I feel that duplicating the enum values from the api to the notification shall be avoided and the nova object model needs to be evolved in a way that the Instance.auto_disk_config is already an enum instead of a boolean field. This is of course more work.
Bottom line, I think we need some answers from searchlight team about the exact needs but I feel that the needed fields can be added to the versioned notifications.
I understand that searchlight wants to get as much information in the notification as possible to avoid polling the API. However the goal to have exactly the same information in the notification than in the API answer is not easily doable right now as the notifications are coming from different nova services while the API answers always come from the nova-api service.
Anyhow adding some extra bits and pieces to the notifications should not be too hard.
There is an ongoing effort to transform the nova notifications to a well defined format [1] and I think the extension of the notification shall be done on the transformed and versioned payload.
The instance.create notification transformation is currently proposed in [2]. The additional fields can be added on top of that patch.
The instance.update notification is already transformed in [3]. An example of the versioned payload is visible in [4] so additional fields can already be proposed.
* tag: seems easy to add based on the tags field of the Instance object. display_ description, so it is super easy to add auto_disk_ config but that is a boolean field and not a AUTO / MANUAL enum. Does searchlight needs the exact values in the notification? Here I feel that duplicating the enum values from the api to the notification shall be avoided and the nova object model needs to be evolved in a way that the Instance. auto_disk_ config is already an enum instead of a boolean field. This is of course more work.
* description: I guess description is the same as Instance.
* key_name: It seems it is the name of the KeyPair attached to the instance. Do searchlight only needs the name of the KeyPair which is not unique or would it be better adding the whole KeyPair object to the notification? (user_id + key_name is unique together, and the id field of the KeyPair alone is unique)
* locked: It is Instance.locked so it is super easy
* OS-DCF:diskConfig: The related data is available in Instance.
Bottom line, I think we need some answers from searchlight team about the exact needs but I feel that the needed fields can be added to the versioned notifications.
[1] https:/ /blueprints. launchpad. net/nova/ +spec/versioned -notification- transformation- ocata /review. openstack. org/#/c/ 384621/ /review. openstack. org/#/c/ 325923/ /review. openstack. org/#/c/ 325923/ 31/doc/ notification_ samples/ instance- update. json,unified /github. com/openstack/ nova/blob/ master/ nova/api/ openstack/ compute/ helpers. py#L32- L39
[2] https:/
[3] https:/
[4] https:/
[5] https:/