On Thu, 2014-01-16 at 11:25 +0100, Jaromir Coufal wrote: > On 2014/12/01 20:40, Jay Pipes wrote: > > On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote: > >>>> So, it's not as simple as it may initially seem :) > >>> > >>> Ah, I should have been clearer in my statement - my understanding is that > >>> we're scrapping concepts like Rack entirely. > >> > >> That was my understanding as well. The existing Tuskar domain model was > >> largely placeholder/proof of concept and didn't necessarily reflect > >> exactly what was desired/expected. > > > > Hmm, so this is a bit disappointing, though I may be less disappointed > > if I knew that Ironic (or something else?) planned to account for > > datacenter inventory in a more robust way than is currently modeled. > > > > If Triple-O/Ironic/Tuskar are indeed meant to be the deployment tooling > > that an enterprise would use to deploy bare-metal hardware in a > > continuous fashion, then the modeling of racks, and the attributes of > > those racks -- location, power supply, etc -- are a critical part of the > > overall picture. > > > > As an example of why something like power supply is important... inside > > AT&T, we had both 8kW and 16kW power supplies in our datacenters. For a > > 42U or 44U rack, deployments would be limited to a certain number of > > compute nodes, based on that power supply. > > > > The average power draw for a particular vendor model of compute worker > > would be used in determining the level of compute node packing that > > could occur for that rack type within a particular datacenter. This was > > a fundamental part of datacenter deployment and planning. If the tooling > > intended to do bare-metal deployment of OpenStack in a continual manner > > does not plan to account for these kinds of things, then the chances > > that tooling will be used in enterprise deployments is diminished. > > > > And, as we all know, when something isn't used, it withers. That's the > > last thing I want to happen here. I want all of this to be the > > bare-metal deployment tooling that is used *by default* in enterprise > > OpenStack deployments, because the tooling "fits" the expectations of > > datacenter deployers. > > > > It doesn't have to be done tomorrow :) It just needs to be on the map > > somewhere. I'm not sure if Ironic is the place to put this kind of > > modeling -- I thought Tuskar was going to be that thing. But really, > > IMO, it should be on the roadmap somewhere. > > > > All the best, > > -jay > > Perfect write up, Jay. > > I can second these needs based on talks I had previously. > > The goal is to primarily support enterprise deployments and they work > with racks, so all of that information such as location, power supply, > etc are important. > > Though this is pretty challenging area and we need to start somewhere. > As a proof of concept, Tuskar tried to provide similar views, then we > jumped into reality. OpenStack has no strong support in racks field for > the moment. As long as we want to deliver working deployment solution > ASAP and enhance it in time, we started with currently available features. > > We are not giving up racks entirely, they are just a bit pushed back, > since there is no real support in OpenStack yet. But to deliver more > optimistic news, regarding last OpenStack summit, Ironic intends to work > with all the racks information (location, power supply, ...). So once > Ironic contains all of that information, we can happily start providing > such capability for deployment setups, hardware overviews, etc. > > Having said that, for Icehouse I pushed for Node Tags to get in. It is > not the best experience, but using Node Tags, we can actually support > various use-cases for user (by him tagging nodes manually at the moment).
Totally cool, Jarda. I appreciate your response and completely understand the prioritization. Best, -jay _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
