Just for reference, the spec is this one: https://review.openstack.org/#/c/133828/
That's a good point, I think it's important to have this distinction of a new node being discovered and a registered node being introspected/interrogated. So I'm +1 for the idea. On Wed, Nov 12, 2014 at 9:47 PM, Victor Lowther <[email protected]> wrote: > 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 > <[email protected]> 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:[email protected]] >> 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 >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
