Open Stack

On Thu, Apr 17, 2014 at 8:07 PM, Eugene Nikanorov
<enikanorov at mirantis.com> wrote:
> Hi Zang,
>
> 1.
>> so the tags is totally useless, and I suggest replace tags by provider
>> name/uuid. It is much more straightforward and easier.
> Funny thing is that the goal of flavor framework is directly opposite.
> We need to hide provider/vendor name. Ssl vpn or ipsec could be implemented
> by different vendors and we don't want to expose vendor or provider name.
> Instead, we may expose the type or other capabilities. It may be a
> coincidence the names 'sslvpn' and 'ipsec' map to both types of vpn and the
> provider names,
> but there are plenty of other cases (for other services) where additional
> parameters are needed.
I think the provider name is already hided w/o using tags, the user
can check and choose which flavor to use, only could admin can define
flavors.  As a cloud admin, I definitely want to choose which provider
to use directly instead of checking tags. The only think we need to
consider is hide the flavor from users, which can be achieved by using
policies.

>
> 2.
>> 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.
> A user isn't given an ability to name providers. Only deployer/cloud admin
> has a right to do that.
> Right now, when service implementation is chosen by the user directly by
> specifying the provider he/she wants, provider name is returned when you
> list providers.
> It is also used in REST call dispatching.
>
> We definitely will not expose anything like driver aliases to the user as it
> is a particular implementation detail.
So we need to separate them more clearly:
 * the cloud admin defined provider name
 * the hard-coded provider alias
and we may also need a mapping from name to alias, the database should
be a better place to store the mapping than config files.

this is how we find provider plugin currently:

1. get service_instance.provider_name from db
2. lookup service_provider in neutron.conf
3. get the plugin

it is wired that a database field is referring a configuration entry.

>
> Thanks,
> Eugene.
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>