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