After some IRC discussion (http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2016-09-27.log.html#t2016-09-27T13:31:42), I'm +1 to this base payload, too.
I vote we do this, and we can always update later if operators chime in with additional use cases that should be put in every node notification. It would be best to keep this simple for now rather than adding more complexity to something that many notifications will be using. Thanks for the email, Yuriy. Mario On Tue, Sep 27, 2016 at 7:00 AM, Yuriy Zveryanskyy <yzveryans...@mirantis.com> wrote: > 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 > __________________________________________________________________________ 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
