Commit cc70e3a breaks administrative disablement of a host.

[jan grant]

The commit in question is cc70e3a28df3c8492769b305d248bb4d9bf32830
The change id: Ib8d67838ceb73c5b1cdc9498c17b335e9e5bb6f3
Bug related to this originally: 1240670

This fix is a good idea; however, it's severely impacted upon the use of host disablement for administrative (and troubleshooting) tasks.

As it is now, any restart of nova-compute on a disabled host, and/or the restart of libvirt, can trigger a host being either disabled, or re-enabled.

This is often not what is wanted, either from an operational standpoint, or a development one. I'd like to be able to isolate a host to continue debugging libvirt problems and know that nova-compute won't re-enable it until I ask it to.

Having said that, the automatic disable/re-enable seems like a good idea, too.

Perhaps the best approach here is to have two flags: an administrative one that's only set/cleared "manually" via the API, and a second one that nova-compute can trigger by itself. Both flags would have to be "enabled" in order for a host to be considered for scheduling.

[Andrea Rosa (andrea-rosa-m)]

Hi Jan

maybe just a single flag is enough something like "enable_on_restart" , the re-enable process should check this value before deciding to automatically re-enable the service.

[Andrea Rosa (andrea-rosa-m)]

one more thing: I'd leave that flag False by default, that allows to deploy the feature in the original commit "cc70e3a28df3c8492769b305d248bb4d9bf32830" without breaking the existing "host disable" feature.

[jan grant (jan-grant)]

I did consider suggesting an "enable_on_restart" or something similar. The problem is that an update to libvirt might cause libvirtd to be restarted; we might want nova-compute to temporarily disable itself (if it notices this) but we don't necessarily want it to remain disabled in the case of actions like a standard deployment.