#refarch (2023-08)
Cloud Posse Reference Architecture
2023-08-01
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
https://github.com/cloudposse/terraform-aws-ecs-alb-service-task is now failing with the error in the screenshot.
this is used in a component based on the refarch ecs-service.
Terraform module which implements an ECS service which exposes a web service via ALB.
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
@Jeremy G (Cloud Posse) your PR updated things in this area. Any thoughts?
Terraform module which implements an ECS service which exposes a web service via ALB.
![Jeremy G (Cloud Posse) avatar](https://avatars.slack-edge.com/2020-07-04/1229022582372_22757dbc9ef96d371614_72.jpg)
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.
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
we’re not using the latter; only the former
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
hrmm…some services are passing and some aren’t. i’m going to retry failures and see if it resolves.
![Jeremy G (Cloud Posse) avatar](https://avatars.slack-edge.com/2020-07-04/1229022582372_22757dbc9ef96d371614_72.jpg)
@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.
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
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",
]
}
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
when we add policies we don’t use it, though
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
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",
]
}
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
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
![Jeremy G (Cloud Posse) avatar](https://avatars.slack-edge.com/2020-07-04/1229022582372_22757dbc9ef96d371614_72.jpg)
@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.
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
yeah, i’ll get a ticket in to take care of that sooner than later
2023-08-02
2023-08-03
![Michael Dizon avatar](https://avatars.slack-edge.com/2021-01-15/1664383757488_b5214d00b8fce4726a7c_72.jpg)
hey guys, any idea how I can add a CMK to the cloudwatch logs that get created by cloudposse/rds/aws
when specifying values for the enabled_cloudwatch_logs_exports
variable?
2023-08-08
2023-08-09
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
AWS teams integration is working in terms of adding the values, but the billing admin can’t see anything in billing. Is something off here?
these are from refarch directly (don’t think there are any customizations): https://github.com/cloudposse/terraform-aws-components/tree/main/modules/aws-sso
billing RO
"arn:${local.aws_partition}:iam::aws:policy/AWSBillingReadOnlyAccess",
"arn:${local.aws_partition}:iam::aws:policy/AWSSupportAccess",
billing admin
"arn:${local.aws_partition}:iam::aws:policy/job-function/Billing",
"arn:${local.aws_partition}:iam::aws:policy/AWSSupportAccess",
![Brian avatar](https://secure.gravatar.com/avatar/22efa2a78045ecdab74494db85b41ba7.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0021-72.png)
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
}
}
![Brian avatar](https://secure.gravatar.com/avatar/22efa2a78045ecdab74494db85b41ba7.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0021-72.png)
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).
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
ahhhh…ok. let me see if i can just enable that via code; i’d prefer not to manually do it.
thx @Brian
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
welp…looks like changing that is ignored.
lifecycle {
ignore_changes = [iam_user_access_to_billing]
}
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
this is why
![Brian avatar](https://secure.gravatar.com/avatar/22efa2a78045ecdab74494db85b41ba7.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0021-72.png)
Yep. It’s ignored. It cannot be enabled or disabled by IAM identity.
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
(didn’t hit send on that yesterday)
2023-08-10
2023-08-11
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
The Spacelift admin stack needs this fix: https://github.com/cloudposse/terraform-aws-components/issues/771.
The component updater is trying to go from 1.259.0 to 1.278.0 and it fails consistently.
Found a bug? Maybe our Slack Community can help.
Describe the Bug
│ Error: Inconsistent conditional result types
│
│ on outputs.tf line 8, in output "root_stack":
│ 8: value = local.enabled && local.create_root_admin_stack ? module.root_admin_stack : {}
│ ├────────────────
│ │ local.create_root_admin_stack is true
│ │ local.enabled is true
│ │ module.root_admin_stack is object with 2 attributes
│
│ The true and false result expressions must have consistent types. The
│ 'true' value includes object attribute "id", which is absent in the 'false'
│ value.
╵
Expected Behavior
Run passes
Steps to Reproduce
Steps to reproduce the behavior:
- Run within the context of an atmos project’s root stack
Screenshots Environment (please complete the following information):
Anything that will help us triage the bug will help. Here are some ideas:
• Version v1.259.0
Additional Context
This works just fine.
output "root_stack" {
description = "The root stack, if enabled and created by this component"
value = local.enabled && local.create_root_admin_stack ? module.root_admin_stack : null
sensitive = true
}
2023-08-16
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
what
• Updated the title
why
• It was an extra helping of copy/pasta
references
2023-08-17
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
Anyone know how to address this TGW error?
╷ │ Error: creating EC2 Transit Gateway VPC Attachment: DuplicateTransitGatewayAttachment: tgw-0550c8f9754f4c11e has non-deleted Transit Gateway Attachments with same VPC ID. │ status code: 400, request id: 0292a4de-a29e-4c78-b2c4-b00f525346c1 │ │ with module.tgw_spoke_vpc_attachment.module.standard_vpc_attachment.aws_ec2_transit_gateway_vpc_attachment.default[“plat-ue1-beta”], │ on .terraform/modules/tgw_spoke_vpc_attachment.standard_vpc_attachment/main.tf line 43, in resource “aws_ec2_transit_gateway_vpc_attachment” “default”: │ 43: resource “aws_ec2_transit_gateway_vpc_attachment” “default” {
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
are you deploying a new TGW, or some resources were deleted on the existing TGW?
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
it is an existing TGW that was upgraded as part of the new multi-regional TGW setup
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
most of the TGW’s worked just fine. this env and 1 or 2 others didn’t recreate properly
![Gabriela Campana (Cloud Posse) avatar](https://avatars.slack-edge.com/2023-05-17/5281506983315_fbbf3b358313efef4647_72.jpg)
@johncblandii do you still need help with this?
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
yes, multiple spokes are failing to destroy
![Gabriela Campana (Cloud Posse) avatar](https://avatars.slack-edge.com/2023-05-17/5281506983315_fbbf3b358313efef4647_72.jpg)
@Andriy Knysh (Cloud Posse)
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
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
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
yes, there is a TGW already for this vpc so it can’t create another
2023-08-18
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
what
• Added preserve_client_ip flag for the target group
why
• NLBs need to be able to preserve the client IP
references
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
@Andriy Knysh (Cloud Posse) i forget what the latest test/readme commands are.
Do you mind running those for me?
what
• Added preserve_client_ip flag for the target group
why
• NLBs need to be able to preserve the client IP
references
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
you need to tun
make init
make github/init
make readme
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
on you computer
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
then we’ll run /terratest
as GH comment
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
ok…i’ll pull it down. i thought there were github comments i could run; did it all on [github.dev](http://github.dev)
.
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
ah, it was missing some github files. i see
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
pushed and terratest ran
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
green bean!
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
thanks @johncblandii, approved and merged
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
2023-08-21
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
So we are overhauling our AWS tagging and wanted to know, generally speaking what the level of effort might be to say add a namespace to cloudposse’s tags. Thinking something like “cp:stage”, “cp:environment” etc.. Also want to normalize all our tags to lower case. PS: where might a change like this be accomplished? My impression is that it’s handled by the terraform-null-label, but I could be mistaken.
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
So any info regarding cloudposse generated tags would be helpful.
![Gabriela Campana (Cloud Posse) avatar](https://avatars.slack-edge.com/2023-05-17/5281506983315_fbbf3b358313efef4647_72.jpg)
@Andriy Knysh (Cloud Posse)
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
FYI: the atmos updater keeps creating PRs for spacelift/admin-stack
, but it is a bad update: https://github.com/cloudposse/terraform-aws-components/issues/771.
That needs to be addressed otherwise it will break the module.
Found a bug? Maybe our Slack Community can help.
Describe the Bug
│ Error: Inconsistent conditional result types
│
│ on outputs.tf line 8, in output "root_stack":
│ 8: value = local.enabled && local.create_root_admin_stack ? module.root_admin_stack : {}
│ ├────────────────
│ │ local.create_root_admin_stack is true
│ │ local.enabled is true
│ │ module.root_admin_stack is object with 2 attributes
│
│ The true and false result expressions must have consistent types. The
│ 'true' value includes object attribute "id", which is absent in the 'false'
│ value.
╵
Expected Behavior
Run passes
Steps to Reproduce
Steps to reproduce the behavior:
- Run within the context of an atmos project’s root stack
Screenshots Environment (please complete the following information):
Anything that will help us triage the bug will help. Here are some ideas:
• Version v1.259.0
Additional Context
This works just fine.
output "root_stack" {
description = "The root stack, if enabled and created by this component"
value = local.enabled && local.create_root_admin_stack ? module.root_admin_stack : null
sensitive = true
}
![Gabriela Campana (Cloud Posse) avatar](https://avatars.slack-edge.com/2023-05-17/5281506983315_fbbf3b358313efef4647_72.jpg)
@Andriy Knysh (Cloud Posse)
Found a bug? Maybe our Slack Community can help.
Describe the Bug
│ Error: Inconsistent conditional result types
│
│ on outputs.tf line 8, in output "root_stack":
│ 8: value = local.enabled && local.create_root_admin_stack ? module.root_admin_stack : {}
│ ├────────────────
│ │ local.create_root_admin_stack is true
│ │ local.enabled is true
│ │ module.root_admin_stack is object with 2 attributes
│
│ The true and false result expressions must have consistent types. The
│ 'true' value includes object attribute "id", which is absent in the 'false'
│ value.
╵
Expected Behavior
Run passes
Steps to Reproduce
Steps to reproduce the behavior:
- Run within the context of an atmos project’s root stack
Screenshots Environment (please complete the following information):
Anything that will help us triage the bug will help. Here are some ideas:
• Version v1.259.0
Additional Context
This works just fine.
output "root_stack" {
description = "The root stack, if enabled and created by this component"
value = local.enabled && local.create_root_admin_stack ? module.root_admin_stack : null
sensitive = true
}
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
what
• Update root_stack
output in modules/spacelift/admin-stack/outputs.tf
why
• Fix the issue described in #771
related
• Closes #771
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
what
• Upgrade aws-config and conformance pack modules to 1.1.0
why
• They’re outdated.
references
2023-08-24
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
So when creating spacelift spaces, I was trying to get another layer for stage under the space for tenant..
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
So here’s my stack:
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
![Matthew Reggler avatar](https://secure.gravatar.com/avatar/2cdf969f30a522e03ebbd1acf653fa49.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0022-72.png)
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
![Matthew Reggler avatar](https://secure.gravatar.com/avatar/2cdf969f30a522e03ebbd1acf653fa49.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0022-72.png)
I’ve run into this before outside of this component, but looking at their terraform here its the same issue under the hood
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
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.
2023-08-25
2023-08-28
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
Here’s an odd issue.. So I am trying to update Spacelift’s root admin stack, but am getting an error:
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
This is referencing this code:
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
But if run atmos terraform shell admin-stack -s…. then run terraform console.. it works
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
I feel like I am having a dependency issue, as its running the locals block before loading the module
![Gabriela Campana (Cloud Posse) avatar](https://avatars.slack-edge.com/2023-05-17/5281506983315_fbbf3b358313efef4647_72.jpg)
@Dan Miller (Cloud Posse) @Matt Calhoun
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
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
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
will give it a “try”
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
so it of course barfs with the next line failing to load a stack with a null name..
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
the issue is that root_admin_stack_config
is null. we should figure out why that is rather than trying to work around it
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
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.
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
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
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
thats correct
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
one sec
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
and do you have other components in the root space? such as spacelift/spaces
and/or spacelift/worker-pool
?
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
yes both
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
can you try removing line 51 I think? - admin-stack-name: root
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
sure
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
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
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
yeah I added it as a suggestion from you when it was creating… but happy to remove it now
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
running now
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
same issue
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
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
...
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
so I bet I have stage and tenat backwards:
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
ah yeah that is flipped!
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
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
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
doesnt seem so:
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
I think you may have the same flipped stage/tenant value elsewhere as well, based on that second error message
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
the stack name should be root-gbl-spacelift
![Christopher Pieper avatar](https://secure.gravatar.com/avatar/534a800903dbed158459a2349029435d.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0017-72.png)
this is from the README in the root folder spacelift:
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
yes that should be correct. The screenshot of your error message says spacelift-gbl-root
and not root-gbl-spacelift
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
:thread: Thoughts on S3 bucket grants adding direct support for the canonical user? Currently the owner is set in the core s3-bucket component, but the grant requires an id
that isn’t dynamic.
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
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)
}
![Gabriela Campana (Cloud Posse) avatar](https://avatars.slack-edge.com/2023-05-17/5281506983315_fbbf3b358313efef4647_72.jpg)
@Jeremy G (Cloud Posse)
![Jeremy G (Cloud Posse) avatar](https://avatars.slack-edge.com/2020-07-04/1229022582372_22757dbc9ef96d371614_72.jpg)
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.
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
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.
![Jeremy G (Cloud Posse) avatar](https://avatars.slack-edge.com/2020-07-04/1229022582372_22757dbc9ef96d371614_72.jpg)
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.
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
we did. just having it in the refarch and not requiring manual changes seemed more ideal.
2023-08-29
2023-08-30
![shaikimran0509 avatar](https://secure.gravatar.com/avatar/24d859760b4b0e3441b8ab4c4f8290d7.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0022-72.png)
Hi all,
in terraform-aws-ecs-cloudwatch-autoscaling
i was trying to add step_scaling_policy_configuration
i am getting error of An argument named "scaling_adjustment" is not expected here.
Interval 1: 2 to 2.5
Interval 2: 2.5 to 3
Interval 3: 3 to 5
Interval 4: 5 and above
expecting help on this..
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
This is more related to #terraform-aws-modules as I don’t believe this is in our refarch