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

Jim Rollenhagen jim at jimrollenhagen.com
Tue Sep 27 14:23:23 UTC 2016


On Tue, Sep 27, 2016 at 9:57 AM, Loo, Ruby <ruby.loo at intel.com> 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



More information about the OpenStack-dev mailing list