Currently, when a customer does a managed switch over (via the Console or CLI), drift detection will report that their GlobalCluster resource is now out of sync. This is because the GlobalCluster CFN resource thinks the SourceDBClusterIdentifier value is the cluster member from describe-global-clusters with the isWriter attribute=true.
My customer believes this property should be ignored when determining drift.
Expected Behavior
The customer feels that we should ignore the SourceDBClusterIdentifier property when calculating drift. This would allow them to do managed switchover without the GlobalCluster resource being marked as in drift.
If at a later date, we enable the GlobalCluster CFN resource to be used to initiate managed switchover, then it would make sense to re-add this property to drift detection. But until we do that, my customer feels that the logic should assume that the decision to switchover outside of CFN was made on purpose and should not mark the GlobalCluster resource as drifted.
Observed Behavior
Post managed switchover, the GlobalCluster resource will be marked as in drift:
Create a GlobalCluster configuration using CFN with a primary cluster in region1 and secondary cluster in region2.
Use the Console/CLI to do a managed switchover.
Run drift detection on the stack that contains the GlobalCluster resource.
Name of the resource
AWS::RDS::GlobalCluster
Resource Name
No response
Issue Description
Currently, when a customer does a managed switch over (via the Console or CLI), drift detection will report that their GlobalCluster resource is now out of sync. This is because the GlobalCluster CFN resource thinks the SourceDBClusterIdentifier value is the cluster member from describe-global-clusters with the isWriter attribute=true.
My customer believes this property should be ignored when determining drift.
Expected Behavior
The customer feels that we should ignore the SourceDBClusterIdentifier property when calculating drift. This would allow them to do managed switchover without the GlobalCluster resource being marked as in drift.
If at a later date, we enable the GlobalCluster CFN resource to be used to initiate managed switchover, then it would make sense to re-add this property to drift detection. But until we do that, my customer feels that the logic should assume that the decision to switchover outside of CFN was made on purpose and should not mark the GlobalCluster resource as drifted.
Observed Behavior
Post managed switchover, the GlobalCluster resource will be marked as in drift:
Test Cases
Create a GlobalCluster configuration using CFN with a primary cluster in region1 and secondary cluster in region2.
Use the Console/CLI to do a managed switchover. Run drift detection on the stack that contains the GlobalCluster resource.
Other Details
No response