Open Stack

Hmmm... with this thread in mind, anyone think that changing DISCOVERING to
INTROSPECTING in the new state machine spec is a good idea?

On Mon, Nov 3, 2014 at 4:29 AM, Ganapathy, Sandhya <sandhya.ganapathy at hp.com
> wrote:

> Hi all,
>
> Following the mail thread on disambiguating the term 'discovery' -
>
> In the lines of what Devananda had stated, Hardware Introspection also
> means retrieving and storing hardware details of the node whose credentials
> and IP Address are known to the system. (Correct me if I am wrong).
>
> I am currently in the process of extracting hardware details (cpu, memory
> etc..) of n no. of nodes belonging to a Chassis whose credentials are
> already known to ironic. Does this process fall in the category of hardware
> introspection?
>
> Thanks,
> Sandhya.
>
> -----Original Message-----
> From: Devananda van der Veen [mailto:devananda.vdv at gmail.com]
> Sent: Tuesday, October 21, 2014 5:41 AM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Ironic] disambiguating the term "discovery"
>
> Hi all,
>
> I was reminded in the Ironic meeting today that the words "hardware
> discovery" are overloaded and used in different ways by different people.
> Since this is something we are going to talk about at the summit (again),
> I'd like to start the discussion by building consensus in the language that
> we're going to use.
>
> So, I'm starting this thread to explain how I use those two words, and
> some other words that I use to mean something else which is what some
> people mean when they use those words. I'm not saying my words are the
> right words -- they're just the words that make sense to my brain right
> now. If someone else has better words, and those words also make sense (or
> make more sense) then I'm happy to use those instead.
>
> So, here are rough definitions for the terms I've been using for the last
> six months to disambiguate this:
>
> "hardware discovery"
> The process or act of identifying hitherto unknown hardware, which is
> addressable by the management system, in order to later make it available
> for provisioning and management.
>
> "hardware introspection"
> The process or act of gathering information about the properties or
> capabilities of hardware already known by the management system.
>
>
> Why is this disambiguation important? At the last midcycle, we agreed that
> "hardware discovery" is out of scope for Ironic -- finding new, unmanaged
> nodes and enrolling them with Ironic is best left to other services or
> processes, at least for the forseeable future.
>
> However, "introspection" is definitely within scope for Ironic. Even
> though we couldn't agree on the details during Juno, we are going to
> revisit this at the Kilo summit. This is an important feature for many of
> our current users, and multiple proof of concept implementations of this
> have been done by different parties over the last year.
>
> It may be entirely possible that no one else in our developer community is
> using the term "introspection" in the way that I've defined it above -- if
> so, that's fine, I can stop calling that "introspection", but I don't know
> a better word for the thing that is find-unknown-hardware.
>
> Suggestions welcome,
> Devananda
>
>
> P.S.
>
> For what it's worth, googling for "hardware discovery" yields several
> results related to identifying unknown network-connected devices and adding
> them to inventory systems, which is the way that I'm using the term right
> now, so I don't feel completely off in continuing to say "discovery" when I
> mean "find unknown network devices and add them to Ironic".
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141112/89fed04c/attachment.html>