Open Stack

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 <jaypipes at gmail.com>
> To: openstack-dev at lists.openstack.org, 
> 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
> > > OpenStack-dev at lists.openstack.org
> > > http://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
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://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