Traling period is causing updates

[1oglop1]

What happened?

Hi I found this issue exactly describing the problem: cloudflare/terraform-provider-cloudflare#154

Steps to reproduce

What happens:
When you create acm.Certificate and return certificate.domain_validation_options

cert_validation_option: pulumi.Output[
            acm.outputs.CertificateOptions
        ] = certificate.domain_validation_options.apply(lambda o: o[0])

and pass this in cloudflare.Record

cloudflare.Record(
            f"{self._name}-cert",
            args=cloudflare.RecordArgs(
                name=cert_validation_option.resource_record_name,
                value=cert_validation_option.resource_record_value,
                type=cert_validation_option.resource_record_type,
                zone_id=self._config.zone_id,
                # We need to allow overwrite due to ACM being regional.
                # We cannot re-use the certificate from another region
                # Validation domain name depends on the certificate domain
                # Two certificates in different regions and same domain name
                # have the same validation record
                allow_overwrite=True,
            ),
            opts=   pulumi.ResourceOptions(delete_before_replace=True),
        )        

value cert_validation_option.resource_record_value will cause forever diff because Cloudflare trims the trailing period.

~ value: "_dbdxxx05384ca.hnyhpvdqhv.acm-validations.aws" => "_dbdxxxf205384ca.hnyhpvdqhv.acm-validations.aws."

Expected Behavior

No updates

Actual Behavior

Forever update

Versions used

NAME VERSION
pulumi 3.33.2
pip 22.0.3
projects 0.1.0
pulumi-cloudflare 4.7.0
setuptools 60.6.0
wheel 0.37.1

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[stack72]

Hi @1oglop1

Can you tell me what version of pulumi-aws that you are using as well?

Paul

[1oglop1]

@stack72 pulumi_aws-5.4.0

[stack72]

Hi @1oglop1

Unfortunately, this is the AWS provider that is returning the trailing . character. This means that we would need to strip that character before passing this to the cloudflare provider. Even in the upstream issue, there are mentions of replace to remove it :/

I am not 100% sure we can do anything in the provider here because the behaviour is actually correct. I guess I suggest that we'd need to run an apply as part of the value and trim any trailing . as follows:

cloudflare.Record(
            f"{self._name}-cert",
            args=cloudflare.RecordArgs(
                name=cert_validation_option.resource_record_name,
                value=cert_validation_option.resource_record_value.apply(
		    lambda val: val. removesuffix(".")
	        ),
                type=cert_validation_option.resource_record_type,
                zone_id=self._config.zone_id,
                # We need to allow overwrite due to ACM being regional.
                # We cannot re-use the certificate from another region
                # Validation domain name depends on the certificate domain
                # Two certificates in different regions and same domain name
                # have the same validation record
                allow_overwrite=True,
            ),
            opts=   pulumi.ResourceOptions(delete_before_replace=True),
        )      

Paul

[1oglop1]

I believe that this is not a mistake fo AWS provider, but instead Cloudflare bending RFCs which state that FQND ends with traling period.
https://datatracker.ietf.org/doc/html/rfc1034
https://datatracker.ietf.org/doc/html/rfc1035

If there is nothing to do about that, at the very least it would probably be good to emit a warning message to the user about this problem.

[stack72]

Hi @1oglop1

I totally understand - i've actually just opened cloudflare/terraform-provider-cloudflare#1713 upstream in the Terraform provider to ensure that we can get this added - if they don't want to accept that, I can bring it directly to a fork of our provider and we will get this fixed

I will change this to be awaiting-upstream and I can track changes directly here

Paul