[openstack-dev] [TripleO][Tuskar] Domain Model Locations

Jaromir Coufal jcoufal at redhat.com
Thu Jan 16 10:25:23 UTC 2014

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).

-- Jarda

More information about the OpenStack-dev mailing list