Open Stack

> 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.
Correct, that's the part of the proposed change, although we probably need
to support it for one more release.

Eugene.


On Fri, Apr 25, 2014 at 9:40 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> 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
>
>
>
> _______________________________________________
> 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/30996431/attachment.html>