> 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 > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev