Open Stack

On 13 December 2013 05:35, Keith Basil <kbasil at redhat.com> wrote:
> On Dec 10, 2013, at 5:09 PM, Robert Collins wrote:






>>>> unallocated | aqvailable | undeployed
>>>
>>> +1 unallocated
>>
>> I think available is most accurate, but undeployed works too. I really
>> don't like unallocated, sorry!
>
>         Would "available" introduce/denote that the service is deployed
>         and operational?

It could lead to that confusion. Jaromir suggested free in the other
thread, I think that that would work well and avoid the confusion with
'working service' that available has.


>> Brainstorming: role is something like 'KVM compute', but we may have
>> two differing only in configuration sets of that role. In a very
>> technical sense it's actually:
>> image + configuration -> scaling group in Heat.
>> So perhaps:
>> Role + Service group ?
>> e.g. GPU KVM Hypervisor would be a service group, using the KVM
>> Compute role aka disk image.
>>
>> Or perhaps we should actually surface image all the way up:
>>
>> Image + Service group ?
>> image = what things we build into the image
>> service group = what runtime configuration we're giving, including how
>> many machines we want in the group
>>
>         How about just leaving it as Resource Class?  The things you've
>         brainstormed about are in line with the original thinking around
>         the resource class concept.
>
>         role (assumes role specific image) +
>         service/resource grouping +
>         hardware that can provide that service/resource

So, Resource Class as originally communicated really is quite
different to me: though obviously there is some overlap. I can drill
into that if you want ... however the implications of the words and
how folk can map from them back to the plumbing is what really
concerns me, so thats what I'll focus on here.

Specifically: Resource Class was focused on the resources being
offered into the overcloud, but the image + (service config/service
group/group config) idea applies to all things we deploy equally -
it's relevant to management instances, control plane instances, as
well as Nova and Cinder. So the Resource part of it doesn't really
fit. Using 'Class' is just jargon - I would expect it to be pretty
impenetrable to non-programmers.

Ideally I think we want something that:
 - has a fairly obvious mapping back to Nova/Heat terminology (e.g. if
the concepts are the same, lets call them the same)
 - doesn't overlap other terms unless they are compatible.

For instance Heat has a concept 'resourcegroup' where resource means
'the object that heat has created and is managing' and the group
refers to scaling to some N of them. This is what we will eventually
back a particular image + config onto - that becomes one resourcegroup
in heat; using resource class to refer to that when the resource
referred to is the delivered service, not 'Instance's (the Nova
baremetal instances we create through the resourcegroup) is going to
cause significant confusion at minimum :)

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud