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' > >> > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
