Open Stack

Hi,

The discussion about advanced services and scheduling was primarily around choosing backbends based on capabilities.
AFAIK, the Nova flavor specify capacity.
So I think that using the term "flavor" might not match what is intended.
A better word might be "capability" or "group of capabilities".

Is the following what we want to achieve?

*         A tenant creates a vip and requires high-available with advanced L7 and SSL capabilities for production.

*         Another tenant creates a vip that requires advanced L7 and SSL capabilities for development.

The admin or maybe even the tenant might group such capabilities (ha, L7, SSL) and name them advanced-adc and another group of capabilities (no-ha, L7, SSL) and name them adc-for-testing.

This leads to an abbreviation of:

*         Tenant creates a vip that requires advanced-adc.

*         Tenant creates a vip the requires adc-for-testing.

Regards,
                -Sam.







From: Eugene Nikanorov [mailto:enikanorov at mirantis.com]
Sent: Thursday, February 27, 2014 12:12 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] Flavor Framework

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.

Looking forward to get your feedback.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140303/725f73ee/attachment-0001.html>