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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
