Open Stack

> 1. Not everyone will have an enterprise CMDB, so there should be some way
> to input inventory without one (even if it is a text file fed into
> ironicclient). The bulk-loading format to do this is TBD.
>
> 2. A way to generate that inventory in an automated way is desirable for
> some folks, but looks likely to be out-of-scope for Ironic.  Folks are -1
> on using heat to drive this process, so we'll probably end up with some
> scary shell scripts instead, or maybe a mistral workflow in future.

FWIW, I'm not against having an automatic way to discovery the
hardware properties in Ironic.

Lemme try to be clear, if Ironic needs to know the size of disk,
amount of memory, no of CPUs and CPU arch to be able to deploy a
machine, and BMCs like Drac, iLO, MM, etc... provides an OOB endpoint
which Ironic can use to get such informations, so I don't see why we
should not consume that from in Ironic. Note that I don't agree that
Ironic should store *all* informations about the hardware, but the
informations it's going to use to be able to *deploy* that machine.

So the reasons I think we should do that is:

1) First because Ironic is an abstraction layer for the hardware, so
if it's a feature that the hardware provides I don't see why not
abstracting and creating an API for it. We already have the
vendor_passthru endpoint where things like that can be used by the
vendor to expose their new shiny hardware capabiltities, and if other
drivers start implementing the same thing in their vendor_passthru we
can go then and promote that feature to a common API. So we already
even have a strategy for that.


2) To be less error prone, this is about quality. Why would I rely on
a human to input all this information to Ironic if I can go there and
interrogate the hardware directly and be sure that this is the real
amount of resources I have there. @Jim even said in this thread that
dealing with the incorrect data from vendor, DC team, etc is the hard
part of registering this things. So I don't wanna rely on them, if I
have a mean to talk to the hardware directly and get this informations
why not do it?

>
> 3. Vendor-specific optimization of nodes for particular roles will be
> handled via Ironic drivers, which expose capabilities which can be selected
> via nova flavors. (is there a BP for this?)
>
> 4. Stuff like RAID configuration will be handled via in-band config
> management tools, nobody has offered any solution for using management
> interfaces to do this, and drac-raid-mgmt is unlikely to land in Ironic
> (where would such an interface be appropriate then?)

IMO, this falls in the same argument I have about Ironic is an
abstraction layer for hardware, if the BMC supports it and configuring
RAID is something that makes sense to do prior to deploying a node, I
don't see why we should not abstract it. Again, we have a strategy for
that, let vendors expose it first in their vendor_passthru interface,
and if more see it as a nice feature to have and implement in their
vendor_passthru as well we can go and promote it to a common API
interface

>
> 5. Nobody has offered any solution for management and convergence of BIOS
> and firmware levels (would this be part of the Ironic driver mentioned in
> (3), or are we punting the entire problem to in-band provision-time tooling?)
>
> If anyone can help by providing existing BP's related to the above (which I
> can follow and/or contribute to) that would be great - I'm happy to drop
> the whole Heat resource thing, but only if there's a clear path to solving
> the problems in some other/better way.
>
> Thanks,
>
> Steve
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev