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
