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). 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