Open Stack

On Thu, Feb 27, 2014 at 2:37 PM, Jay Pipes <jaypipes at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev