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