Open Stack

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
> >>>>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.

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
> 
> Ladislav
> 
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
-- James Slagle
--