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