<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13px">I'd also recommend simplifying the API and CLI by removing the</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> implementation-focused "provider type" stuff eventually, as well, since</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> a service type framework would essentially make that no longer needed --</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> at least on the public API side of things.</span><div>
<span style="font-family:arial,sans-serif;font-size:13px">Correct, that's the part of the proposed change, although we probably need to support it for one more release.</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">Eugene.</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 25, 2014 at 9:40 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, 2014-04-25 at 13:32 -0400, Mohammad Banikazemi wrote:<br>
> As I understand the proposed flavor framework, the intention is to<br>
> provide a mechanism for specifying different "flavors" of a given<br>
> service "type"  as they  are already defined. So using the term "type"<br>
> may be confusing. Here we want to specify possibly different set of<br>
> capabilities within a given defined service type.<br>
<br>
</div>Hi Mohammed,<br>
<br>
Yes, the trouble in Neutron is the existing service type usage... I<br>
proposed to rename that to service family or service class in a previous<br>
email, and use a type for each service class, so:<br>
<br>
load balancer type<br>
firewall type<br>
VPN type<br>
<br>
I'd also recommend simplifying the API and CLI by removing the<br>
implementation-focused "provider type" stuff eventually, as well, since<br>
a service type framework would essentially make that no longer needed --<br>
at least on the public API side of things.<br>
<br>
Best,<br>
-jay<br>
<div class=""><br>
> Inactive hide details for Jay Pipes ---04/25/2014 12:09:43 PM---On<br>
</div>> Fri, 2014-04-25 at 13:41 +0000, Akihiro Motoki wrote: > Hi,Jay Pipes<br>
<div class="">> ---04/25/2014 12:09:43 PM---On Fri, 2014-04-25 at 13:41 +0000, Akihiro<br>
> Motoki wrote: > Hi,<br>
><br>
> From: Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>><br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>,<br>
> Date: 04/25/2014 12:09 PM<br>
> Subject: Re: [openstack-dev] [Neutron] Flavor(?) Framework<br>
><br>
><br>
><br>
</div>> ______________________________________________________________________<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
> On Fri, 2014-04-25 at 13:41 +0000, Akihiro Motoki wrote:<br>
> > 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>
> Some reasons:<br>
><br>
> First, flavor, in English, can and often is spelled differently<br>
> depending on where you live in the world (flavor vs. flavour).<br>
><br>
> Second, type is the appropriate term for what this is describing, and<br>
> doesn't have connotations of taste, which flavor does.<br>
><br>
> I could also mention that the term "flavor" is a vestige of the<br>
> Rackspace Cloud API and, IMO, should be killed off in place of the<br>
> more<br>
> common and better understood "instance type" which is used by the EC2<br>
> API.<br>
><br>
> > There is similar cases in other OpenStack projects.<br>
> > Nova uses "flavor" and Cinder uses "(volume) type" for similar<br>
> cases.<br>
> > Both cases are similar to our use cases and I think it is better to<br>
> > use<br>
> > either of them to avoid more confusion from naming for usesr and<br>
> > operators.<br>
> ><br>
> > Cinder volume_type detail is available at [1]. In Cinder<br>
> volume_type,<br>
> > we can define multiple "volume_type" for one driver.<br>
> > (more precisely, "volume_type" is associated to one "backend<br>
> > defintion"<br>
> > and we can define multiple "backend definition" for one backend<br>
> > driver").<br>
> ><br>
> > In addition, I prefer to managing flavor/type through API and<br>
> > decoupling<br>
> > flavor/type definition from provider definitions in configuration<br>
> > files<br>
> > as Cinder and Nova do.<br>
><br>
> Yes, I don't believe there's any disagreement on that particular<br>
> point.<br>
> This effort is all about trying to provide a more comfortable and<br>
> reasonable way for classification of these advanced services to be<br>
> controlled by the user.<br>
><br>
> Best,<br>
> -jay<br>
><br>
> > [1]<br>
> ><br>
> <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<br>
> ><br>
> > (2014/04/24 0:05), Eugene Nikanorov wrote:<br>
> ><br>
> > > Hi neutrons,<br>
> > ><br>
> > ><br>
> > > A quick question of the ^^^<br>
> > > I heard from many of you that a term 'flavor' is undesirable, but<br>
> so<br>
> > > far there were no suggestions for the notion that we are going to<br>
> > > introduce.<br>
> > > So please, suggest you name for the resource.<br>
> > > Names that I've been thinking of:<br>
> > >  - Capability group<br>
> > >  - Service Offering<br>
> > ><br>
> > ><br>
> > > Thoughts?<br>
> > ><br>
> > ><br>
> > > Thanks,<br>
> > > Eugene.<br>
> > ><br>
> > ><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>
> > _______________________________________________<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>
><br>
><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>
><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>
<br>
<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>
</div></div></blockquote></div><br></div>