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? > > How about using the term "load balancer type", "VPN type", and "firewall > > type" instead? > > > > 3) I don't believe the FlavorType (public or internal) attribute of the > > flavor is useful. We want to get away from having any vendor-specific > > attributes or objects in the APIs (yes, even if they are "hidden" from > > the normal user). See point #1 for more about this. A scheduler should > > be able to match a driver to a request simply by matching the set of > > required capabilities in the requested flavor (load balancer type) to > > the set of capabilities advertised by the driver. > > > > 4) A minor point... I think it would be fine to group the various > > "types" into a single database table behind the scenes (like you have in > > the Object model section). However, I think it is useful to have the > > public API expose a /$servie-types resource endpoint for each service > > itself, instead of a generic /types (or /flavors) endpoint. So, folks > > looking to set up a load balancer would call GET /balancer-types, or > > call neutron balancer-type-list, instead of calling > > GET /types?service=load-balancer or neutron flavor-list > > --service=load-balancer > > > > 5) In the section on Scheduling, you write "Scheduling is a process of > > choosing provider and a backend for the resource". As mentioned above, I > > think this could be changed to something like this: "Scheduling is a > > process of matching the set of requested capabilities -- the flavor > > (type) -- to the set of capabilities advertised by a driver for the > > resource". That would put Neutron more in line with how Nova handles > > this kind of thing. > > > > Anyway, just food for thought. > > > > Best, > > -jay > > > > > >> Looking forward to get your feedback. > >> > >> > >> 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev