<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">> In addition, I prefer to managing flavor/type through API and decoupling</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> flavor/type definition from provider definitions in configuration files</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> as Cinder and Nova do.</span><br><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Yes, that's the current proposal.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Thanks,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Eugene.</span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 25, 2014 at 5:41 PM, Akihiro Motoki <span dir="ltr"><<a href="mailto:motoki@da.jp.nec.com" target="_blank">motoki@da.jp.nec.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
I have a same question from Mark. Why is "flavor" not desired?<br>
My first vote is "flavor" first, and then "type".<br>
<br>
There is similar cases in other OpenStack projects.<br>
Nova uses "flavor" and Cinder uses "(volume) type" for similar cases.<br>
Both cases are similar to our use cases and I think it is better to use<br>
either of them to avoid more confusion from naming for usesr and operators.<br>
<br>
Cinder volume_type detail is available at [1]. In Cinder volume_type,<br>
we can define multiple "volume_type" for one driver. <br>
(more precisely, "volume_type" is associated to one "backend defintion"<br>
and we can define multiple "backend definition" for one backend driver").<br>
<br>
In addition, I prefer to managing flavor/type through API and decoupling<br>
flavor/type definition from provider definitions in configuration files<br>
as Cinder and Nova do.<br>
<br>
[1] <a href="http://docs.openstack.org/admin-guide-cloud/content/multi_backend.html" target="_blank">
http://docs.openstack.org/admin-guide-cloud/content/multi_backend.html</a><br>
<br>
Thanks,<br>
Akihiro<div><div class="h5"><br>
<br>
<div>(2014/04/24 0:05), Eugene Nikanorov wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<div dir="ltr">Hi neutrons,
<div><br>
</div>
<div>A quick question of the ^^^</div>
<div>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.</div>
<div>So please, suggest you name for the resource.</div>
<div>Names that I've been thinking of:</div>
<div> - Capability group</div>
<div> - Service Offering</div>
<div><br>
</div>
<div>Thoughts?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Eugene.</div>
</div>
<br>
<fieldset></fieldset> <br>
</div></div><div class=""><pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</div></blockquote>
<br>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>