<div dir="ltr">Are there any resources available or proven examples on using external tools which call nova evacuate?<div><br></div><div>For example use a monitoring tool to detect node failure and let the monitoring tool call evacuate on the instances which were running on the failed compute node.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 3, 2014 at 11:28 PM, Jay Lau <span dir="ltr"><<a href="mailto:jay.lau.513@gmail.com" target="_blank">jay.lau.513@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"><br><div class="gmail_extra">Yes, it would be great if we can have a simple framework for future run time policy plugins. ;-)<br></div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2014-03-03 23:12 GMT+08:00 laserjetyang <span dir="ltr"><<a href="mailto:laserjetyang@gmail.com" target="_blank">laserjetyang@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">there are a lot of rules for HA or LB, so I think it might be a better idea to scope the framework and leave the policy as plugins.<br>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 3, 2014 at 10:30 PM, Andrew Laski <span dir="ltr"><<a href="mailto:andrew.laski@rackspace.com" target="_blank">andrew.laski@rackspace.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 03/01/14 at 07:24am, Jay Lau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey,<br>
<br>
Sorry to bring this up again. There are also some discussions here:<br>
<a href="http://markmail.org/message/5zotly4qktaf34ei" target="_blank">http://markmail.org/message/<u></u>5zotly4qktaf34ei</a><br>
<br>
You can also search [Runtime Policy] in your email list.<br>
<br>
Not sure if we can put this to Gantt and enable Gantt provide both initial<br>
placement and rum time polices like HA, load balance etc.<br>
</blockquote>
<br></div>
I don't have an opinion at the moment as to whether or not this sort of functionality belongs in Gantt, but there's still a long way to go just to get the scheduling functionality we want out of Gantt and I would like to see the focus stay on that.<div>

<div><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
Jay<br>
<br>
<br>
<br>
2014-02-21 21:31 GMT+08:00 Russell Bryant <<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 02/20/2014 06:04 PM, Sean Dague wrote:<br>
> On 02/20/2014 05:32 PM, Russell Bryant wrote:<br>
>> On 02/20/2014 05:05 PM, Costantino, Leandro I wrote:<br>
>>> Hi,<br>
>>><br>
>>> Would like to know if there's any interest on having<br>
>>> 'automatic evacuation' feature when a compute node goes down. I<br>
>>> found 3 bps related to this topic: [1] Adding a periodic task<br>
>>> and using ServiceGroup API for compute-node status [2] Using<br>
>>> ceilometer to trigger the evacuate api. [3] Include some kind<br>
>>> of H/A plugin  by using a 'resource optimization service'<br>
>>><br>
>>> Most of those BP's have comments like 'this logic should not<br>
>>> reside in nova', so that's why i am asking what should be the<br>
>>> best approach to have something like that.<br>
>>><br>
>>> Should this be ignored, and just rely on external monitoring<br>
>>> tools to trigger the evacuation? There are complex scenarios<br>
>>> that require lot of logic that won't fit into nova nor any<br>
>>> other OS component. (For instance: sometimes it will be faster<br>
>>> to reboot the node or compute-nova than starting the<br>
>>> evacuation, but if it fail X times then trigger an evacuation,<br>
>>> etc )<br>
>>><br>
>>> Any thought/comment// about this?<br>
>>><br>
>>> Regards Leandro<br>
>>><br>
>>> [1]<br>
>>><br>
<a href="https://blueprints.launchpad.net/nova/+spec/vm-auto-ha-when-host-broken" target="_blank">https://blueprints.launchpad.<u></u>net/nova/+spec/vm-auto-ha-<u></u>when-host-broken</a><br>
>>><br>
>>><br>
[2]<br>
>>><br>
<a href="https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically" target="_blank">https://blueprints.launchpad.<u></u>net/nova/+spec/evacuate-<u></u>instance-automatically</a><br>
>>><br>
>>><br>
[3]<br>
>>><br>
<a href="https://blueprints.launchpad.net/nova/+spec/resource-optimization-service" target="_blank">https://blueprints.launchpad.<u></u>net/nova/+spec/resource-<u></u>optimization-service</a><br>
>><br>
>><br>
>>><br>
My opinion is that I would like to see this logic done outside of Nova.<br>
><br>
> Right now Nova is the only service that really understands the<br>
> compute topology of hosts, though it's understanding of liveness is<br>
> really not sufficient to handle this kind of HA thing anyway.<br>
><br>
> I think that's the real problem to solve. How to provide<br>
> notifications to somewhere outside of Nova on host death. And the<br>
> question is, should Nova be involved in just that part, keeping<br>
> track of node liveness and signaling up for someone else to deal<br>
> with it? Honestly that part I'm more on the fence about. Because<br>
> putting another service in place to just handle that monitoring<br>
> seems overkill.<br>
><br>
> I 100% agree that all the policy, reacting, logic for this should<br>
> be outside of Nova. Be it Heat or somewhere else.<br>
<br>
I think we agree.  I'm very interested in continuing to enhance Nova<br>
to make sure that the thing outside of Nova has all of the APIs it<br>
needs to get the job done.<br>
<br>
--<br>
Russell Bryant<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
<br>
<br>
-- <br>
Thanks,<br>
<br>
Jay<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Thanks,<br><br></div>Jay<br></div>
</div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>