Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-11-13 Thread Dmitry Tantsur

On 11/12/2014 10:47 PM, Victor Lowther wrote:

Hmmm... with this thread in mind, anyone think that changing DISCOVERING
to INTROSPECTING in the new state machine spec is a good idea?
As before I'm uncertain. Discovery is a troublesome term, but too many 
people use and recognize it, while IMO introspecting is much less 
common. So count me as -0 on this.




On Mon, Nov 3, 2014 at 4:29 AM, Ganapathy, Sandhya
sandhya.ganapa...@hp.com mailto:sandhya.ganapa...@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@gmail.com
mailto:devananda@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@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-11-13 Thread Ganapathy, Sandhya
Hi All,

Based on the discussions, I have filed a blue print that initiates discovery of 
node hardware details given its credentials at chassis level. I am in the 
process of creating a spec for it. Do share your thoughts regarding this - 

https://blueprints.launchpad.net/ironic/+spec/chassis-level-node-discovery

Thanks,
Sandhya.

-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com] 
Sent: Thursday, November 13, 2014 2:20 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] disambiguating the term discovery

On 11/12/2014 10:47 PM, Victor Lowther wrote:
 Hmmm... with this thread in mind, anyone think that changing 
 DISCOVERING to INTROSPECTING in the new state machine spec is a good idea?
As before I'm uncertain. Discovery is a troublesome term, but too many people 
use and recognize it, while IMO introspecting is much less common. So count me 
as -0 on this.


 On Mon, Nov 3, 2014 at 4:29 AM, Ganapathy, Sandhya
 sandhya.ganapa...@hp.com mailto:sandhya.ganapa...@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@gmail.com
 mailto:devananda@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@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack

Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-11-13 Thread Lucas Alvares Gomes
Hi

On Thu, Nov 13, 2014 at 11:27 AM, Ganapathy, Sandhya
sandhya.ganapa...@hp.com wrote:
 Hi All,

 Based on the discussions, I have filed a blue print that initiates discovery 
 of node hardware details given its credentials at chassis level. I am in the 
 process of creating a spec for it. Do share your thoughts regarding this -

 https://blueprints.launchpad.net/ironic/+spec/chassis-level-node-discovery

Thanks Sandhya for the spec. But I prefer if people DO NOT share their
thoughts in this thread, it's out of topic. What we are trying to sort
out here is whether we should use the term discover for the approach
of finding out the physical characteristics of an already registered
Node in Ironic, or we should call it something else like
introspection or interrogation and leave the discover term only
for the approach of discovering nodes that are not registered in
Ironic yet.

Implementations details like your blueprint is suggesting whether make
it at Chassis level or Node level or both should go in another thread.


 Thanks,
 Sandhya.

 -Original Message-
 From: Dmitry Tantsur [mailto:dtant...@redhat.com]
 Sent: Thursday, November 13, 2014 2:20 PM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Ironic] disambiguating the term discovery

 On 11/12/2014 10:47 PM, Victor Lowther wrote:
 Hmmm... with this thread in mind, anyone think that changing
 DISCOVERING to INTROSPECTING in the new state machine spec is a good idea?
 As before I'm uncertain. Discovery is a troublesome term, but too many people 
 use and recognize it, while IMO introspecting is much less common. So count 
 me as -0 on this.


 On Mon, Nov 3, 2014 at 4:29 AM, Ganapathy, Sandhya
 sandhya.ganapa...@hp.com mailto:sandhya.ganapa...@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@gmail.com
 mailto:devananda@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

Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-11-13 Thread Dmitry Tantsur

On 11/13/2014 12:27 PM, Ganapathy, Sandhya wrote:

Hi All,

Based on the discussions, I have filed a blue print that initiates discovery of 
node hardware details given its credentials at chassis level. I am in the 
process of creating a spec for it. Do share your thoughts regarding this -

https://blueprints.launchpad.net/ironic/+spec/chassis-level-node-discovery
Hi and thank you for the suggestion. As already said, this thread is not 
the best place to discuss it, so please file a (short version of) spec, 
so that we can comment on it.


Thanks,
Sandhya.

-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com]
Sent: Thursday, November 13, 2014 2:20 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] disambiguating the term discovery

On 11/12/2014 10:47 PM, Victor Lowther wrote:

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

As before I'm uncertain. Discovery is a troublesome term, but too many people 
use and recognize it, while IMO introspecting is much less common. So count me 
as -0 on this.



On Mon, Nov 3, 2014 at 4:29 AM, Ganapathy, Sandhya
sandhya.ganapa...@hp.com mailto:sandhya.ganapa...@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@gmail.com
 mailto:devananda@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

Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-11-12 Thread Victor Lowther
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.ganapa...@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@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-11-12 Thread Lucas Alvares Gomes
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
victor.lowt...@gmail.com 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
 sandhya.ganapa...@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@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-11-03 Thread Ganapathy, Sandhya
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@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-10-22 Thread Lucas Alvares Gomes
On Tue, Oct 21, 2014 at 6:29 PM, Stuart Fox stu...@demonware.net wrote:
 Having written/worked on a few DC automation tools, Ive typically broken
 down the process of getting unknown hardware into production in to 4
 distinct stages.
 1) Discovery (The discovery of unknown hardware)
 2) Normalising (Push initial configs like drac/imm/ilo settings, flashing to
 known good firmware etc etc)
 3) Analysis (Figure out what the hardware is and what its constituent parts
 are cpu/ram/disk/IO caps/serial numbers etc)
 4) Burnin (run linpack or equiv tests for 24hrs)

 At the end of stage 4 the hardware should be ready for provisioning.

Oh, thanks for that, I quite like this separation.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-10-21 Thread Dmitry Tantsur

On 10/21/2014 02:11 AM, Devananda van der Veen wrote:

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.
I generally agree with this separation, though it brings some troubles 
to me, as I'm used to calling discovery what you called 
introspection (it was not the case this summer, but now I changed my 
mind). And the term discovery is baked into the.. hmm.. introspection 
service that I've written [1].


So I would personally prefer to leave discovery as in discovery of 
hardware properties, though I realize that introspection may be a 
better name.


[1] https://github.com/Divius/ironic-discoverd



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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-10-21 Thread Lucas Alvares Gomes
+1 for the separation

I already gave up of the term discovery as you can see on the DRAC
Hardware Introspection[1] spec, I also don't think that
introspection is the best word for that (we already use the world
cloud for OpenStack so it can't get more confusing than that).
Perhaps interrogation would be another term for that.

[1] https://review.openstack.org/#/c/125920

Cheers,
Lucas

On Tue, Oct 21, 2014 at 8:49 AM, Dmitry Tantsur dtant...@redhat.com wrote:
 On 10/21/2014 02:11 AM, Devananda van der Veen wrote:

 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.

 I generally agree with this separation, though it brings some troubles to
 me, as I'm used to calling discovery what you called introspection (it
 was not the case this summer, but now I changed my mind). And the term
 discovery is baked into the.. hmm.. introspection service that I've
 written [1].

 So I would personally prefer to leave discovery as in discovery of
 hardware properties, though I realize that introspection may be a better
 name.

 [1] https://github.com/Divius/ironic-discoverd



 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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-10-21 Thread Sam Betts (sambetts)
I agree with Devananda's definition of Œhardware discovery¹ and other
tools similar to Ironic use the term discovery in this way, however I have
found that these other tools often bundle the gathering of the system
properties together with the discovery of the hardware as a single step
from a user perspective. I also agree that in Ironic there needs to be a
separate term for that (at least from a dev perspective) and I think
Lucas¹s suggestion of Œhardware interrogation¹ or something like Œhardware
inventory¹ would be more explanatory at first glance than Œintrospection¹.

- Sam



On 21/10/2014 09:52, Lucas Alvares Gomes lucasago...@gmail.com wrote:

+1 for the separation

I already gave up of the term discovery as you can see on the DRAC
Hardware Introspection[1] spec, I also don't think that
introspection is the best word for that (we already use the world
cloud for OpenStack so it can't get more confusing than that).
Perhaps interrogation would be another term for that.

[1] https://review.openstack.org/#/c/125920

Cheers,
Lucas

On Tue, Oct 21, 2014 at 8:49 AM, Dmitry Tantsur dtant...@redhat.com
wrote:
 On 10/21/2014 02:11 AM, Devananda van der Veen wrote:

 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.

 I generally agree with this separation, though it brings some troubles
to
 me, as I'm used to calling discovery what you called introspection
(it
 was not the case this summer, but now I changed my mind). And the term
 discovery is baked into the.. hmm.. introspection service that I've
 written [1].

 So I would personally prefer to leave discovery as in discovery of
 hardware properties, though I realize that introspection may be a
better
 name.

 [1] https://github.com/Divius/ironic-discoverd



 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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-10-21 Thread Lucas Alvares Gomes
On Tue, Oct 21, 2014 at 10:27 AM, Sam Betts (sambetts)
sambe...@cisco.com wrote:
 I agree with Devananda's definition of Œhardware discovery¹ and other
 tools similar to Ironic use the term discovery in this way, however I have
 found that these other tools often bundle the gathering of the system
 properties together with the discovery of the hardware as a single step
 from a user perspective. I also agree that in Ironic there needs to be a
 separate term for that (at least from a dev perspective) and I think
 Lucas¹s suggestion of Œhardware interrogation¹ or something like Œhardware
 inventory¹ would be more explanatory at first glance than Œintrospection¹.

Thanks for the suggestion but no inventory please, this is another
taboo word in Ironic. This is because when we say hardware inventory
it kinda suggests that Ironic could be used as a CMDB, which is not
the case.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-10-21 Thread Stuart Fox
Having written/worked on a few DC automation tools, Ive typically broken
down the process of getting unknown hardware into production in to 4
distinct stages.
1) Discovery (The discovery of unknown hardware)
2) Normalising (Push initial configs like drac/imm/ilo settings, flashing
to known good firmware etc etc)
3) Analysis (Figure out what the hardware is and what its constituent parts
are cpu/ram/disk/IO caps/serial numbers etc)
4) Burnin (run linpack or equiv tests for 24hrs)

At the end of stage 4 the hardware should be ready for provisioning.

Hope that helps

Stuart

On Tue, Oct 21, 2014 at 2:38 AM, Lucas Alvares Gomes lucasago...@gmail.com
wrote:

 On Tue, Oct 21, 2014 at 10:27 AM, Sam Betts (sambetts)
 sambe...@cisco.com wrote:
  I agree with Devananda's definition of Œhardware discovery¹ and other
  tools similar to Ironic use the term discovery in this way, however I
 have
  found that these other tools often bundle the gathering of the system
  properties together with the discovery of the hardware as a single step
  from a user perspective. I also agree that in Ironic there needs to be a
  separate term for that (at least from a dev perspective) and I think
  Lucas¹s suggestion of Œhardware interrogation¹ or something like
 Œhardware
  inventory¹ would be more explanatory at first glance than
 Œintrospection¹.

 Thanks for the suggestion but no inventory please, this is another
 taboo word in Ironic. This is because when we say hardware inventory
 it kinda suggests that Ironic could be used as a CMDB, which is not
 the case.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
BR,
Stuart
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-10-21 Thread Adam Lawson
I fully and wholeheartedly agree that inventory management is out of scope
of Ironic. But I have a small suggestion:

We'd do well as a community to adopt/evangelize an informal rule which I
enforce at work (because I see this happen a lot when brainstorming with
cross-project goals); we cannot say no (X) without suggesting an
alternative (Y)... Like a runner throwing his baton at the next guy in the
race instead of handing it to him. ; )

Back on topic however, is there an existing program where inventory data
(consumed by Ironic or any other program that needs to know the
configuration of hardwareX) could be stored? I.e. hardware catalog?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, Oct 21, 2014 at 10:29 AM, Stuart Fox stu...@demonware.net wrote:

 Having written/worked on a few DC automation tools, Ive typically broken
 down the process of getting unknown hardware into production in to 4
 distinct stages.
 1) Discovery (The discovery of unknown hardware)
 2) Normalising (Push initial configs like drac/imm/ilo settings, flashing
 to known good firmware etc etc)
 3) Analysis (Figure out what the hardware is and what its constituent
 parts are cpu/ram/disk/IO caps/serial numbers etc)
 4) Burnin (run linpack or equiv tests for 24hrs)

 At the end of stage 4 the hardware should be ready for provisioning.

 Hope that helps

 Stuart

 On Tue, Oct 21, 2014 at 2:38 AM, Lucas Alvares Gomes 
 lucasago...@gmail.com wrote:

 On Tue, Oct 21, 2014 at 10:27 AM, Sam Betts (sambetts)
 sambe...@cisco.com wrote:
  I agree with Devananda's definition of Œhardware discovery¹ and other
  tools similar to Ironic use the term discovery in this way, however I
 have
  found that these other tools often bundle the gathering of the system
  properties together with the discovery of the hardware as a single step
  from a user perspective. I also agree that in Ironic there needs to be a
  separate term for that (at least from a dev perspective) and I think
  Lucas¹s suggestion of Œhardware interrogation¹ or something like
 Œhardware
  inventory¹ would be more explanatory at first glance than
 Œintrospection¹.

 Thanks for the suggestion but no inventory please, this is another
 taboo word in Ironic. This is because when we say hardware inventory
 it kinda suggests that Ironic could be used as a CMDB, which is not
 the case.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 BR,
 Stuart

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-10-21 Thread Devananda van der Veen
On Tue, Oct 21, 2014 at 11:26 AM, Adam Lawson alaw...@aqorn.com wrote:

 I fully and wholeheartedly agree that inventory management is out of scope
 of Ironic. But I have a small suggestion:

 We'd do well as a community to adopt/evangelize an informal rule which I
 enforce at work (because I see this happen a lot when brainstorming with
 cross-project goals); we cannot say no (X) without suggesting an
 alternative (Y)... Like a runner throwing his baton at the next guy in the
 race instead of handing it to him. ; )

 Back on topic however, is there an existing program where inventory data
 (consumed by Ironic or any other program that needs to know the
 configuration of hardwareX) could be stored? I.e. hardware catalog?


Nothing within OpenStack yet does this, and I am not aware of any
stackforge projects providing an inventory database / hardware catalog /
CMDB.

That said, I have been encouraging people to look at integration between
existing (enterprise or opensource) inventory management systems and
Ironic. My discussions with enterprise CMDB vendors have so far been
positive around the current logical boundary (Ironic is a provisioning
tool, not a full CMDB).

-Devananda
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] disambiguating the term discovery

2014-10-20 Thread Monty Taylor
On 10/20/2014 07:11 PM, Devananda van der Veen wrote:
 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

I have never landed a meaningful patch to Ironic - but I +1 all of the
above. I _HAVE_ had MANY confusing discussions with product managers and
customers where someone says does it do discovery and half the room
thinks one definition and half the room thinks the other.

 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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev