Open Stack

Hello,

+1 to 'let's work towards having a single Node Profile (flavor) 
associated with each Deployment Role (pages 12 & 13 of the latest 
mockups[1])'

Good start.

We could have also more flavors per role now, user just would have to be 
advised: "You are using one image for multiple hardware, so be sure it's 
compatible." So it probably make sense to limit it for one flavor per 
role for now.

Regards
Ladislav


On 02/03/2014 12:23 PM, Tomas Sedovic wrote:
> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev