Open Stack

Hi Yuriy,

Thanks for bringing this up. I'm good with your list, with the exception of driver_info and instance_info. I'm on the fence with these two. If we assume that any secrets will be bleep'd out (configdrives won't be there), is there other information there that might be useful? I'm not totally sure what notifications will be used for; it is somewhat hard to assume.

I suppose we could look at it this way, since you and Mario are fine without those two. If no one speaks up wanting them, then we'll do as you propose, and not expose those two fields.

--ruby


From: Yuriy Zveryanskyy <yzveryanskyy at mirantis.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Tuesday, September 27, 2016 at 7:00 AM
To: "openstack-dev at lists.openstack.org" <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [ironic] base node payload for notification

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/a7d4d850/attachment.html>