Page 2 of 6
Re: Deactivated Hosts Aren't Removed from Core
Posted: Tue Jan 28, 2014 11:16 am
by lmiltchev
You should've done the following:
1. Ran "Verify" to confirm the unchanged config was valid. It was.
2. Deactivated a host that I knew would make the config invalid.
3. Ran "Write" to write the configs to file
4. Ran "Verify" to verify the configuration
4. Activated the host.
5. Ran "Write" to write the configs to file
6. Ran "Verify" to verify the configuration
Re: Deactivated Hosts Aren't Removed from Core
Posted: Tue Jan 28, 2014 11:21 am
by Hossy
lmiltchev wrote:You should've done the following:
1. Ran "Verify" to confirm the unchanged config was valid. It was.
2. Deactivated a host that I knew would make the config invalid.
3. Ran "Write" to write the configs to file
4. Ran "Verify" to verify the configuration
4. Activated the host.
5. Ran "Write" to write the configs to file
6. Ran "Verify" to verify the configuration
I understand what you were saying, but your first step 3 wasn't done. Using your logic, my verify after deactivating the host should've returned valid since the invalid config hadn't been written, but it didn't -- it returned invalid. So, something wrote the config even though I never clicked "Write."
EDIT: ... The confusing part is that the third "Verify" I ran (after re-activating the host) still failed. So, why would the config be written in one case and not another?
Re: Deactivated Hosts Aren't Removed from Core
Posted: Tue Jan 28, 2014 2:17 pm
by scottwilkerson
In reading through this thread, I became aware of the ability to deactivate a host / service by unchecking the "Active" checkbox on the edit page and clicking save.
I added some validation into the CCM to not allow this, as it should check for dependencies before allowing this.
Attached is the CCM component with the changes you can install through Admin -> Manage Components
Re: Deactivated Hosts Aren't Removed from Core
Posted: Tue Jan 28, 2014 2:22 pm
by Hossy
scottwilkerson wrote:In reading through this thread, I became aware of the ability to deactivate a host / service by unchecking the "Active" checkbox on the edit page and clicking save.
I added some validation into the CCM to not allow this, as it should check for dependencies before allowing this.
Attached is the CCM component with the changes you can install through Admin -> Manage Components
That's cool, but I think there's still the problem of CCM "forgetting" that it needs to still delete CFG files if the first attempt at Apply Configuration fails. Can you also write a fix for this?
I was talking to another admin peer and he said that the delete operations CCM attempts to do in the first attempt are not attempted in subsequent attempts, resulting in orphaned CFG files.
Re: Deactivated Hosts Aren't Removed from Core
Posted: Tue Jan 28, 2014 2:26 pm
by Hossy
scottwilkerson wrote:In reading through this thread, I became aware of the ability to deactivate a host / service by unchecking the "Active" checkbox on the edit page and clicking save.
I added some validation into the CCM to not allow this, as it should check for dependencies before allowing this.
Attached is the CCM component with the changes you can install through Admin -> Manage Components
Does this fix also apply to the batch deactivate you can do by checking hosts/services/etc in the list view and using the "With Checked:" drop-down?
Re: Deactivated Hosts Aren't Removed from Core
Posted: Tue Jan 28, 2014 4:23 pm
by lmiltchev
Does this fix also apply to the batch deactivate you can do by checking hosts/services/etc in the list view and using the "With Checked:" drop-down?
This functionality hasn't changed, so this should be fine.
I noticed a small, "cosmetic" bug with this one. If you try to deactivate some hosts, that cannot be deactivated, because of dependencies, you will get the correct messages, for example:
Code: Select all
Item x.x.x.1 cannot be disabled because it has dependent relationships
Item x.x.x.2 cannot be disabled because it has dependent relationships
Item x.x.x.3 cannot be disabled because it has dependent relationships
Close
but it will be shown on the blue background color, instead of red...
Re: Deactivated Hosts Aren't Removed from Core
Posted: Tue Jan 28, 2014 5:40 pm
by Hossy
Hossy wrote:That's cool, but I think there's still the problem of CCM "forgetting" that it needs to still delete CFG files if the first attempt at Apply Configuration fails. Can you also write a fix for this?
I was talking to another admin peer and he said that the delete operations CCM attempts to do in the first attempt are not attempted in subsequent attempts, resulting in orphaned CFG files.
What about this fix?
Re: Deactivated Hosts Aren't Removed from Core
Posted: Wed Jan 29, 2014 8:51 am
by scottwilkerson
Hossy wrote:
That's cool, but I think there's still the problem of CCM "forgetting" that it needs to still delete CFG files if the first attempt at Apply Configuration fails. Can you also write a fix for this?
This will not likely be changed because the whole goal of the automated snapshot reverting to the last know good running configuration would be negated. Leaving you with a monitoring engine that cannot start, and monitoring would cease.
Re: Deactivated Hosts Aren't Removed from Core
Posted: Wed Jan 29, 2014 9:10 am
by Hossy
scottwilkerson wrote:Hossy wrote:
That's cool, but I think there's still the problem of CCM "forgetting" that it needs to still delete CFG files if the first attempt at Apply Configuration fails. Can you also write a fix for this?
This will not likely be changed because the whole goal of the automated snapshot reverting to the last know good running configuration would be negated. Leaving you with a monitoring engine that cannot start, and monitoring would cease.
I don't think you're following what I'm saying. I don't want to change the automated snapshot reverting, I'm asking that you fix the inconsistency caused by it: the inconsistency between the database and the config files.
Here's what happens:
1. Deactivate a host (and possibly another type of change) that causes the "Verify" step to fail.
2. Apply Configuration (this fails).
3. CCM reverts the config files to their previous state, but leaves the database settings unchanged.
4. User fixes the error.
5. Apply Configuration (this succeeds this time).
At step 5, the deletes of the host CFG files that would've occurred in step 2 if step 2 succeeded never occur. The CFG files now become orphans and require manual cleanup.
Whatever mechanism generates the delete commands for the CFG files in step 2, should either 1) continue to generate those delete commands until a successful Apply Configuration happens so that the commands are issued in step 5 or 2) not remove those commands from the "to do" list until a successful Apply Configuration happens. Either way, upon failure, the automated snapshot reverting will keep the original config and to-be-deleted CFG files in place until a successful Apply Configuration happens. (I don't know how the automated snapshot reverting works -- either making a temp copy of the config or rebuilding the config files from a previous DB revision/state).
Re: Deactivated Hosts Aren't Removed from Core
Posted: Wed Jan 29, 2014 9:26 am
by scottwilkerson
Now I understand what you are saying.
I will add this to our internal TODO, I believe I know how we can accomplish it, but it will be a major change that will require significant testing...