#refarch (2023-08)

@Jeremy G (Cloud Posse) your PR updated things in this area. Any thoughts?

I’m not sure what “resource” couldn’t be found. I don’t know why the task name is prepended to the policy ARN. You are better off using task_policy_arns_map input rather than task_policy_arns in any case, so try switching to that.

we’re not using the latter; only the former

hrmm…some services are passing and some aren’t. i’m going to retry failures and see if it resolves.

@johncblandii The key "_#1_" in the resource address shown in your screenshot indicates a key was made for an entry in task_policy_arns (which is a list). If you use task_policy_arns_map then it would use the map key instead.

ah, the vendored component has defaults.

variable "task_policy_arns" {
  type        = list(string)
  description = "The IAM policy ARNs to attach to the ECS task IAM role"
  default = [
    "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly",
    "arn:aws:iam::aws:policy/AmazonSSMReadOnlyAccess",
  ]
}

when we add policies we don’t use it, though

https://github.com/cloudposse/terraform-aws-components/blob/main/modules/ecs-service/variables.tf#L30-L37

re-running all stacks works, which is weird, so looks like it isn’t a blocker. will keep it in mind to refactor it away from the list version

@johncblandii It would be nice to move the defaults to the map, but I am worried it would be too disruptive. If you would like to try it out and confirm there is no or little interruption of service, that would be great.

yeah, i’ll get a ticket in to take care of that sooner than later

Yes. You will need to manually enable the option to allow IAM identities access to billing. If the account_iam_user_access_to_billing (part of the account component) option wasn’t enabled at time the account was created or if the account was imported, then you must enable it manually.

The reason is must be enabled manually is because the account component ignores (see snippet below) that property except whenever it creates the account itself.

# Provision Accounts for Organization (not connected to OUs)
resource "aws_organizations_account" "organization_accounts" {
  for_each                   = local.organization_accounts_map
  name                       = each.value.name
  email                      = format(each.value.account_email_format, each.value.name)
  iam_user_access_to_billing = var.account_iam_user_access_to_billing
  tags                       = merge(module.this.tags, try(each.value.tags, {}), { Name : each.value.name })

  lifecycle {
    ignore_changes = [iam_user_access_to_billing]  # <=============== IRGNORING
  }
}

In order to manually enable it, you must log in as root then find the setting on the Accounts page. The setting isn’t visible if you’re not logged in as root (even if IAM identities were allowed access to billing).

ahhhh…ok. let me see if i can just enable that via code; i’d prefer not to manually do it.

thx @Brian

welp…looks like changing that is ignored.

  lifecycle {
    ignore_changes = [iam_user_access_to_billing]
  }

this is why

Yep. It’s ignored. It cannot be enabled or disabled by IAM identity.

done and it all works well

(didn’t hit send on that yesterday)

are you deploying a new TGW, or some resources were deleted on the existing TGW?

it is an existing TGW that was upgraded as part of the new multi-regional TGW setup

most of the TGW’s worked just fine. this env and 1 or 2 others didn’t recreate properly

@johncblandii do you still need help with this?

yes, i believe so. will check on it in a sec

yes, multiple spokes are failing to destroy

@Andriy Knysh (Cloud Posse)

I believe the problem is a duplication of the TGW resource sharing when enabling the alternate region. I’m debugging a similar issue today and will let you know once I discover exactly what the issue is. Will update later today/tomorrow

yes, there is a TGW already for this vpc so it can’t create another

@Andriy Knysh (Cloud Posse) i forget what the latest test/readme commands are.

Do you mind running those for me?

you need to tun

make init
make github/init
make readme

on you computer

then we’ll run /terratest as GH comment

ok…i’ll pull it down. i thought there were github comments i could run; did it all on [github.dev](http://github.dev).

ah, it was missing some github files. i see

pushed and terratest ran

green bean!

thanks @johncblandii, approved and merged

So any info regarding cloudposse generated tags would be helpful.

@Andriy Knysh (Cloud Posse)

@Andriy Knysh (Cloud Posse)

@johncblandii https://github.com/cloudposse/terraform-aws-components/pull/837

So here’s my stack:

Space ID’s aren’t the name of the space (with the exception of “root”, where name=ID), there is a long alphanumeric added to the end after a hyphen

You can see this in the console for manually-created spaces.

Unfortunately this means you’ll need to deploy this in stages, manually copying in the space ids for existing spaces.

The terraform resource for creating new spaces doesn’t support “parent_space_by_name”, so CloudPosse would need to rewrite their spaces module to use the data source spacelift_space_by_path and some clever concatenation logic to access spaces by name

I’ve run into this before outside of this component, but looking at their terraform here its the same issue under the hood

So here in lies the appearance of nested spaces, but not the support. Will file a bug in github and see what comes of it.

This is referencing this code:

But if run atmos terraform shell admin-stack -s…. then run terraform console.. it works

I feel like I am having a dependency issue, as its running the locals block before loading the module

@Dan Miller (Cloud Posse) @Matt Calhoun

could you try wrapping it with a try?

  root_admin_stack_name   = local.create_root_admin_stack ? try(keys(module.root_admin_stack_config.spacelift_stacks)[0], null) : null

will give it a “try”

so it of course barfs with the next line failing to load a stack with a null name..

the issue is that root_admin_stack_config is null. we should figure out why that is rather than trying to work around it

Of course, and as I wrote earlier.. When I do an atmos terraform shell admin-stack -s root-gbl-spacelift.. And then run terraform console, the module.root_admin_stack_config is not null, its what it should be.. Only thing I can gather is that terraform can’t correctly apply the order, so when locals block is run module hasn’t been loaded yet.

what your root admin stack configuration? in particular these settings:

        root_admin_stack: true # This stack will be created in the root space and will create all the other admin stacks as children.
        context_filters: # context_filters determine which child stacks to manage with this admin stack
          administrative: true # This stack is managing all the other admin stacks
          root_administrative: false # We don't want this stack to also find itself in the config and add itself a second time
        labels:
          - admin

thats correct

one sec

and do you have other components in the root space? such as spacelift/spaces and/or spacelift/worker-pool?

yes both

can you try removing line 51 I think? - admin-stack-name: root

sure

That admin-stack-name label is telling this component that there should be an admin-stack for this component. But this component creates its own spacelift stack

yeah I added it as a suggestion from you when it was creating… but happy to remove it now

running now

same issue

hmm, perhaps we’re missing other default stack settings. Do you have these in admin-stack-defaults?

settings:
  spacelift:
    administrative: true
...
vars:
  spacelift_spaces_stage_name: "root"
  administrative: true
...

so I bet I have stage and tenat backwards:

ah yeah that is flipped!

that sounds exactly like the issue. Terraform is looking for a component in a stack that doesnt exist, so root_admin_stack_config is empty

doesnt seem so:

I think you may have the same flipped stage/tenant value elsewhere as well, based on that second error message

the stack name should be root-gbl-spacelift

this is from the README in the root folder spacelift:

yes that should be correct. The screenshot of your error message says spacelift-gbl-root and not root-gbl-spacelift

this is a rough approach to allowing an optional(string) on var.grants then replacing it based on the type.

It is inefficient, but it would be great to support this at the core module level (optional id and set the value if type = Canonical)

data "aws_canonical_user_id" "default" { count = local.enabled ? 1 : 0 }

locals {
  # TODO: This is inefficient. Adjust this to prevent duplicate loops.
  canonical_grants     = [for grant in var.grants : merge(grant, { id = one(data.aws_canonical_user_id.default[*].id) }) if grant.type == "CanonicalUser"]
  non_canonical_grants = [for grant in var.grants : grant if grant.type != "CanonicalUser"]

  grants = concat(local.canonical_grants, local.non_canonical_grants)
}

@Jeremy G (Cloud Posse)

I don’t see the advantage to this. The module user should fill in the grants before sending them to the module. Usually a CanonicalUser grant is for a different user, so automatically filling in the current user seems counter-productive.

well the canonical user for s3 is 1 particular id that exists via a data provider so it wouldn’t be something you want to manually put in because you’d need to manually grab that value for each AWS account and edit your yaml.

this takes away the automation and injects manual requirements.

You can use the data provider to grab the ID in your root module. To me, that makes the interface simpler and easier to understand than to have a special flag for S3 Canonical User.

we did. just having it in the refarch and not requiring manual changes seemed more ideal.

This is more related to #terraform-aws-modules as I don’t believe this is in our refarch