Commit cc70e3a breaks administrative disablement of a host.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
New
|
Undecided
|
Unassigned |
Bug Description
The commit in question is cc70e3a28df3c84
The change id: Ib8d67838ceb73c
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.
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.