aws_cloudformation_stack resources no longer have an ARN in plan.json

[rulatir]

I just rebuilt terraformer from master, and now when I do terraformer plan, the aws_cloudformation_stack resources in plan.json no longer contain the whole ARN. I can synthesize the ARN from the ID just fine since account ID is the only extra info needed, but the problem is that the bare ID seems to be just an arbitrary string with no characteristics indicating that it is an ID of a cloudformation stack, and I must basically downgrade to accept arbitrary strings as resource IDs.

The good thing about ARNs is that they are easily identifiable as resource references. I believe they should be used wherever possible. It would facilitate writing schema-less resource graph crawlers: if an object property looks like ARN, it is a graph edge.

[rulatir]

Hmm, this is weird. Manual terraform import currently omits the ARN too. But I swear it must have worked previously, or my own script would have tripped just like it trips now, and I have imported cloudformation stacks successfully (with plan.json massage described in issue #420).

[rulatir]

And it seems that the relevant code in terraform AWS provider hasn't changed in years. So this is really strange unless schema.ResourceData::SetId() changed its behavior between v2.48 and v2.50... probably an upstream issue though.

[patrykorwat]

In #415 i changed the way how CF stacks are being imported. Now they are imported by its name, which is the correct way according to TF. Will take a look into the plan.json, perhaps there’s something more to adjust.

[rulatir]

"Because UUIDs are so 1980s and so Microsoft" - Amazon/Hashicorp Joint Standards Committee

Seriously though, what's their rationale? Got a link to where they say it? I just terraform imported an ASG that was created with one of our CF stacks, and surely enough it is tagged with an ARN reference to the "mother" CF stack. How can TF say you shouldn't use the ARN as a CF stack's ID when the modeled reality does use ARNs as CF stack references?

(EDIT: it is also tagged with a name reference so perhaps the ARN reference is legacy stuff?)

[patrykorwat]

@rulatir Terraform is all driven by the AWS API. You can read more about it in https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DescribeStacks.html
and take a look at the parameter StackName. The name suggests that the accepted value is always a name but by taking closer look we can see the value is:

The name or the unique stack ID [...]:

• Running stacks: You can specify either the stack's name or its unique stack ID.
• Deleted stacks: You must specify the unique stack ID.
  AWS CloudFormation fixes #415 did improved the import process, so that it only used stack name but it did also started filtering out deleted stacks, so now Terraformer will import only running stacks (as Terraform itself supports management of running stacks only as well).

Because of that and fact that currently the tfstate file is inheritibly incorrect:

{
   ...
            "resources": {
                "aws_cloudformation_stack.tfer--abcI": {
                    "type": "aws_cloudformation_stack",
                    "depends_on": [],
                    "primary": {
                        "id": "<NAME>",
                        "attributes": {
                            ...
                            "id": "<NAME>",
                            "name": "<NAME>"
                        }
}

Because of those facts, it is better to refer to the CF template by its identifier.

In a more broad sense, Terraform as well as AWS doesn't strongly define what is an identifier of a resource. It's up to a service (I assume internal development team) to define those specifics. I agree it's not making the development of tools that manage the resources easy because each resources must be uniquely checked for details of the practices.