Excerpts from Steven Hardy's message of 2014-09-15 04:44:24 -0700: > All, > > Starting this thread as a follow-up to a strongly negative reaction by the > Ironic PTL to my patches[1] adding initial Heat->Ironic integration, and > subsequent very detailed justification and discussion of why they may be > useful in this spec[2]. > > Back in Atlanta, I had some discussions with folks interesting in making > "ready state"[3] preparation of bare-metal resources possible when > deploying bare-metal nodes via TripleO/Heat/Ironic. > > The initial assumption is that there is some discovery step (either > automatic or static generation of a manifest of nodes), that can be input > to either Ironic or Heat. > > Following discovery, but before an undercloud deploying OpenStack onto the > nodes, there are a few steps which may be desired, to get the hardware into > a state where it's ready and fully optimized for the subsequent deployment: > > - Updating and aligning firmware to meet requirements of qualification or > site policy > - Optimization of BIOS configuration to match workloads the node is > expected to run > - Management of machine-local storage, e.g configuring local RAID for > optimal resilience or performance. > > Interfaces to Ironic are landing (or have landed)[4][5][6] which make many > of these steps possible, but there's no easy way to either encapsulate the > (currently mostly vendor specific) data associated with each step, or to > coordinate sequencing of the steps. >
First, Ironic is hidden under Nova as far as TripleO is concerned. So mucking with the servers underneath Nova during deployment is a difficult proposition. Would I look up the Ironic node ID of the nova server, and then optimize it for the workload after the workload arrived? Why wouldn't I just do that optimization before the deployment? > What is required is some tool to take a text definition of the required > configuration, turn it into a correctly sequenced series of API calls to > Ironic, expose any data associated with those API calls, and declare > success or failure on completion. This is what Heat does. > I'd rather see Ironic define or adopt a narrow scope document format that it can consume for bulk loading. Heat is extremely generic, and thus carries a ton of complexity for what is probably doable with a CSV file. > So the idea is to create some basic (contrib, disabled by default) Ironic > heat resources, then explore the idea of orchestrating ready-state > configuration via Heat. > > Given that Devananda and I have been banging heads over this for some time > now, I'd like to get broader feedback of the idea, my interpretation of > "ready state" applied to the tripleo undercloud, and any alternative > implementation ideas. > I think there may be value in being able to tie Ironic calls to other OpenStack API calls. I'm dubious that this is an important idea, but I think if somebody wants to step forward with their use case for it, then the resources might make sense. However, I realy don't see the _enrollment_ phase as capturing any value that isn't entirely offset by added complexity. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
