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 <yzveryans...@mirantis.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Tuesday, September 27, 2016 at 7:00 AM To: "openstack-dev@lists.openstack.org" <openstack-dev@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
__________________________________________________________________________ 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
