Deactivated Hosts Aren't Removed from Core

[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

[Hossy]

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?

[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

[Hossy]

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.

[Hossy]

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?

[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...

[Hossy]

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?

[scottwilkerson]

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.

[Hossy]

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).

[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...