aws.acm.Certificate subjectAlternativeNames order is not consistent and replaces on different order

[shellicar]

Version

Windows - v2.5.0
@pulumi/pulumi 2.5.0
@pulumi/aws 2.11.0

Description

I am creating a certificate with multiple (4) SAN entries.
I had noticed that I had to change the ordering of the subjectAlternativeNames value for the values to match pulumi's current state.
Otherwise on pulumi up, pulumi would detect changes and attempt to recreate the certificate, usually resulting in a situation that I need to manually intervene to fix (potentially due to a different route53.Record/acm.CertificateValidation issue).

This was a satisfactory workaround until I started to deploy to a new stack (environment).
In the other stack, the order of subjectAlternativeNames seems to be different again.
If I always use the same order (pre-sort), then pulumi wants to replace the Certificate on every update, as it thinks the value has changed.
I'm guessing this is due to how another API reports the SAN order.

[leezen]

Unfortunately, this looks like a fairly deep issue upstream as discussed in hashicorp/terraform-provider-aws#8531

[shellicar]

Thanks for the information and for the link.
For now I am working around the issue by using multiple wildacard certs with only a single SAN (the wildcard).

[marns93]

hashicorp/terraform-provider-aws#8531 is fixed and will be released next week.

[stack72]

This will be fixed and released in the v3.0.0 release

[gleb-jiji]

I'm still getting attempts to recreate a freshly created certificate due to subjectAlternativeNames order mismatch.
Pulumi 2.9.0, and Python packages pulumi==2.9.0, pulumi-aws==3.1.0
Also the subject_alternative_names constructor argument still requires a list and won't accept a set.

[stack72]

Hi All

My most sincere apologies for taking so long to circle back here. I have just tested this with the latest pulumi-aws (v3.17.0) and at some point this has actually been fixed and I have verified that is the case.

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";

const x = new aws.acm.Certificate("demo", {
domainName: "my.zone",
    validationMethod: "DNS",
    subjectAlternativeNames: [
        "one.my.zone",
        "two.my.zone",
        "three.my.zone",
    ]
});

export const options = x.domainValidationOptions;

pulumi up yields:

     Type                    Name             Status
 +   pulumi:pulumi:Stack     gh-aws-1022-dev  created
 +   └─ aws:acm:Certificate  demo             created

Outputs:
    options: [
        [0]: {
            domainName         : "three.my.zone"
            resourceRecordName : "_4a9b40b76f13976cbcaf3756b636c3d0.three.my.zone."
            resourceRecordType : "CNAME"
            resourceRecordValue: "_de6b4e65e01170b675d7cfe974860bcc.wggjkglgrm.acm-validations.aws."
        }
        [1]: {
            domainName         : "two.my.zone"
            resourceRecordName : "_e38d998e5e4ed8e7f4b7bd62e050181b.two.my.zone."
            resourceRecordType : "CNAME"
            resourceRecordValue: "_84c739ab1b701509f1fe38f7a0b90c65.wggjkglgrm.acm-validations.aws."
        }
        [2]: {
            domainName         : "my.zone"
            resourceRecordName : "_965794d11afd6dc70ac9c46cd5cd71ec.my.zone."
            resourceRecordType : "CNAME"
            resourceRecordValue: "_5738734e55d687a240e56c09415582df.wggjkglgrm.acm-validations.aws."
        }
        [3]: {
            domainName         : "one.my.zone"
            resourceRecordName : "_feea2097fc4d2cf0a82fdc195c36072e.one.my.zone."
            resourceRecordType : "CNAME"
            resourceRecordValue: "_e6a0c5ca151d0ebc1ebe8bef9e06b0fa.wggjkglgrm.acm-validations.aws."
        }
    ]

Resources:
    + 2 created

Duration: 13s

A further Pulumi up yields the following:

     Type                 Name             Status
     pulumi:pulumi:Stack  gh-aws-1022-dev

Outputs:
    options: [
        [0]: {
            domainName         : "three.my.zone"
            resourceRecordName : "_4a9b40b76f13976cbcaf3756b636c3d0.three.my.zone."
            resourceRecordType : "CNAME"
            resourceRecordValue: "_de6b4e65e01170b675d7cfe974860bcc.wggjkglgrm.acm-validations.aws."
        }
        [1]: {
            domainName         : "two.my.zone"
            resourceRecordName : "_e38d998e5e4ed8e7f4b7bd62e050181b.two.my.zone."
            resourceRecordType : "CNAME"
            resourceRecordValue: "_84c739ab1b701509f1fe38f7a0b90c65.wggjkglgrm.acm-validations.aws."
        }
        [2]: {
            domainName         : "my.zone"
            resourceRecordName : "_965794d11afd6dc70ac9c46cd5cd71ec.my.zone."
            resourceRecordType : "CNAME"
            resourceRecordValue: "_5738734e55d687a240e56c09415582df.wggjkglgrm.acm-validations.aws."
        }
        [3]: {
            domainName         : "one.my.zone"
            resourceRecordName : "_feea2097fc4d2cf0a82fdc195c36072e.one.my.zone."
            resourceRecordType : "CNAME"
            resourceRecordValue: "_e6a0c5ca151d0ebc1ebe8bef9e06b0fa.wggjkglgrm.acm-validations.aws."
        }
    ]

Resources:
    2 unchanged

Duration: 3s

I am going to close this issue out as this isn't repeatable here and has not been reported in the upstream provider again (AFAICT)

Please do let us know if there are any issues

Paul