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