<div dir="ltr"><div style>(Just a warning, my primary area of research is large scale system resource management, so i have a tendency to descend into scheduling wonkery at the drop of a hat ;)</div><div><br></div>Metadata annotations are a great start, but I think that we need to move the data somewhere else in the long run. We want to be able to push decision making into nova eventually. For example, our existing implementation only provides manual load-shedding; eventually, it would be good if nova itself could decide when to initiate load-shedding -- in response to new submissions for example. This is probably the simplest algorithm you'd want to build with this mechanism.<div>
<br></div><div>The main issue with using metadata annotations is that they are basically the wild west. We'll need a controlled vocabulary for the annotations, and you'd really want to be able to validate them, and assert defaults, etc. If we want to be able to make decisions from core components, i'd be a lot more comfortable if the information was always there, as opposed to being some sort of sparse, optional annotation. </div>
<div><br></div><div>The metadata namespace is also user mutable. If you wanted to drive variable pricing from this information, the system instantly becomes easily gamed. Ideally, most of these would be sticky assertions, where some aspects were immutable, or perhaps state changes were tracked.</div>
<div><br></div><div>The major reason that we implemented this on top of metadata to start with is that it was a simple place to prototype. We also expect to need to evolve the model in response to user feedback, and so the current wild-westy-ness of the implementation is a plus for the moment.<br>
<div style> -nld</div><div style><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 16, 2013 at 7:44 PM, Jonathan Proulx <span dir="ltr"><<a href="mailto:jon@jonproulx.com" target="_blank">jon@jonproulx.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><div>Poncho leads in a very interesting direction. Among other things I've been wanting a way to have "nice" instances that could use space capacity but be suspended or deleted when the capacity was needed by higher priority instances. <br>
<br></div>Though curious why existing metadata implementation is insufficient for annotation?<br><br></div>-Jon</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 16, 2013 at 6:50 PM, Narayan Desai <span dir="ltr"><<a href="mailto:narayan.desai@gmail.com" target="_blank">narayan.desai@gmail.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">We've pushed an updated license in.<div> -nld</div></div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, May 16, 2013 at 5:36 PM, Narayan Desai <span dir="ltr"><<a href="mailto:narayan.desai@gmail.com" target="_blank">narayan.desai@gmail.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">In the rush to get the code posted concurrently with the paper submission, we missed this. It should be BSD licensed; that is our legal department's license of choice. Other licenses are possible, just not quickly ;)<div>
<br></div><div>Our main intent here is to get the code and ideas out, so the licensing was a complete oversight.<br><div> -nld</div></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, May 16, 2013 at 5:00 PM, Jeremy Hanmer <span dir="ltr"><<a href="mailto:jeremy.hanmer@dreamhost.com" target="_blank">jeremy.hanmer@dreamhost.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">Any chance the license could get updated to something that would encourage contributions?</div><div>
<div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 16, 2013 at 2:16 PM, Tim Bell <span dir="ltr"><<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="EN-GB"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Poncho would be my nomination for best project name, although Ironic deserves a special award also..<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Looks very interesting …<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Tim<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"" lang="EN-US">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"" lang="EN-US"> Narayan Desai [mailto:<a href="mailto:narayan.desai@gmail.com" target="_blank">narayan.desai@gmail.com</a>] <br>
<b>Sent:</b> 16 May 2013 22:52<br><b>To:</b> Tim Bell<br><b>Cc:</b> <a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>; Scott Devoid; Lorin Hochstein<br><b>Subject:</b> Re: [Openstack-operators] Graceful VM shutdown<u></u><u></u></span></p>
</div></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">We (Scott Devoid, Lorin Hochstein, and myself) have built something to help with this class of problem, and submitted a paper to LISA about it. The paper is still under review, but the code is already up on github. We'd love feedback on the code or approach. <u></u><u></u></p>
<div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Our basic goal here was to start working with a user-annotated approach for load-shedding, which will open the door to a bunch of really interesting resource management techniques and reducing the impact of basic system operations tasks.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The code is called poncho (since we needed it to deal with our "full cloud" ;) and is available here:<u></u><u></u></p></div><div>
<p class="MsoNormal"><a href="https://github.com/magellancloud/poncho" target="_blank">https://github.com/magellancloud/poncho</a><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">
It is definitely still under development, but we hope that it will prove out the concepts before we try to build a version that would be suitable for integration into openstack.<u></u><u></u></p></div><div><p class="MsoNormal">
<u></u> <u></u></p></div><div><p class="MsoNormal">I've attached a preprint of the paper to this mail.<u></u><u></u></p></div><div><p class="MsoNormal"> -nld<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><div><p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p><div><div><p class="MsoNormal">On Thu, May 16, 2013 at 1:02 PM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>> wrote:<u></u><u></u></p>
</div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><div><div><div><div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">
I am interested to see how other service providers handle the cases where there is a need to reboot a hypervisor but it is planned (such as a reboot after OS patching).<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">We do not want to do live or block migration for these cases as there is no shared storage and block migration can be a bit unreliable at times.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">In my ideal case, we would be able to warn the VMs in some way so they can do a reasonable job of shutting down. In some cases, our users would like many minutes of notice to complete their current transaction.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Does anyone know of a standard mechanism for hypervisor communicating to the guest to warn of an impending shutdown ?<u></u><u></u></p><p class="MsoNormal"><span style="color:#888888"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#888888">Tim<u></u><u></u></span></p><p class="MsoNormal"><span style="color:#888888"> <u></u><u></u></span></p></div></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt">
<br></p><div>_______________________________________________<br>OpenStack-operators mailing list<br><a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><u></u><u></u></div><p></p></blockquote></div><p class="MsoNormal">
<u></u> <u></u></p></div></div></div></div><br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>