Open Stack

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

Yes, that's the current proposal.

Thanks,
Eugene.


On Fri, Apr 25, 2014 at 5:41 PM, Akihiro Motoki <motoki at da.jp.nec.com>wrote:

>  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 listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/282ef6e0/attachment.html>