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