cTentacleAgent Server Url

Hi, hoping someone can help or point me in the right direction.

I have an issue with OctopusDSC when running from Azure Automation, specifically the cTentacleAgent resource.

For context, we have a VM hosting Octopus sitting behind an Application Gateway and we also power down this VM during our off hours for cost saving.

This leads me to our issue. Whenever the server is shut down, a 502 is thrown from the Application Gateway. This then causes cTentacleAgent on other servers to throw a “non-terminating” error and causes the whole DSC compliance check to fail. See pictures 1 & 2

My question is, is there a way around this behaviour from the cTentacleAgent resource? It’s not really a problem as far as cTentacleAgent goes, however it causes me to not be able to see the compliance of any other resources I have running against the node.

Preferred behaviour would be to have the resource mark the node as non-compliant.


Hi Dane,

Thanks for getting in touch! Our team had a discussion about your issue and I think we may need to clarify some points to get a better idea around what exactly is going wrong here.

You note that you encounter this issue when your server shuts down. Just to clarify, you’re referring to your Octopus server shutting down?

I’m continuing to investigate and discuss this with the developers.

Looking forward to hearing from you.

Best regards,
Daniel

Hi Daniel,

Apologies for the ambiguity.

That is correct, the issue occurs whenever the Octopus Server is shut down.

Also, for clarification, the 502 is an expected status code when the sever is shut down due to our Application Gateway configuration.

Hi Dane,

Sorry for the delay in getting back to you here. I had a discussion with the team and we looked into options here. Would you be able to confirm what you currently have the -ErrorAction parameter set to on the Test-TargetResource inside your cTentacleAgent.psm1? If this is set to Stop it could explain why things are stopping on non-terminating errors.

An alternative option for handling this would be to modify the cTentacleAgent.psm1 file to include a try/catch when connecting to the Octopus server. You could pick up 502 errors and just ignore them by default.

If you are still stuck here or find the above advice doesn’t help, please let me know.

Best regards,
Daniel

Hi Daniel,

Thanks for getting back to me.

This isn’t really a workaround that I can implement for the following reasons:

  • I’m using the OctopusDSC module as created and maintained by Octopus Deploy
  • The module is imported directly from the PS Gallery
  • It is imported into an Azure Automation account

Due to this process being automated within my infrastructure, I would need to host my own copy of the OctopusDSC module with it manually edited. This is not feasible for our use case.

However, I am currently testing a workaround whereby I have wrapped my DSC config in a try catch.

try {
    ## Configure Octopus Tentacle
    cTentacleAgent TentacleAgent {
        Name                        = "Tentacle"
        ApiKey                      = $ApiKey
        OctopusServerUrl            = $ServerUri
        OctopusServerThumbprint     = $ServerThumbprint
        DefaultApplicationDirectory = (Join-Path -Path $OctopusDirectory -ChildPath $ApplicationDirectory)
        ListenPort                  = $ListenPort
        Environments                = $Environments
        Roles                       = $Roles
        Space                       = $Space
        RegisterWithServer          = $RegisterWithServer
        State                       = "Started"
    }
}
catch {
    Write-Warning "Unable to validate TentacleAgent configuration: $( $Error[0].Exception.Message )"
}

Not sure if this will work but will test it regardless.

I still believe that the better solution would be for the DSC module to either have that exception handling or report the node as non-compliant on server error instead of just breaking.

FYI this has not resolved the issue:

The PowerShell DSC resource ‘[cTentacleAgent]TentacleAgent::[OctopusTentacleConfiguration]TentacleConfig’ with SourceInfo ‘C:\Modules\User\OctopusTentacleConfigurationDSC\1.0\DSCResources\OctopusTentacleConfiguration\OctopusTentacleConfiguration.schema.psm1::86::13::cTentacleAgent’ threw one or more non-terminating errors while running the Test-TargetResource functionality. These errors are logged to the ETW channel called Microsoft-Windows-DSC/Operational. Refer to this channel for more details.

Hi Dane,

Just a heads up that we’re still looking into this. I’m doing some testing on my end to see if there is a good option available for you.

I’m also looking into options that the developers may be able to implement to avoid this sort of thing happening. However, this is a unique edge case which we’ve not encountered before. I apologize for the delay in providing a sufficient resolution.

Let me know if you have any further questions or thoughts on this issue.

Best regards,
Daniel

Thanks for the update Daniel, appreciated.

Hi @Daniel_Fischer, is there any update on this one yet?

Hi Dane,

I’m sorry for the delay in getting back to you here. I spent some time attempting a reproduction of this issue in Azure and did some testing. I then followed up with our developers working on the Octopus DSC resource, and unfortunately it looks like we don’t have any good options readily available to help you resolve this.

The main suggestion was to not shut down the Octopus server, but this is obviously very dependent on your environment and perhaps not in your control. The other option was as I mentioned earlier to host your own copy of the DSC resource and modify it yourself. Though you mentioned this was not possible.

I think this leaves us with the final option for you to raise an issue on the OctopusDSC repo to request this is changed. However, the priority of this issue will be low and I can’t provide a guarantee that it will be addressed any time soon.

I know this isn’t exactly a helpful solution to your issue but I don’t think there is too much more we can do past this. Azure automatically executes the commands which perform the Test/Set-TargetResource which makes it difficult to catch and stop this from happening.

If you have any questions or thoughts at all on this, please don’t hesitate to let me know.

Best regards,
Daniel

Hi Daniel,

Thanks for getting back to me.

I will raise the issue in the GitHub repo as suggested. Appreciate the support you’ve given me.

Feel free to close this one.

Regards,

Dane.