Open Stack

On 02 Nov 2016, at 15:15, Ben Swartzlander <ben at swartzlander.org<mailto:ben at swartzlander.org>> wrote:

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.

I see, thanks.

Concerning the workaround for bug/1622732: Would you agree that configuring protocol/type
tuples (rather than only protocols) would be a better solution?

Cheers,
 Arne


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



--
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<mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
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

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