Hi, > -----Original Message----- > From: EXT Balázs Gibizer [mailto:balazs.gibi...@ericsson.com] > Sent: Tuesday, April 12, 2016 10:14 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance > > > -----Original Message----- > > From: Juvonen, Tomi (Nokia - FI/Espoo) [mailto:tomi.juvo...@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.
Yes. > > > > > -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. If the conclusion is really this, then by fast no changes to Nova. > > Cheers, > Gibi > > > > > Br, > > Tomi > > > > > -----Original Message----- > > > From: EXT Qiming Teng [mailto:teng...@linux.vnet.ibm.com] > > > Sent: Friday, April 08, 2016 2:38 PM > > > To: OpenStack Development Mailing List (not for usage questions) > > > <openstack-dev@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:teng...@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- > > > > > requ...@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- > > > requ...@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-requ...@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- > > requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
