[openstack-dev] [Neutron] Flavor(?) Framework
Akihiro Motoki
motoki at da.jp.nec.com
Fri Apr 25 13:41:41 UTC 2014
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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140425/42b04e58/attachment.html>
More information about the OpenStack-dev
mailing list