search

dsccommunity / FailoverClusterDsc

This module contains DSC resources for deployment and configuration of Windows Server Failover Cluster.
MIT License
60 stars 54 forks source link

ClusterPreferredOwner: Is the behavior of parameter Ensure correct? #102

Open johlju opened 7 years ago

johlju commented 7 years ago

Details of the scenario you tried and the problem that is occurring: Opening up this issue to discuss the behavior of parameter Ensure in xClusterPreferredOwner

Today: When parameter Ensure is set to 'Present' the nodes assigned to parameter Nodes is set (replaced) as the preferred owners. The user says these owners should always be preferred owners. If someone adds another preferred owner outside of the desired configuration. The configuration will set the preferred owners back to the preferred owners in the configuration.

When parameter Ensure is set to 'Absent' the user says that those owners should never ever be preferred owners to be in desired state. So the resource will get all the currently present preferred owners and then remove only those the user said should be absent, leaving the rest to still be preferred owners. There are currently not a way to say that there should be no preferred owners at all.

Comment from @bgelens in PR #98.

"Personally I would think a resource like this handles only one state. So ensure doesn't make sense to me. Instead I would think the resource would govern the owners specified in the configuration and would purge anything else instead of being additive. The resource is handling desired state a an imperative operation. So to fix a situation, first I have to remove owners, then push another config that would be consistent with my desired state..."

The DSC configuration that is using the resource (as detailed as possible): n/a

Version of the Operating System and PowerShell the DSC Target Node is running: n/a

Version of the DSC module you're using, or 'dev' if you're using current dev branch: Dev

stale[bot] commented 6 years ago

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.