Open Stack

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