Open Stack

Hi folks,

In Icehouse there were attempts to apply Provider Framework ('Service Type
Framework') approach to VPN and Firewall services.
Initially Provider Framework was created as a simplistic approach of
allowing user to choose service implementation.
That approach definitely didn't account for public cloud case where users
should not be aware of underlying implementation, while being able to
request capabilities or a SLA.

However, Provider Framework consists of two parts:
1) API part.
That's just 'provider' attribute of the main resource of the service plus a
REST call to fetch available providers for a service

2) Dispatching part
That's a DB table that keeps mapping between resource and implementing
provider/driver.
With this mapping it's possible to dispatch a REST call to the particular
driver that is implementing the service.

As we are moving to better API and user experience, we may want to drop the
first part, which makes the framework "non-public-cloud-friendly" but the
second part will remain if we ever want to support more then one driver
simultaneously.

Flavor framework proposes choosing implementation based on capabilities,
but the result of the choice (e.g. scheduling) is still a mapping between
resource and the driver.
So the second part is still needed for the Flavor Framework.

I think it's a good time to continue the discussion on Flavor and Provider
Frameworks.

Some references:
1. Flavor Framework description
https://wiki.openstack.org/wiki/Neutron/FlavorFramework
2. Flavor Framework PoC/example code https://review.openstack.org/#/c/83055/
3. FWaaS integration with Provider framework:
https://review.openstack.org/#/c/60699/
4. VPNaaS integration with Provider framework:
https://review.openstack.org/#/c/41827/

I'd like to see the work on (3) and (4) continued, considering Provider
Framework is a basis for Flavor Framework.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140416/6f8030dc/attachment.html>