Re: [openstack-dev] [ironic] base node payload for notification

2016-09-29 Thread Tripp, Travis S
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

Re: [openstack-dev] [ironic] base node payload for notification

2016-09-27 Thread Jim Rollenhagen
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

Re: [openstack-dev] [ironic] base node payload for notification

2016-09-27 Thread Loo, Ruby
g> 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 alphabetica

Re: [openstack-dev] [ironic] base node payload for notification

2016-09-27 Thread Mario Villaplana
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

[openstack-dev] [ironic] base node payload for notification

2016-09-27 Thread Yuriy Zveryanskyy
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",