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