Open Stack

My apologies for firing this off and then hiding under the FOSDEM rock.

In light of the points raised by Devananda and Robert, I no longer think 
fiddling with the scheduler is the way to go.

Note this was never intended to break/confuse all TripleO users -- I 
considered it a cleaner equivalent to entering incorrect HW specs (i.e. 
instead of doing that you would switch to this other filter in nova.conf).

Regardless, I stand corrected on the distinction between heterogeneous 
hardware all the way and having a flavour per service definition. That 
was a very good point to raise.

I'm fine with both approaches.

So yeah, let's work towards having a single Node Profile (flavor) 
associated with each Deployment Role (pages 12 & 13 of the latest 
mockups[1]), optionally starting with requiring all the Node Profiles to 
be equal.

Once that's working fine, we can look into the harder case of having 
multiple Node Profiles within a Deployment Role.

Is everyone comfortable with that?

Tomas

[1]: 
http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-27_tripleo-ui-icehouse.pdf

On 03/02/14 00:21, Robert Collins wrote:
> On 3 February 2014 08:45, Jaromir Coufal <jcoufal at redhat.com> wrote:
>>
>
>>> However, taking a step back, maybe the real answer is:
>>>
>>> a) homogeneous nodes
>>> b) document. . .
>>>      - **unsupported** means of "demoing" Tuskar (set node attributes to
>>> match flavors, hack
>>>        the scheduler, etc)
>>
>> Why are people calling it 'hack'? It's an additional filter to
>> nova-scheduler...?
>
> It doesn't properly support the use case; its extra code to write and
> test and configure that is precisely identical to mis-registering
> nodes.
>
>>>      - our goals of supporting heterogeneous nodes for the J-release.
>>
>> I wouldn't talk about J-release. I would talk about next iteration or next
>> step. Nobody said that we are not able to make it in I-release.
>
> +1
>
>>
>>> Does this seem reasonable to everyone?
>>>
>>> Mainn
>>
>>
>> Well +1 for a) and it's documentation.
>>
>> However me and Robert, we look to have different opinions on what
>> 'homogeneous' means in our context. I think we should clarify that.
>
> So I think my point is more this:
>   - either this iteration is entirely limited to homogeneous hardware,
> in which case, document it, not workarounds or custom schedulers etc.
>   - or it isn't limited, in which case we should consider the options:
>     - flavor per service definition
>     - custom scheduler
>     - register nodes wrongly
>
> -Rob
>