Open Stack

Hi Tomi,

Juvonen, Tomi (Nokia - FI/Espoo) <tomi.juvonen at nokia.com> 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.