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