[openstack-dev] [ironic] base node payload for notification

Yuriy Zveryanskyy yzveryanskyy at mirantis.com
Tue Sep 27 11:00:07 UTC 2016


Hi,
there is a discussion starting in comment on
https://review.openstack.org/#/c/321865/
I agree with Ruby Loo proposal about a base node payload.

Currently we have these node's fields exposed via API (in alphabetical
order):

"chassis_uuid", "clean_step", "console_enabled", "created_at",  "driver",
"driver_info", "driver_internal_info", "extra", "inspection_finished_at",
"inspection_started_at", "instance_info", "instance_uuid", "last_error",
"maintenance", "maintenance_reason", "name", "network_interface",
"power_state", "properties", "provision_state", "provision_updated_at",
"raid_config", "reservation", "resource_class", "target_power_state",
"target_provision_state", "target_raid_config", "updated_at", "uuid"

In my opinion these field should be excluded from base node payload:

"chassis_uuid": it not represents node state, not changed too often,
additional
DB SELECT will be needed for base payload
"driver_info": it not represents node state, contains only driver settings
and
secrets like IPMI passwords
"driver_internal_info": it's driver internal info
"instance_info": configdrive blob can be saved inside
"raid_config": it's hardware related
"reservation": it's not independent changed fields, only lock flag
"target_raid_config": it's hardware related

And resulting base payload fields list (for version 1.0):

"clean_step", "console_enabled", "created_at",  "driver", "extra",
"inspection_finished_at", "inspection_started_at", "instance_uuid",
"last_error", "maintenance", "maintenance_reason", "name",
"network_interface", "power_state", "properties", "provision_state",
"provision_updated_at", "resource_class", "target_power_state",
"target_provision_state", "updated_at", "uuid"

Any other suggestions are welcome.

Yuriy Zveryanskyy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160927/48e6acf4/attachment.html>


More information about the OpenStack-dev mailing list