Le 14/10/2014 01:46, Adam Lawson a écrit :
/I think Adam is talking about this bp:
https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically/
Correct - yes. Sorry about that. ; )
So it would seem the question is not whether to support auto-evac but
how it should be handled. If not handled by Nova, it gets complicated.
Asking a user to configure a custom Nagios trigger/action... not sure
if we'd recommend that as our definition of ideal.
* I can foresee Congress being used to control whether auto-evac is
required and what other policies come into play by virtue of an
unplanned host removal from service. But that seems like a bit
overkill.
* i can foresee Nova/scheduler being used to perform the evac
itself. Are they still pushing back?
* I can foresee Ceilometer being used to capture service state and
define how long a node should be inaccessible before it's
considered offline. But seems a bit out of scope for what
ceilometer was meant to do.
Well, IMHO Gantt should just enforce policies (possibly defined by
Congress or whatever else) so if a condition is not met (here, HA on a
VM), it should issue a reschedule. That said, Gantt is not responsible
for polling all events and updating its internal view, that's another
project which should send those metrics to it.
I'm not having a preference in between Heat, Ceilometer or whatever else
for notifying Gantt. I even think that whatever the solution would be
(even a Nagios handler), that's Gantt at the end which would trigger the
evacuation by calling Nova to fence that compute node and move the VM to
another host (like rescheduling already does, but in a manual way).
-Sylvain
I'm all about making this super easy to do a simple task though, at
least so the settings are all defined in one place. Nova seems logical
but I'm wondering if there is still resistance.
So curious; how are these higher-level discussions
initiated/facilitated? TC?
I proposed a cross-project session at the Paris Summit about scheduling
and Gantt (yet to be accepted), that usecase could be discussed there.
-Sylvain
*/
Adam Lawson/*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
On Mon, Oct 13, 2014 at 3:21 PM, Russell Bryant <rbry...@redhat.com
<mailto:rbry...@redhat.com>> wrote:
On 10/13/2014 06:18 PM, Jay Lau wrote:
> This is also a use case for Congress, please check use case 3 in the
> following link.
>
>
https://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zrkSw/edit#
Wow, really? That honestly makes me very worried about the scope of
Congress being far too big (so early, and maybe period).
--
Russell Bryant
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
