Open Stack

On Thu, 2014-02-27 at 17:23 -0800, Joe Gordon wrote:
> On Thu, Feb 27, 2014 at 5:05 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> > On Thu, 2014-02-27 at 15:12 -0800, Joe Gordon wrote:
> >> On Thu, Feb 27, 2014 at 2:37 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> >> > On Thu, 2014-02-27 at 02:11 +0400, Eugene Nikanorov wrote:
> >> >> Hi neutron folks,
> >> >>
> >> >> I know that there are patches on gerrit for VPN, FWaaS and L3 services
> >> >> that are leveraging Provider Framework.
> >> >> Recently we've been discussing more comprehensive approach that will
> >> >> allow user to choose service capabilities rather than vendor or
> >> >> provider.
> >> >>
> >> >> I've started creating design draft of Flavor Framework, please take a
> >> >> look:
> >> >> https://wiki.openstack.org/wiki/Neutron/FlavorFramework
> >> >>
> >> >> It also now looks clear to me that the code that introduces providers
> >> >> for vpn, fwaas, l3 is really necessary to move forward to Flavors with
> >> >> one exception: providers should not be exposed to public API.
> >> >> While provider attribute could be visible to administrator (like
> >> >> segmentation_id of network), it can't be specified on creation and
> >> >> it's not available to a regular user.
> >> >
> >> > A few thoughts, Eugene, and thanks for putting together the wiki page
> >> > where we can work on this important topic.
> >> >
> >> > 1) I'm not entirely sure that a provider attribute is even necessary to
> >> > expose in any API. What is important is for a scheduler to know which
> >> > drivers are capable of servicing a set of attributes that are grouped
> >> > into a "flavor".
> >> >
> >> > 2) I would love to see the use of the term "flavor" banished from
> >> > OpenStack APIs. Nova has moved from flavors to "instance types", which
> >> > clearly describes what the thing is, without the odd connotations that
> >> > the word "flavor" has in different languages (not to mention the fact
> >> > that flavor is spelled flavour in non-American English).
> >>
> >> This isn't true, we moved towards preferring the term flavor.
> >
> > Really? When did this happen?
> 
> https://blueprints.launchpad.net/nova/+spec/flavor-instance-type-dedup
> 
> I wasn't aware of the decision to move to instance types. I could ask
> you the same thing, 'really when did that happen'

I could have sworn there was a conversation (I remember John Garbutt
specifically bringing up the problem of non-American-English spelling of
flavour) on openstack-dev, but I can't find it right now...

On your blueprint, you have:

"russellb: stick with our own terminology (flavor) except when
specifically doing EC2 handling IMO" ~ 2013-3-4

Unfortunately, nobody specified whether that was a design session, an ML
conversation or some random quote from IRC, so it's not entirely clear
where the decision came from or where the discussion was had. :)

I do note, however, that the blueprint is still going on, with the
latest Abandoned patch some time last January. I'll also note that
instance_type is used all over the documentation, is used in places like
Heat templating, and in general just makes a lot more sense. There's
also 401K results in Google for "instance_type Nova API" vs. 292K
results for "flavor Nova API". Just sayin.

Regardless of this, I still vote to *not* use the term flavor in
Neutron's API, but use the term "type" instead, and hopefully my other
points about Neutron types won't get lost in this side conversation ;)

Best,
-jay