On Thu, 2014-02-27 at 17:23 -0800, Joe Gordon wrote: > On Thu, Feb 27, 2014 at 5:05 PM, Jay Pipes <jaypi...@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 <jaypi...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
