Proper use of try catch in configuration plans

[vaclav.nadrasky_0945]

Hello.
I'm struggling to properly send a notification in case something bad happens in a configuration job. Example of a simple configuration plan that simulates this:

##AH:UseTextMode

try
{
    Ensure-File C:\Temp\ensure.txt
    (
        Text: This is just a simple ensure action.
    );

    Start-Service missing_service
    (
        FailIfServiceDoesNotExist: true
    );
}
catch
{
    Post-Http $webookUrl
    (
        ContentType: application/json, TextData: '{"text": "Failure"}'
    );
}

Message is never send. I assume it is because a configuration drift occurred in a "try" block so no other blocks are executed. I am able to resolve this issue by placing the post action inside a block with an execution policy set to always:

##AH:UseTextMode

try
{
    Ensure-File C:\Temp\ensure.txt
    (
        Text: This is just a simple ensure action.
    );

    Start-Service missing_service
    (
        FailIfServiceDoesNotExist: true
    );
}
catch
{
    # CachAlwaysBlock
    with executionPolicy=always
    {   
        Post-Http $webookUrl
        (
            ContentType: application/json, TextData: '{"text": "Message B"}'
        );
    }
}

It works. But the problem now is that when I switch plan to a visual editor and than back to the text mode again the whole "with" statement disappear. So it's very dangerous to use it.

Maybe I got it all wrong and there is a better way how to automatically inform my team that something bad had happened. But if such a mechanism exists in Otter, I'm no aware of it.

Is "with executionPolicy=always" a bad idea to use and there is a better way of handling failures, or is it the only way?

[rhessinger]

Hi @vaclav-nadrasky_0945,

It looks like there is a bug in the visual editor that is stripping that off. I have created a ticket, OT-382, to track the fix. As for if this is the best practice, I'm going to pass you over to @atripp for that. She is our Otter Script expert.

Thanks,
Rich

[atripp]

Hello, the configuration plans can do a ton of great things, but they're a bit confusing -- and a big thing we want to be improving in the next year, with both software and documentation changes.

But I'll explain a couple things you might already know, for the sake of helping someone who might read this in future. Using your first script (without the execution policy):

• The OtterScript is executed twice in a row; first in "Collect" mode then "Ensure" mode if it
• Ensure-File always executes in Collect (and it records whether the file exists), and it may execute in the "Ensure" run (where it would create/overwrite) if it reported drift
• Start-Service never executes in Collect, but may run in "Ensure" mode... but may executes if another operation in the block reported drift (i.e. if Ensure-File reported drift)
• Post-Http never executes in Collect mode, and it never executes or Ensure modes, because it's the only statement in a block

The with executionPolicy=always policy changes this, and it's the intended use of this execution directive. But... it's an editor bug, so we'll fix it.

So... all that said... I don't think I'd recommend doing an error handling in a Configuration plan like this; it feels more appropriate for an Orchestration plan that you run for a purpose, to like provision or set-up a server.

Otter will perform a routine configuration scan at least every hour, so there's a good chance this will just end up sending the same error message over and over:

1. Drift is a detected
2. Configuration FAILS to change
3. Error notice is sent

This isn't all that helpful, and is more of an indication of an outage more than anything else. And this isn't a great way to detect an outage. Instead, you can check the status of the server; if there is a failure during a Configuration execution, the server status becomes Error, and it can then be investigated about the details.