<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">Hi Jordan,</div>
<div class=""><br class="">
</div>
<div class="">As Duncan pointed out there may be issues if you have multiple backends</div>
<div class="">and indistinguishable nodes (which you could probably avoid by separating</div>
<div class="">the hosts per backend and use different “host” flags for each set).</div>
<div class=""><br class="">
</div>
<div class="">But also if you have only one backend: the “host" flag will enter the ‘services'</div>
<div class="">table and render the host column more or less useless. I imagine this has an</div>
<div class="">impact on things using the services table, such as “cinder-manage” (how</div>
<div class="">does your “cinder-manage service list” output look like? :-), and it may make it</div>
<div class="">harder to tell if the individual services are doing OK, or to control them.</div>
<div class=""><br class="">
</div>
<div class="">I haven’t run Cinder with identical “host” flags in production, but I imagine</div>
<div class="">there may be other areas which are not happy about indistinguishable hosts.</div>
<div class=""><br class="">
</div>
<div class="">Arne</div>
<div class=""><br class="">
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 08 Jan 2015, at 16:50, Jordan Pittier <<a href="mailto:jordan.pittier@scality.com" class="">jordan.pittier@scality.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Hi,
<div class="">><span style="font-size:12.7272720336914px" class="">Some </span><span style="font-size:12.7272720336914px" class="">people apparently use the ‘host’ option in cinder.conf to make the hosts indistinguishable, but this creates problems in other
places.</span></div>
<div class=""><span style="font-size:12.7272720336914px" class="">I use shared storage mounted on several cinder-volume nodes, with "host" flag set the same everywhere. Never ran into problems so far. Could you elaborate on "</span><span style="font-size:12.7272720336914px" class="">this
creates problems in other places" please ?</span></div>
<div class=""><span style="font-size:12.7272720336914px" class=""><br class="">
</span></div>
<div class=""><span style="font-size:12.7272720336914px" class="">Thanks !</span></div>
<div class=""><span style="font-size:12.7272720336914px" class="">Jordan</span></div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Thu, Jan 8, 2015 at 3:40 PM, Arne Wiebalck <span dir="ltr" class="">
<<a 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">
<div style="word-wrap:break-word" class="">
<div class="">Hmm. Not sure how widespread installations with multiple Ceph backends are where the</div>
<div class="">Cinder hosts have access to only one of the backends (which is what you assume, right?)</div>
<div class="">But, yes, if the volume type names are also the same (is that also needed for this to be a</div>
<div class="">problem?), this will be an issue ...</div>
<div class=""><br class="">
</div>
<div class="">So, how about providing the information the scheduler does not have by introducing an</div>
<div class="">additional tag to identify ‘equivalent’ backends, similar to the way some people already</div>
<div class="">use the ‘host’ option?</div>
<div class=""><br class="">
</div>
<div class="">Thanks!</div>
<span class="HOEnZb"><font color="#888888" class="">
<div class=""> Arne</div>
</font></span>
<div class="">
<div class="h5">
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 08 Jan 2015, at 15:11, Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com" target="_blank" class="">duncan.thomas@gmail.com</a>> wrote:</div>
<br class="">
<div class="">
<div dir="ltr" class="">The problem is that the scheduler doesn't currently have enough info to know which backends are 'equivalent' and which aren't. e.g. If you have 2 ceph clusters as cinder backends, they are indistinguishable from each other.<br class="">
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On 8 January 2015 at 12:14, Arne Wiebalck <span dir="ltr" class="">
<<a 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="">
The fact that volume requests (in particular deletions) are coupled with certain Cinder hosts is not ideal from an operational perspective:<br class="">
if the node has meanwhile disappeared, e.g. retired, the deletion gets stuck and can only be unblocked by changing the database. Some<br class="">
people apparently use the ‘host’ option in cinder.conf to make the hosts indistinguishable, but this creates problems in other places.<br class="">
<br class="">
From what I see, even for backends that would support it (such as Ceph), Cinder currently does not provide means to ensure that any of<br class="">
the hosts capable of performing a volume operation would be assigned the request in case the original/desired one is no more available,<br class="">
right?<br class="">
<br class="">
If that is correct, how about changing the scheduling of delete operation to use the same logic as create operations, that is pick any of the<br class="">
available hosts, rather than the one which created a volume in the first place (for backends where that is possible, of course)?<br class="">
<br class="">
Thanks!<br class="">
Arne<br class="">
<br class="">
—<br class="">
<span class=""><font color="#888888" class="">Arne Wiebalck<br class="">
CERN IT<br class="">
_______________________________________________<br class="">
OpenStack-dev mailing list<br class="">
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank" class="">OpenStack-dev@lists.openstack.org</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
</font></span></blockquote>
</div>
<br class="">
<br clear="all" class="">
<br class="">
-- <br class="">
<div class="">Duncan Thomas</div>
</div>
_______________________________________________<br class="">
OpenStack-dev mailing list<br class="">
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank" class="">OpenStack-dev@lists.openstack.org</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
<br class="">
_______________________________________________<br class="">
OpenStack-dev mailing list<br class="">
<a href="mailto:OpenStack-dev@lists.openstack.org" class="">OpenStack-dev@lists.openstack.org</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
<br class="">
</blockquote>
</div>
<br class="">
</div>
_______________________________________________<br class="">
OpenStack-dev mailing list<br class="">
<a href="mailto:OpenStack-dev@lists.openstack.org" class="">OpenStack-dev@lists.openstack.org</a><br class="">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br class="">
</div>
</blockquote>
</div>
<br class="">
</body>
</html>