Open Stack

On 2013/13/12 23:11, Jordan OMara wrote:
> On 13/12/13 16:20 +1300, Robert Collins wrote:
>> However, on instance - 'instance' is a very well defined term in Nova
>> and thus OpenStack: Nova boot gets you an instance, nova delete gets
>> rid of an instance, nova rebuild recreates it, etc. Instances run
>> [virtual|baremetal] machines managed by a hypervisor. So
>> nova-scheduler is not ever going to be confused with instance in the
>> OpenStack space IMO. But it brings up a broader question, which is -
>> what should we do when terms that are well defined in OpenStack - like
>> Node, Instance, Flavor - are not so well defined for new users? We
>> could use different terms, but that may confuse 'stackers, and will
>> mean that our UI needs it's own dedicated terminology to map back to
>> e.g. the manuals for Nova and Ironic. I'm inclined to suggest that as
>> a principle, where there is a well defined OpenStack concept, that we
>> use it, even if it is not ideal, because the consistency will be
>> valuable.
>
> I think this is a really important point. I think the consistency is a
> powerful tool for teaching new users how they should expect
> tripleo/tuskar to work and should lessen the learning curve, as long
> they've used openstack before.
I don't 100% agree here. Yes it is important for user to keep 
consistency in naming - but as long as he is working within the same 
domain. Problem is that our TripleO/Tuskar UI user is very different 
from OpenStack UI user. They are operators, and they might be very often 
used to different terminology - globally used and known in their field 
(for example Flavor is very OpenStack specific term, they might better 
see HW profile, or similar).

I think that mixing these terms in overcloud and undercloud might lead 
to problems and users' confusion. They already are confused about the 
whole 'over/under cloud' stuff. They are not working with this approach 
daily as we are. They care about deploying OpenStack, not about how it 
works under the hood. Bringing another more complicated level of 
terminology (explaining what is and belongs to under/overcloud) will 
increase the confusion here.

For developers, it might be easier to deal with the same terms as 
OpenStack already have or what is used in the background to make that 
happen. But for user - it will be confusing going to 
infrastructure/hardware management part and see the very same terms.

Therefor I incline more to broadly accepted general terminology and not 
reusing OpenSTack terms (at least in the UI).

-- Jarda