[openstack-dev] Bare-metal node scheduling

Monty Taylor mordred at inaugust.com
Wed Oct 10 21:47:59 UTC 2012



On 10/10/2012 02:29 PM, Mark McLoughlin wrote:
> 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.

Totally!

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

I hear that. In my world though, the functionality would be taking a
step back while waiting for a feature that doesn't exist that once it
does would be finally back to parity with the current feature set.

Why not file a bug post merge to implement a multi-slot feature in
nova-compute with the understanding that the current scheduler work be
re-factored to use it once it's there?

(I'm saying this because moving targets are funny, but once there is an
additional example of what's needed in the code, it opens the doors to
other people to nudge it into a direction)

Also, that's for sake of argument - I readily understand that it may be
a non-ideal suggestion.

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

I agree that we shouldn't give up and merge whatever, but I do think
that it's early enough in the cycle that merging the current working
code and then setting out blueprints is a reasonable approach instead of
continuing to push the whole work out until it's "perfect" It's not like
this is merging a half-baked thing ... it works quite nicely at the
moment and I believe there are several of us using it right now... all
of whom are quite keen to continue to make it better and more usable
over time.

Monty



More information about the OpenStack-dev mailing list