Yes, it would be great if we can have a simple framework for future run time policy plugins. ;-)
2014-03-03 23:12 GMT+08:00 laserjetyang <[email protected]>: > 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. > > > On Mon, Mar 3, 2014 at 10:30 PM, Andrew Laski > <[email protected]>wrote: > >> On 03/01/14 at 07:24am, Jay Lau wrote: >> >>> Hey, >>> >>> Sorry to bring this up again. There are also some discussions here: >>> http://markmail.org/message/5zotly4qktaf34ei >>> >>> You can also search [Runtime Policy] in your email list. >>> >>> Not sure if we can put this to Gantt and enable Gantt provide both >>> initial >>> placement and rum time polices like HA, load balance etc. >>> >> >> 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. >> >> >> >> >> >>> Thanks, >>> >>> Jay >>> >>> >>> >>> 2014-02-21 21:31 GMT+08:00 Russell Bryant <[email protected]>: >>> >>> On 02/20/2014 06:04 PM, Sean Dague wrote: >>>> > On 02/20/2014 05:32 PM, Russell Bryant wrote: >>>> >> On 02/20/2014 05:05 PM, Costantino, Leandro I wrote: >>>> >>> Hi, >>>> >>> >>>> >>> Would like to know if there's any interest on having >>>> >>> 'automatic evacuation' feature when a compute node goes down. I >>>> >>> found 3 bps related to this topic: [1] Adding a periodic task >>>> >>> and using ServiceGroup API for compute-node status [2] Using >>>> >>> ceilometer to trigger the evacuate api. [3] Include some kind >>>> >>> of H/A plugin by using a 'resource optimization service' >>>> >>> >>>> >>> Most of those BP's have comments like 'this logic should not >>>> >>> reside in nova', so that's why i am asking what should be the >>>> >>> best approach to have something like that. >>>> >>> >>>> >>> Should this be ignored, and just rely on external monitoring >>>> >>> tools to trigger the evacuation? There are complex scenarios >>>> >>> that require lot of logic that won't fit into nova nor any >>>> >>> other OS component. (For instance: sometimes it will be faster >>>> >>> to reboot the node or compute-nova than starting the >>>> >>> evacuation, but if it fail X times then trigger an evacuation, >>>> >>> etc ) >>>> >>> >>>> >>> Any thought/comment// about this? >>>> >>> >>>> >>> Regards Leandro >>>> >>> >>>> >>> [1] >>>> >>> >>>> https://blueprints.launchpad.net/nova/+spec/vm-auto-ha-when-host-broken >>>> >>> >>>> >>> >>>> [2] >>>> >>> >>>> https://blueprints.launchpad.net/nova/+spec/evacuate- >>>> instance-automatically >>>> >>> >>>> >>> >>>> [3] >>>> >>> >>>> https://blueprints.launchpad.net/nova/+spec/resource- >>>> optimization-service >>>> >> >>>> >> >>>> >>> >>>> My opinion is that I would like to see this logic done outside of Nova. >>>> > >>>> > Right now Nova is the only service that really understands the >>>> > compute topology of hosts, though it's understanding of liveness is >>>> > really not sufficient to handle this kind of HA thing anyway. >>>> > >>>> > I think that's the real problem to solve. How to provide >>>> > notifications to somewhere outside of Nova on host death. And the >>>> > question is, should Nova be involved in just that part, keeping >>>> > track of node liveness and signaling up for someone else to deal >>>> > with it? Honestly that part I'm more on the fence about. Because >>>> > putting another service in place to just handle that monitoring >>>> > seems overkill. >>>> > >>>> > I 100% agree that all the policy, reacting, logic for this should >>>> > be outside of Nova. Be it Heat or somewhere else. >>>> >>>> I think we agree. I'm very interested in continuing to enhance Nova >>>> to make sure that the thing outside of Nova has all of the APIs it >>>> needs to get the job done. >>>> >>>> -- >>>> Russell Bryant >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> -- >>> Thanks, >>> >>> Jay >>> >> >> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Thanks, Jay
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
