Hi, I have a same question from Mark. Why is "flavor" not desired? My first vote is "flavor" first, and then "type".
There is similar cases in other OpenStack projects. Nova uses "flavor" and Cinder uses "(volume) type" for similar cases. Both cases are similar to our use cases and I think it is better to use either of them to avoid more confusion from naming for usesr and operators. Cinder volume_type detail is available at [1]. In Cinder volume_type, we can define multiple "volume_type" for one driver. (more precisely, "volume_type" is associated to one "backend defintion" and we can define multiple "backend definition" for one backend driver"). In addition, I prefer to managing flavor/type through API and decoupling flavor/type definition from provider definitions in configuration files as Cinder and Nova do. [1] http://docs.openstack.org/admin-guide-cloud/content/multi_backend.html Thanks, Akihiro (2014/04/24 0:05), Eugene Nikanorov wrote: Hi neutrons, A quick question of the ^^^ I heard from many of you that a term 'flavor' is undesirable, but so far there were no suggestions for the notion that we are going to introduce. So please, suggest you name for the resource. Names that I've been thinking of: - Capability group - Service Offering Thoughts? Thanks, Eugene. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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
