Open Stack

On Wed, 2012-10-10 at 08:14 -0700, Monty Taylor wrote:
> 
> On 10/08/2012 01:53 PM, David Kang wrote:
> > 
> >  Mark,
> > 
> >  I think Mark's suggestion has many advantages.
> > However, I'm not sure how realistic the assumption is in real-world "Assume that each compute node has a homogeneous set of bare-metal nodes".
> > I want to ask other people's opinion on that, especially industry people like Calxeda, NTT, ...
> > Please let us know your experiences and opinions.
> 
> Indeed. I, in fact, do not want to have to run my data center in this
> way. We've been discussing that it is entirely possible with the current
> codebase to run with only one compute node (looking at openstack bare
> metal as a management framework beneath an openstack install - so the
> spin up/tear down is pretty infrequent)
> 
> Requiring a compute node to have a homogenous set of servers would make
> this much less appealing. So for whatever my vote counts here, I vote
> very very very strongly against requiring that assumption.

It's a suggestion for how we can make progress merging the rest of the
bare-metal support work quickly without overly complicating the
scheduler/compute code for the non-bare-metal case.

The idea is be that compute would only be able to support a single slot
type now (i.e. manages heterogeneous nodes) but we'd soon add support
for multiple slot types.

> >  If we have to change the code according to the review, this would be another fundamental design changes.
> > Let me tell you how our design has evolved.
> > 
> > Our initial design did not change upstream scheduler part except adding BaremetalHostManager.
> > BaremetalHostManager (instead of HostManager) takes care of special communication with bare-metal nova-compute.
> > In this case, bare-metal nova-compute reports the largest available resources to BaremetalHostManager.
> > But Vish and other people did not like it and suggested the multiple entries of capabilities for bare-metal nova-compute.
> > (We've exchanged many emails in this mailing list to conclude the 2nd design.)
> > 
> > 2nd design: This is the design that is being reviewed.
> > Now bare-metal nova-compute reports multiple entries of capabilities of bare-metal machines.
> > We knew that this design change causes (non-trivial) changes in upstream scheduler.
> > After the 2nd design is summarized in that email chain at August 28, our team has worked based on that.
> > But, now the multiple entries of capabilities seem to disrupt the main nova too much. Sigh~
> 
> It seems to me that we've got work done in response to vish and other's
> comments and design input from earlier. It seems a little bit
> problematic to come back out of the context of the earlier design
> discussion and suggest a wholly-new design idea again at this point.

It's certainly not ideal, but sometimes an idea doesn't seem like such a
great idea when you see the code.

It may be that the patch implementing the idea could be improved so that
it starts looking like an OK idea again, but I wanted to explore another
idea which would potentially be much less invasive before proceeding. If
we figure out the idea won't work, we can go back to the current
proposed code again.

I understand everyone's a little jumpy because this folks have been keen
to see this merged for a while now, but that doesn't mean we should at
some point give up and merge whatever we have at that point.

Cheers,
Mark.