Open Stack

On 11/02/2016 06:23 AM, Arne Wiebalck wrote:
> Hi Valeriy,
>
> I wasn’t aware, thanks!
>
> So, if each driver exposes the storage_protocols it supports, would it 
> be sensible to have
> manila-ui check the extra_specs for this key and limit the protocol 
> choice for a given
> share type to the supported protocols (in order to avoid that the user 
> tries to create
> incompatible type/protocol combinations)?

This is not possible today, as any extra_specs related to protocols are 
hidden from normal API users. It's possible to make sure the share type 
called "nfs_shares" always goes to a backend that supports NFS, but it's 
not possible to programatically know that in a client, and therefore 
it's not possible to build the smarts into the UI. We intend to fix this 
though, as there is no good reason to keep that information hidden.

-Ben


> Thanks again!
>  Arne
>
>
>> On 02 Nov 2016, at 10:00, Valeriy Ponomaryov 
>> <vponomaryov at mirantis.com <mailto:vponomaryov at mirantis.com>> wrote:
>>
>> Hello, Arne
>>
>> Each share driver has capability called "storage_protocol". So, for 
>> case you describe, you should just define such extra spec in your 
>> share type that will match value reported by desired backend[s].
>>
>> It is the purpose of extra specs in share types, you (as cloud admin) 
>> define its connection yourself, either it is strong or not.
>>
>> Valeriy
>>
>> On Wed, Nov 2, 2016 at 9:51 AM, Arne Wiebalck <Arne.Wiebalck at cern.ch 
>> <mailto:Arne.Wiebalck at cern.ch>> wrote:
>>
>>     Hi,
>>
>>     We’re preparing the use of Manila in production and noticed that
>>     there seems to be no strong connection
>>     between share types and share protocols.
>>
>>     I would think that not all backends will support all protocols.
>>     If that’s true, wouldn’t it be sensible to establish
>>     a stronger relation and have supported protocols defined per
>>     type, for instance as extra_specs (which, as one
>>     example, could then be used by the Manila UI to limit the choice
>>     to supported protocols for a given share
>>     type, rather than maintaining two independent and hard-coded tuples)?
>>
>>     Thanks!
>>      Arne
>>
>>     --
>>     Arne Wiebalck
>>     CERN IT
>>
>>     __________________________________________________________________________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>> -- 
>> Kind Regards
>> Valeriy Ponomaryov
>> www.mirantis.com <http://www.mirantis.com/>
>> vponomaryov at mirantis.com <mailto:vponomaryov at mirantis.com>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org 
>> <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Arne Wiebalck
> CERN IT
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161102/aa408df9/attachment.html>