Thank you very much from the interest. Need to look over other discussion and perhaps have a session in Barcelona to look the way forward after change in Nova. > -----Original Message----- > From: Adam Spiers [mailto:aspi...@suse.com] > Sent: Monday, June 20, 2016 4:43 PM > To: Juvonen, Tomi (Nokia - FI/Espoo) <tomi.juvo...@nokia.com> > Cc: openstack-operators mailing list <openstack- > operat...@lists.openstack.org> > Subject: Re: [Openstack-operators] [HA] RFC: user story including > hypervisor reservation / host maintenance / storage AZs / event history > (fwd) > > Hi Tomi, > > Juvonen, Tomi (Nokia - FI/Espoo) <tomi.juvo...@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. Surely not just for OPNFV, but for all operators. If playing with the idea of having link to some external tool to have more than "host_maintenance_reason", like it now would seem some more generic "host_details", where one could have external REST API to call to have any wanted host specific details that one would like to expose also to tenant/owner of server. If having that tool it could also have maintenance or host failure specific scenarios implemented. Could have admin to do things manually, or configure tool VNF / instance specifically to do some actions.. OPNFV use case here is just the more specific maintenance state to begin with, but who knows what one might want to implement there at the end. Auto evacuate... ? That is anyhow far in next steps as of complex to build. It is even case specific, what to do in different scenarios: - Manually do any action by admin. - Automatically move VM (maybe not if problem with bigger scale) - Let it stay on host over maintenance (not busy hour for service) - Let VM owner remove/add VM (to host already gone through maintenance) ... > > > 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
Thanks, need to familiarize into this as well as other requests in the field. > > > 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. I understand this point as just the text field is also usable. External tool is kind of out of scope of the spec. Anyhow would mention it to have the understanding that the aim is to build more functionality in the future into OpenStack and not to limit to what single string can offer. Br, Tomi _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
