Open Stack

I'll work on Daniel's suggestion and will send a patch for review.

Vladik

----- Original Message -----
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Tuesday, 12 November, 2013 5:32:28 AM
> Subject: Re: [openstack-dev] [Nova] Recent change breaks manual control of service enabled / disabled status -
> suggest it is backed out and re-worked
> 
> On Mon, Nov 11, 2013 at 11:34:10AM +0000, Day, Phil wrote:
> > Hi Folks,
> > 
> > I'd like to get some eyes on a bug I just filed:
> > https://bugs.launchpad.net/nova/+bug/1250049
> > 
> > A recent change (https://review.openstack.org/#/c/52189/9 ) introduced the
> > automatic disable / re-enable of nova-compute when connection to libvirt
> > is lost and recovered.   The problem is that it doesn't take any account
> > of the fact that a cloud administrator may have other reasons for
> > disabling a service, and always put nova-compute back into an enabled
> > state.
> > 
> > The impact of this is pretty big for us - at any point in time we have a
> > number of servers disabled for various operational reasons, and there are
> > times when we need to restart libvirt as part of a deployment.  With this
> > change in place all of those hosts are returned to an enabled state, and
> > the reason that they were disabled is lost.
> > 
> > While I like the concept that an error condition like this should disable
> > the host from a scheduling perspective, I think it needs to be implemented
> > as an additional form of disablement (i.e a separate value kept in the
> > ServiceGroup API), not an override of the current one.
> > 
> > I'd like to propose that the current change is reverted as a priority, and
> > a new approach then submitted as a second step that works alongside the
> > current enable /disable reason.
> > 
> > Sorry for not catching this in the review stage - I didn't notice this one
> > at all.
> 
> It seems like it would be pretty easy to just use an explicit
> 'disable_reason'
> string value, and then only automatically re-enable if the string matches the
> one we set when disabling it originally. I think that should be easy enough
> for
> someone to do without needing to revert the entire original change.
> 
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>