Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev