[openstack-dev] [Nova] RFC Host Maintenance

Balázs Gibizer balazs.gibizer at ericsson.com
Tue Apr 12 07:13:39 UTC 2016


> -----Original Message-----
> From: Juvonen, Tomi (Nokia - FI/Espoo) [mailto:tomi.juvonen at nokia.com]
> Sent: April 11, 2016 09:06
> 
> Hi,
> 
> Looking the discussion so far: 
> -Suggestion to have extended information for maintenance to somewhere
> outside Nova.
> -Notification about Nova state changes.
> 
> So how about if the whole logic of maintenance would be triggered by Nova
> API disable/enable service notification, but otherwise the business logic
> would be outside Nova?!

I think in this scenario the module that holds the business logic outside of
Nova can be used by the admin to trigger the maintenance and one of the
business logic piece would be to set the respective service(s) disabled in
OpenStack. 

> 
> -Extended host information needed by maintenance should be outside of
> Nova (extended information like maintenance window, more precise
> maintenance state and version information) -Extended server information
> needed by maintenance should be outside of Nova (configuration for
> automatic actions in different use cases) -The communicating and action flow
> with server owner and admin should be outside of Nova.
> 
> One thing is now as there is accepted that host fault monitoring is to be
> external, it might be best fit also for some of this maintenance logic.
> Monitoring SW is also the place with the best knowledge about the host
> state and if looking to build any automated actions on fault scenarios, then
> surely maintenance would be close to that also. Monitoring also need to
> know what host is in maintenance. Logic is very similar from server point of
> view when looking server actions and communication with server owner.
> 
> Might this be the way to go?

What impact this solution has on Nova? As far as I see it is very limited if not
zero.  

Cheers,
Gibi

> 
> Br,
> Tomi
> 
> > -----Original Message-----
> > From: EXT Qiming Teng [mailto:tengqim at linux.vnet.ibm.com]
> > Sent: Friday, April 08, 2016 2:38 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > <openstack-dev at lists.openstack.org>
> > Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance
> >
> > On Fri, Apr 08, 2016 at 09:52:31AM +0000, Balázs Gibizer wrote:
> > > > -----Original Message-----
> > > > From: Qiming Teng [mailto:tengqim at linux.vnet.ibm.com]
> > > > Sent: April 07, 2016 15:42
> > > >
> > > > The only gap based on my limited understanding is that nova is not
> > emitting
> > > > events compute host state changes. This knowledge is still kept
> > > > inside
> > nova
> > > > as some service states. If that info is posted to oslo messaging,
> > > > a lot
> > of usage
> > > > scenarios can be enabled and we can avoid too much churns to nova
> > itself.
> > >
> > > Nova does not really know the state of the compute host, it knows
> > > only
> > the state of the nova-compute service running on the compute host. In
> > Mitaka we added notification about the service status[2].
> > > Also there is a proposal about notification about hypervisor info
> > > change
> > [1].
> > >
> > > Cheers,
> > > Gibi
> > >
> > > [1] https://review.openstack.org/#/c/299807/
> > > [2]
> > > http://docs.openstack.org/developer/nova/notifications.html#existing
> > > -
> > versioned-notifications
> > >
> >
> > Thanks for the sharing, Balázs. The mitaka service status notification
> > looks pretty useful, I'll try it.
> >
> > Regards,
> >   Qiming
> >
> > > >
> > > > Regards,
> > > >   Qiming
> > > >
> > > >
> > > >
> __________________________________________________________
> > > > ________________
> > > > OpenStack Development Mailing List (not for usage questions)
> > > > Unsubscribe: OpenStack-dev-
> > > > request at lists.openstack.org?subject:unsubscribe
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> >
> __________________________________________________________
> ____________
> > ____
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-
> > request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> >
> >
> __________________________________________________________
> ____________
> > ____ OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list