Open Stack

On Thu, Feb 27, 2014 at 5:05 PM, Jay Pipes <jaypipes at 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 <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.
>
> 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 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
>>
>> _______________________________________________
>> 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