Open Stack

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.

Mohammad




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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140425/634cf665/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140425/634cf665/attachment.gif>