it seems that aws.rds.Cluster and aws.rds.ClusterInstance require that engineVersion is set (and set to the same value) when creating an Aurora DB cluster. but when it comes time to upgrade to a new version of aurora, if you set the new version on both the Cluster and the ClusterInstance, pulumi up will fail. But if you only change the version on the Cluster (and leave the Cluster Instance on the older version) the upgrade will happen correctly. Subsequent updates will still succeed even though in the pulumi code the versions are now miss matched. This behavior seems odd, so I was wondering if their was an explanation.
09/20/2019, 8:14 PM
Honestly not an expert on what version upgrade paths Aurora supports and allows, and how those map across cluster and instance versions.
Is there a particular upgrade path you expected was supported from reading AWS docs which Pulumi did not allow you to accomplish?
Or something Pulumi allowed that you to deploy successfully but did not actually work?
09/20/2019, 8:24 PM
for example moving from 5.7.mysql_aurora.2.04.4 to 5.7.mysql_aurora.2.04.5 is supported by AWS. on AWS this change is made on the cluster level, and trickles down to the instances. In pulumi, I must specify the engine version on the Cluster and ClusterInstances, and they must match during initial creation or the creation will fail. At this point, my typescript has 5.7.mysql_aurora.2.04.4 for both the Cluster and ClusterInstance. But if I want to upgrade, changing both to 5.7.mysql_aurora.2.04.5 will fail. I must only modify the Cluster version (which will trickle down to the Cluster Instance). This works, but then my type script has the cluster at 5.7.mysql_aurora.2.04.5 and the cluster instance at 5.7.mysql_aurora.2.04.4 (which is incorrect as it has been upgraded by way of the cluster). On subsequent updates “pulumi up” still succeeds even though the ClusterInstance version is mismatched with what exists on AWS. It just seemed confusing to me, I know how to make it work now but wanted to know if I was doing something wrong or if this whats expected.
What would make more sense to me is if the engineVersion was only required on the Cluster, and cluster instances did not have an engineVersion defined. I tried this but it does not work