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
<vponomar...@mirantis.com <mailto:vponomar...@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.wieba...@cern.ch
<mailto:arne.wieba...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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/>
vponomar...@mirantis.com <mailto:vponomar...@mirantis.com>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
<mailto:openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
