Role Dependency Collect / Configure Behaviour

[Ryan Miller]

Background:
I had an issue with the collection stage of PSDsc failing if powershell is not at least version 5 on the target machine. I can partially solve this with some custom assets to collect and configure powershell 5 installation via PSEnsure.

I've set up the powershell 5 installation as part of a server role that is a dependency of all other server roles.

Problem:
It seems that for a base role B and a dependent role D, that the order of execution will be

• B (Collect)
• D (Collect)
• B (Configure)
• D (Configure)

but this will not work for me because without B being configured the D collection will fail, which also then blocks the B configuration

Is there some way to abort/defer dependent roles until the base roles are properly configured?

Am I tackling this problem in a reasonable way?

Product: Otter
Version: 1.6.2

[Tod]

When you say D (Collect) is failing, are you saying there's an execution error during the collection phase? If so, that's a bug in the implementation of that particular collection - it should be logging warnings and appear drifted instead of generating an error.

Can you show the error log that is being generated (or submit it as a ticket referencing this post if you don't want it public).

[Alana]

Just as an update to this, we have updated the behavior of how role dependencies work to better support this scenario. Given the original example...

• B (Collect)
• D (Collect)
• B (Configure)
• D (Configure)

The new behavior will be that, if "B" reports drift, then "D" (as a dependent role) will also be considered drifted, and then both B and D will be configured as expected.