https://github.com/osquery/osquery logo
Join Slack
Powered by
Hey - Latest Terraform mod-root version is spittin...
# fleet
e
Hey - Latest Terraform mod-root version is spitting back a bunch of downstream null variable errors.
Copy code
Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: Invalid function argument
│ 
│   on .terraform/modules/fleet.byo-vpc.rds/main.tf line 136, in resource "aws_rds_cluster" "this":
│  136:     for_each = length(var.serverlessv2_scaling_configuration) > 0 && var.engine_mode == "provisioned" ? [var.serverlessv2_scaling_configuration] : []
│     ├────────────────
│     │ while calling length(value)
│     │ var.serverlessv2_scaling_configuration is null
│ 
│ Invalid value for "value" parameter: argument must not be null.
Any ideas here? We are not explicitly setting the serverless vars, happy to accept the default in the byo-vpc module
👀 1
@Cameron
m
Hello @Ed Merrett. Sorry to hear you're running into issues, thanks for bringing it to our attention. I'm going to run this by our infrastructure team and see what the next steps look like.
j
Hi @Ed Merrett, @Matt Rebelo tagged me in and I'm sorry to see that you're experiencing some trouble with our terraform example. Good news, I was able to reproduce the issue on our end and I've identified a fix that I'm working on testing, before I get it merged in. I should have the fix in and the example updated, in the next 30m-1h.
e
💥 Love it, thanks @Jorge Falcon for hopping on that so fast!
j
@Ed Merrett - I just merged the fix in and updated the example. Give it another shot when you have a moment
e
👀
Hmm new errors:
Copy code
Error: Cannot import non-existent remote object
│ 
│ While attempting to import an existing object to "module.fleet.module.byo-vpc.module.byo-db.module.ecs.aws_ecs_task_definition.backend", the provider detected that
│ no object exists with the given id. Only pre-existing objects can be imported; check that the id is correct and that it is associated with the provider's configured
│ region or endpoint, or use "terraform apply" to create a new remote object for this resource.
j
The error indicates an issue importing a remote object. Did you see this error when executing the various targeted terraform applies that we recommend?
e
Oh no, news to me you guys recommend a targeted apply - is that info in the main fleetdm repo?
Ah right, from scratch - however I am just upgrading
j
If just upgrading, then the targeted applies shouldn't apply here. You're right in that it's mainly for the first time, and in some cases when introducing new modules.
Just for my clarity, did terraform throw the error when running 
terraform apply
or were you trying to 
terraform import module.fleet.module.byo-vpc.module.byo-db.module.ecs.aws_ecs_task_definition.backend <task-definition-id>
or something else?
e
I think I can see the issue - looks like the CI pipleine that generated a failure (tf apply) destroyed the task definition
j
Yeah, it's having trouble either finding the task definition or it disappeared (destroyed) like you mentioned
e
my CI error:
Copy code
module.fleet.module.byo-vpc.module.byo-db.module.ecs.aws_ecs_task_definition.backend: Destroying... [id=fleet]
module.fleet.module.byo-vpc.module.byo-db.module.ecs.aws_ecs_task_definition.backend: Destruction complete after 0s
module.fleet.module.byo-vpc.module.rds.aws_rds_cluster.this[0]: Modifying... [id=fleet]
╷
│ Error: updating RDS Cluster (fleet): InvalidParameterCombination: Cannot upgrade aurora-mysql from 8.0.mysql_aurora.3.08.2 to 8.0.mysql_aurora.3.07.1
│ 	status code: 400, request id: b801e644-0984-43a0-a3bd-c8e0703d1adf
│ 
│   with module.fleet.module.byo-vpc.module.rds.aws_rds_cluster.this[0],
│   on .terraform/modules/fleet.byo-vpc.rds/main.tf line 61, in resource "aws_rds_cluster" "this":
│   61: resource "aws_rds_cluster" "this" {
│
when trying to upgrade using tf-mod-root 15.2
j
Yesterday, I actually published a new version of the module that should default to 
8.0.mysql_aurora.3.08.2
as the engine_version. 
tf-mod-root-v1.16.1
and later should default to 
8.0.mysql_aurora.3.08.2
. The other alternative is that you can explicitly define it in your module.fleet.rds_config under 
engine_version
- https://github.com/fleetdm/fleet-terraform/blob/tf-mod-root-v1.16.2/example/main.tf#L105
From the error it looks like the database cluster/instances are probably on 
8.0.mysql_aurora.3.08.2
already, but you may want to double check. The AWS terraform provider does not try to do an in-place upgrade, if the version is bumped up. I would just double check that the engine_version defined in the terraform matches the engine_version in aws
e
Yeah thats what we were trying to apply etc - update the fleet instance and terraform module - now I'm in a CI black hole and can't apply due to the destroyed task definiton this is fine
j
If you're able to, you might be able to target the task definition directly with something like 
terraform apply -target=module.fleet.module.byo-vpc.module.byo-db.module.ecs.aws_ecs_task_definition.backend
, if the task definition is the only issue
e
Anyone get TF state borks and just sends them into pure panic 😆 Got it sorted, thanks for helping out on what was very much a "me" issue also. Really appreciate your guidance here! All upgraded! ✅ ty
j
Anytime! I'm glad you were able to get it all resolved
🎉 1
m
Thank you Jorge!
7 Views
Open in Slack
PreviousNext
Powered by