<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/02/2016 06:23 AM, Arne Wiebalck
wrote:<br>
</div>
<blockquote cite="mid:F5DF4912-61DB-456A-B393-452F75051CEB@cern.ch"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class="">Hi Valeriy,</div>
<div class=""><br class="">
</div>
<div class="">I wasn’t aware, thanks! </div>
<div class=""><br class="">
</div>
<div class="">So, if each driver exposes the storage_protocols it
supports, would it be sensible to have</div>
<div class="">manila-ui check the extra_specs for this key and
limit the protocol choice for a given</div>
<div class="">share type to the supported protocols (in order to
avoid that the user tries to create</div>
<div class="">incompatible type/protocol combinations)?</div>
</blockquote>
<br>
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.<br>
<br>
-Ben<br>
<br>
<br>
<blockquote cite="mid:F5DF4912-61DB-456A-B393-452F75051CEB@cern.ch"
type="cite">
<div class="">
</div>
<div class="">Thanks again!</div>
<div class=""> Arne</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">On 02 Nov 2016, at 10:00, Valeriy Ponomaryov
<<a moz-do-not-send="true"
href="mailto:vponomaryov@mirantis.com" class="">vponomaryov@mirantis.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Hello, Arne
<div class=""><br class="">
</div>
<div class="">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].</div>
<div class=""><br class="">
</div>
<div class="">It is the purpose of extra specs in share
types, you (as cloud admin) define its connection
yourself, either it is strong or not.</div>
<div class=""><br class="">
</div>
<div class="">Valeriy</div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Wed, Nov 2, 2016 at 9:51 AM,
Arne Wiebalck <span dir="ltr" class="">
<<a moz-do-not-send="true"
href="mailto:Arne.Wiebalck@cern.ch" target="_blank"
class="">Arne.Wiebalck@cern.ch</a>></span> wrote:<br
class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br class="">
<br class="">
We’re preparing the use of Manila in production and
noticed that there seems to be no strong connection<br
class="">
between share types and share protocols.<br class="">
<br class="">
I would think that not all backends will support all
protocols. If that’s true, wouldn’t it be sensible to
establish<br class="">
a stronger relation and have supported protocols
defined per type, for instance as extra_specs (which,
as one<br class="">
example, could then be used by the Manila UI to limit
the choice to supported protocols for a given share<br
class="">
type, rather than maintaining two independent and
hard-coded tuples)?<br class="">
<br class="">
Thanks!<br class="">
Arne<br class="">
<br class="">
--<br class="">
Arne Wiebalck<br class="">
CERN IT<br class="">
<br class="">
______________________________<wbr class="">______________________________<wbr
class="">______________<br class="">
OpenStack Development Mailing List (not for usage
questions)<br class="">
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe"
rel="noreferrer" target="_blank" class="">
OpenStack-dev-request@lists.<wbr class="">openstack.org?subject:<wbr
class="">unsubscribe</a><br class="">
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank" class="">http://lists.openstack.org/<wbr
class="">cgi-bin/mailman/listinfo/<wbr class="">openstack-dev</a><br
class="">
</blockquote>
</div>
<br class="">
<br class="" clear="all">
<div class=""><br class="">
</div>
-- <br class="">
<div class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr" class="">Kind Regards<br class="">
Valeriy Ponomaryov<br class="">
<a moz-do-not-send="true"
href="http://www.mirantis.com/" target="_blank"
class="">www.mirantis.com</a><br class="">
<a moz-do-not-send="true"
href="mailto:vponomaryov@mirantis.com"
target="_blank" class="">vponomaryov@mirantis.com</a><br
class="">
</div>
</div>
</div>
__________________________________________________________________________<br
class="">
OpenStack Development Mailing List (not for usage questions)<br
class="">
Unsubscribe: <a moz-do-not-send="true"
href="mailto:OpenStack-dev-request@lists.openstack.org"
class="">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br
class="">
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
<div class="">--<br class="">
Arne Wiebalck<br class="">
CERN IT </div>
<br class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>