[openstack-dev] [TripleO][Tuskar] Terminology
james.slagle at gmail.com
Wed Dec 18 13:02:28 UTC 2013
On Wed, Dec 18, 2013 at 10:44:46AM +0100, Ladislav Smola wrote:
> 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
> >>>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
> >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.
> 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.
Generally, I'm +1 here.
I do however see a couple of downsides with it:
- OpenStack concepts, while they may be well defined and understood in the
developer community, that doesn't always mean they make sense, and so to a
new user they could be confusing (a few others already pointed this out).
For example, using Instance, I *think* (no hard data really) most people
assume virtual when you say Instance. Nova can obviously do baremetal, but
that may not be clear to everyone at first. I mean, I assume Ironic is named
Ironic for a reason :). That should tell you right there that it's doing
something different, and not what's necessarily expected.
- Internal OpenStack terminology can change. We'd need to update the UI for
those changes if we wanted to stay up to date, or we're back to having a UI
that doesn't match internal concepts. If we compromised in the beginning by
using an internal concept that wasn't necessarily clear, we're then even
worse off. For example, isn't there a push now to update the usage of
"tenant" in some places? I know we're not calling that term out
specifically, but it's just an example.
> 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
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-- James Slagle
More information about the OpenStack-dev