On Fri, 2014-04-25 at 13:32 -0400, Mohammad Banikazemi wrote: > As I understand the proposed flavor framework, the intention is to > provide a mechanism for specifying different "flavors" of a given > service "type" as they are already defined. So using the term "type" > may be confusing. Here we want to specify possibly different set of > capabilities within a given defined service type.
Hi Mohammed, Yes, the trouble in Neutron is the existing service type usage... I proposed to rename that to service family or service class in a previous email, and use a type for each service class, so: load balancer type firewall type VPN type I'd also recommend simplifying the API and CLI by removing the implementation-focused "provider type" stuff eventually, as well, since a service type framework would essentially make that no longer needed -- at least on the public API side of things. Best, -jay > Inactive hide details for Jay Pipes ---04/25/2014 12:09:43 PM---On > Fri, 2014-04-25 at 13:41 +0000, Akihiro Motoki wrote: > Hi,Jay Pipes > ---04/25/2014 12:09:43 PM---On Fri, 2014-04-25 at 13:41 +0000, Akihiro > Motoki wrote: > Hi, > > From: Jay Pipes <[email protected]> > To: [email protected], > Date: 04/25/2014 12:09 PM > Subject: Re: [openstack-dev] [Neutron] Flavor(?) Framework > > > > ______________________________________________________________________ > > > > On Fri, 2014-04-25 at 13:41 +0000, Akihiro Motoki wrote: > > Hi, > > > > I have a same question from Mark. Why is "flavor" not desired? > > My first vote is "flavor" first, and then "type". > > Some reasons: > > First, flavor, in English, can and often is spelled differently > depending on where you live in the world (flavor vs. flavour). > > Second, type is the appropriate term for what this is describing, and > doesn't have connotations of taste, which flavor does. > > I could also mention that the term "flavor" is a vestige of the > Rackspace Cloud API and, IMO, should be killed off in place of the > more > common and better understood "instance type" which is used by the EC2 > API. > > > 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. > > Yes, I don't believe there's any disagreement on that particular > point. > This effort is all about trying to provide a more comfortable and > reasonable way for classification of these advanced services to be > controlled by the user. > > Best, > -jay > > > [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 > > > [email protected] > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
