Re: [openstack-dev] [ironic] base node payload for notification
On 9/27/16, 8:23 AM, "Jim Rollenhagen" wrote: On Tue, Sep 27, 2016 at 9:57 AM, Loo, Ruby wrote: > 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. On 9/27/16, 8:23 AM, "Jim Rollenhagen" wrote: > 2) Searching things with searchlight - the obvious case for driver_info is "find > all nodes with BMCs on the 10.100.0.0/24 network" or similar things. We’ve done some usability studies on searchlight UI and one of the most useful use cases that has emerged is the ability to search based on IP addresses / ranges / cidr (all supported by the underlying elastic search engine). In most searchlight plugins (e.g. glance / nova), we’ve indexed any data visible via the API. For sensitive fields, you can set them to be admin only (or use other filtering abilities in the plugin). In addition, if you guys have any interest in doing some aggregation like abilities in addition to search, you can do that using the searchlight indexing. For example, counts, averages, various statistics can be done via the aggregation API exposed up via searchlight [0] of the ElasticSearch aggregation API [1]. For example, one simple use case we’ve used it for is to get a count of images & flavors used across nova instances or hosts. [0] http://developer.openstack.org/api-ref/search/?expanded=create-an-aggregated-search-detail [1] https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations.html __ 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
Re: [openstack-dev] [ironic] base node payload for notification
On Tue, Sep 27, 2016 at 9:57 AM, Loo, Ruby wrote: > 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. I'm also on the fence. There's a couple use cases that I think could use this: 1) Building a thing that takes action on notifications - for example, on a deploy failure, analyze the error and do a thing (e.g. if BMC is unresponsive, perform a cold reset). However, this tool could have access to read this data to work around this. 2) Searching things with searchlight - the obvious case for driver_info is "find all nodes with BMCs on the 10.100.0.0/24 network" or similar things. Now that I write these out, seems like driver_info would be more useful than instance_info, because the latter is more ephemeral. It is easier to add a thing to notifications than to remove it (deprecation periods and so on). So I lean toward not including them now, and adding them if we find the need. // jim __ 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
Re: [openstack-dev] [ironic] base node payload for notification
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 Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Tuesday, September 27, 2016 at 7:00 AM To: "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
Re: [openstack-dev] [ironic] base node payload for notification
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 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
[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
