Open Stack

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