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
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
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,
t
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 pu
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", "drive