<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 14, 2013 at 8:13 PM, Michael Still <span dir="ltr"><<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Thu, Mar 14, 2013 at 8:50 PM, Blair Bethwaite<br>


<<a href="mailto:blair.bethwaite@gmail.com" target="_blank">blair.bethwaite@gmail.com</a>> wrote:<br>
<br>
> I think Joe has hit on the crux of this here. There are so many permutations<br>
> of possible deployments that it just isn't reasonable to test everything,<br>
> let alone even think of all the possibilities, e.g., to continue with the<br>
> current example, what happens if I have several different pools of shared<br>
> storage servicing distinct sets of compute nodes under the same Nova<br>
> deployment...? So it seems reasonable when looking at issues like this that<br>
> they should be viewed through the prism of a novice OS operator (experienced<br>
> sysadmin but little domain knowledge).<br>
><br>
> For this particular problem I don't think either the on or off default is<br>
> satisfactory. Nova needs to know whether it's dealing with shared storage or<br>
> not. Where it is, the default should be off, where it's not, on.<br>
<br>
</div>Grizzly attempts to handle this very situation -- it tries to learn<br>
the topology of your storage and do sensible things. Unfortunately Joe<br>
was aware of a bug but didn't report it, and now we don't have time to<br>
fix it for grizzly RC1, which is a shame. Perhaps we'll get it fixed<br>
for RC2, although it still seems that a bug hasn't been filed.<br></blockquote><div><br></div><div>Filed: <a href="https://bugs.launchpad.net/nova/+bug/1155391" target="_blank">https://bugs.launchpad.net/nova/+bug/1155391</a></div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'd expect to see this feature on by default in grizzly. Its been off<br>
for two releases, which should be ample time for operators to have run<br>
it in their labs. Its now time to deploy it for real. Its important<br>
that we enable it because nova is too hard to configure correctly, and<br>
we need to reduce the number of "make it work" flags that operators<br>
need to add to deployments. Ultimately nova is in the business of<br>
managing resources on compute nodes -- its creating and destroying<br>
VMs, disk volumes, iscsi endpoints and so forth. Cached disk images<br>
are no different.<br>
<br>
I think my overall learning from this thread is that there's no point<br>
disabling features for a few releases so that operators can test in a<br>
staged manner -- the reality is that testing doesn't occur. </blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
Michael<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Joe Topjian<div>Systems Administrator</div><div>Cybera Inc.</div><div><br></div><div><a href="http://www.cybera.ca" target="_blank">www.cybera.ca</a></div>

<div><br></div><div><font color="#666666"><span>Cybera</span><span> is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.</span></font></div>


</div></div>