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

Reply via email to