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

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