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?! -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? Br, Tomi > -----Original Message----- > From: EXT Qiming Teng [mailto:[email protected]] > Sent: Friday, April 08, 2016 2:38 PM > To: OpenStack Development Mailing List (not for usage questions) > <[email protected]> > 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:[email protected]] > > > 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- > > > [email protected]?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev- > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
