Hi Eugene:
I have several questions
1. I wonder if tags is really needed. for example, if I want a ipsec
vpn, I'll define a flavor which is directly refer to ipsec provider.
If using current design, almost all users will end up creating flavors
like this:
ipsec tags=[ipsec]
sslvpn tags=[sslvpn]
so the tags is totally useless, and I suggest replace tags by provider
name/uuid. It is much more straightforward and easier.
2. currently the provider name is something configured in neutron.conf:
service_provider=<service_type>:<name>:<driver>[:default]
the name is arbitrary, user may set whatever he want, and the name is
also used in service instance stored in database. I don't know why
give user the ability to name the provider, and the name is totally
nonsense, it hasn't been referred anywhere. I think each service
provider should provide a alias, so user can configure service more
flexible:
service_provider=<service_type>:<driver_alias>[:default]
and the alias can be also used as an identifier in rpc or other place,
also I don't want to see any user configured name used as an
identifier.
On Wed, Apr 16, 2014 at 5:10 AM, Eugene Nikanorov
<enikano...@mirantis.com> wrote:
> 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.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
