<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 14, 2016 at 2:11 AM, Avishay Traeger <span dir="ltr"><<a href="mailto:avishay@stratoscale.com" target="_blank">avishay@stratoscale.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.8px">Hi all,</div><div style="font-size:12.8px"><span style="font-size:12.8px">I would like to propose working on a new feature for Ocata to provide health information for Cinder backends and volumes. Currently, a volume's status basically reflects the last management operation performed on it - it will be in error state only as a result of a failed management operation. There is no indication as to whether or not a backend or volume is "healthy" - i.e., the data exists and is accessible.</span><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The basic idea would be to add a "health" property for both backends and volumes.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">For backends, this may be something like:</div><div style="font-size:12.8px">- "healthy"</div><div style="font-size:12.8px">- "warning" (something is wrong and the admin should check the storage)</div><div style="font-size:12.8px">- "management unavailable" (there is no management connectivity)</div><div style="font-size:12.8px">- "data unavailable" (there is no data path connectivity)<br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">For volumes:</div><div style="font-size:12.8px">- "healthy"</div><div style="font-size:12.8px">- "degraded" (i.e., not at full redundancy)</div><div style="font-size:12.8px">- "error" (in case of a data loss event)</div><div style="font-size:12.8px"><div>- "management unavailable" (there is no management connectivity)</div><div>- "data unavailable" (there is no data path connectivity)</div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Before I start working on a spec, I wanted to get some feedback, especially from driver owners:</div><div style="font-size:12.8px">1. What useful information can you provide at the backend level?</div><div style="font-size:12.8px">2. And at the volume level?</div><div style="font-size:12.8px">3. How would you obtain this information? Querying the storage (poll)? Registering for events? Something else?</div><div style="font-size:12.8px">4. Other feedback?</div><div><br></div><div>Thank you,</div><div>Avishay</div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><b style="font-size:12.7273px"><font color="#666666">Avishay Traeger, PhD</font></b><br></div><div><font color="#666666"><i>System Architect</i></font></div><div><span style="color:rgb(102,102,102);font-size:12.7273px"><br></span></div><div><span style="color:rgb(102,102,102)">Mobile:</span><span style="color:rgb(102,102,102)"> </span><a value="+972524317955" style="color:rgb(17,85,204)">+972 54 447 1475</a><br></div><div><font color="#666666">E-mail: <a href="mailto:avishay@stratoscale.com" style="color:rgb(17,85,204)" target="_blank">avishay@stratoscale.<wbr>com</a></font></div><div><font color="#666666"><br></font></div><div><img src="http://www.stratoscale.com/wp-content/uploads/Logo-Signature-Stratoscale-230.jpg"><br></div><div><font color="#666666"><br></font></div><div><p style="margin:0in"><a href="http://www.stratoscale.com/" style="color:rgb(17,85,204)" target="_blank"><span style="font-family:arial;font-size:9.75pt">Web</span></a><span style="font-family:arial;font-size:9.75pt"> | </span><a href="http://www.stratoscale.com/blog/" style="color:rgb(17,85,204)" target="_blank"><span style="font-family:arial;font-size:9.75pt">Blog</span></a><span style="font-family:arial;font-size:9.75pt;color:rgb(108,163,214)"> | </span><a href="https://twitter.com/Stratoscale" style="color:rgb(17,85,204)" target="_blank"><span style="font-family:arial;font-size:9.75pt">Twitter</span></a><span style="font-family:arial;font-size:9.75pt;color:rgb(108,163,214)"> | <a href="https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts" style="color:rgb(17,85,204)" target="_blank">Google+</a><wbr> | </span><span style="font-family:arial;font-size:9.75pt"><a href="https://www.linkedin.com/company/stratoscale" style="color:rgb(17,85,204)" target="_blank">Linkedin</a></span></p></div></div></div></div></div></div></div></div></div>
</font></span></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><div class="gmail_default" style="font-family:monospace,monospace">I'd like to get a more detailed use case and example of a problem you want to solve with this. I have a number of concerns including those I raised in your "list manageable volumes" proposal. Most importantly there's really no clear definition of what these fields mean and how they should be interpreted. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">For backends, I'm not sure what you want to solve that can't be handled already by the scheduler and report-capabilities periodic job? You can already report back from your backend to the scheduler that you shouldn't be used for any scheduling activities going forward. More detailed info than that might be useful, but I'm not sure it wouldn't fall into an already existing OpenStack monitoring project like Monasca? </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">As far as volumes, I personally don't think volumes should have more than a few states. They're either "ok" and available for an operation or they're not. The list you have seems ok to me, but I don't see a ton of value in fault prediction or going to great lengths to avoid something failing. The current model we have of a volume being "ok" until it's "not" seems perfectly reasonable to me. Typically my experience is that trying to be clever and polling/monitoring to try and preemptively change the status of a volume does little more than result in complexity, confusion and false status changes of resources. I'm pretty strongly opposed to having a level of granularity of the volume here. At least for now, I'd rather see what you have in mind for the backend and nail that down to something that's solid and basically bullet proof before trying to tackle thousands of volumes which have transient states. And of course the biggest question I have still "what problem" you hope to solve here? </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks,</div><div class="gmail_default" style="font-family:monospace,monospace">John</div><br></div></div>