Hi Tomi, Juvonen, Tomi (Nokia - FI/Espoo) <[email protected]> wrote: > I'm working in the OPNFV Doctor project that is about fault > management and maintenance (NFV). The goal of the project is to > build fault management and maintenance framework for high > availability of Network Services on top of virtualized > infrastructure. > > https://wiki.opnfv.org/display/doctor > > Currently there is already landed effort to OpenStack to have > ability to detect failures fast, change states in OpenStack (Nova), > add state information that was missing and also to expose that to > owner of a VM. Also alarm is triggered. By all this one can now rely > the states and get notice about faults in a split second. Surely > with system configured monitor different faults and make actions > based configured policies, or leave some actions for consumers of > the alarms risen.
Sounds very interesting - thanks. Does this really have to be limited to OPNFV though? It sounds like it would be very useful within OpenStack generally. > For maintenance I had a session in Austin to talk with Ops and Nova > core about the maintenance part. There it was seen that Nova didn't > want more specific information about host maintenance (maintenance > state, maintenance window...), so as a result of the discussion > there is a spec that was now transferred to Ocata: > > https://review.openstack.org/310510/ That's great - thanks a lot for highlighting, as it certainly seems to overlap a lot with the functionality which NTT proposed and is now described here: http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html > The spec proposes a link to Nova external tool to provide more > specific information about host (compute) maintenance and by latest > comments it could have any host specific extra information to the > same place (for example you have mentioned event history). Still if > looking this kind of tool, why not make it configurable for anything > convenient for different operator scenario like automatic operations > if so wanted. Yes, that definitely makes sense to me. > Anyhow project like Nova do not want big new functionalities, so all > "more complex flows" should reside somewhere outside. Right. I can certainly understand that desire, but I'm a bit confused why the spec is proposing both extending Nova's API / DB schema *and* adding an external tool. _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
