[openstack-dev] [TripleO][Tuskar] Terminology

Ladislav Smola lsmola at redhat.com
Wed Dec 18 09:44:46 UTC 2013

On 12/17/2013 04:20 PM, Tzu-Mainn Chen wrote:
>> 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
> I think you're correct with respect to the end-user, and I can see the argument
> for terminology changes at the view level; it is important not to confuse the
> end-user.
> But at the level where developers are working with OpenStack APIs, I think it's
> important not to confuse the developers and reviewers, and that's most easily done
> by sticking with established OpenStack terminology.
> Mainn

I think we are assuming a lot here. I would rather keep the same naming 
Openstack use
and possibly rename it later based on users real feedback.

There is not only UI, sysadmins will work with CLI, using Openstack 
services, using Openstack
naming. So naming it differently will be confusing.

Btw. I would never hire a sysadmin that should be managing my 100s nodes 
cloud and have no idea
what is happening under the hood. :-D


> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list