Open Stack

Hi,

> -----Original Message-----
> From: EXT Balázs Gibizer [mailto:balazs.gibizer at ericsson.com]
> Sent: Tuesday, April 12, 2016 10:14 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance
> 
> > -----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.

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: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
> 
> __________________________________________________________________________
> 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