Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
The Fool
Oct 16, 2003


we looked at migrating from tfe to tfc and the change in pricing would have made it significantly more expensive

Adbot
ADBOT LOVES YOU

i am a moron
Nov 12, 2020

"I think if there’s one thing we can all agree on it’s that Penn State and Michigan both suck and are garbage and it’s hilarious Michigan fans are freaking out thinking this is their natty window when they can’t even beat a B12 team in the playoffs lmao"
Yea I don’t pay the bills, TFC ain’t cheap. Client has an organizational directive to use SaaS first, PaaS second, and IaaS/on premises as an absolute last resort. So unless someone’s SaaS implementation is horrible, it leads to stuff like using TFC and kinda shrugging at the cost

Edit: they’re interesting cause drat near everything was already containerized which IME is a bit rare for a company in their vertical and as old as it is. Makes shifting workloads to AKS insanely easy

necrobobsledder
Mar 21, 2005
Lay down your soul to the gods rock 'n roll
Nap Ghost

12 rats tied together posted:

CloudFormation is really good at this but is unintuitive because the way to do it is to use none of the features for it. StackSets are garbage, cross-stack references are also garbage. Control Tower shouldn't exist.
A large part of the modularity problems in CF come directly from how exported variables work and how there's basically no such thing as namespaces enforced by the system. It's too flexible in a sense.

12 rats tied together
Sep 7, 2006

The Fool posted:

You say the plumbing is error-prone like it's not automated and abstracted away.
Apologies. I didn't want to go big into the plumbing because it was going to make the post bigger and it was big enough already. By plumbing I mean this (please forgive any syntax errors I don't actually have a terraform setup to mess around with)
JavaScript code:
// root state
// lets assume this is a data only module that exports some networking info that every app needs, like subnet ids or something
module "some_networking_crap" {
  source = "${path.repository_root}/modules/data_only/networking"
}

// and then i have my own module
module "my_crap_primary" { 
  source = "./modules/crap_app"
  private_only = true 
  create_bucket = true // this app instance needs its own s3 bucket for a stupid reason
  subnet_ids = module.some_network_crap.output.private_subnet_ids // this is the plumbing
}

module "my_crap_secondary" {
  source = "./modules/crap_app"
  private_only = true
  create_bucket = false
  bucket_name_override = module.my_crap_primary.bucket_name //  this is a new type of plumbing
  subnet_ids = module.some_network_crap.output.private_subnet_ids // more plumbing 
 }
I'm not aware of a way to abstract this type of plumbing without wrapping it in another module, which might solve this problem right now, but generally leads to other problems down the line (incompatible nested versions. console becomes impossible to use. ever-growing list of conditional toggles).

Additionally, what happens when the networking module changes? My root state here is full of load-bearing string literals: "private_subnet_ids". "bucket_arn". If these ever become wrong my app suddenly starts failing to plan and I have no idea why, I need to trace the change up to whoever published my module, maybe find an updating guide or release notes, etc. This is a lot of work, risk, and ongoing maintenance for the really simple ask of "using the subnet that I'm supposed to".

CloudFormation sucks at this too, to be fair. The only benefit it has is that you dont have to write HCL, but Terraform also has that, so it's not really a W.

A better way to solve this problem is using a programming language, because then you can write factory methods. You can use dependency injection. You can use inheritance and composition mechanism unavailable in HCL. A lot of people do this already and just serialize to terraform json, or cloudformation json/yaml, but it's still kind of a lot of work. This is where Pulumi comes in, which has a standard library full of useful stuff like enums for every instance type so its impossible to run an apply and get "c5.8xlarge is not a valid instance type" errors.

necrobobsledder posted:

A large part of the modularity problems in CF come directly from how exported variables work and how there's basically no such thing as namespaces enforced by the system. It's too flexible in a sense.
Agree. The way I prefer to work with it dodges some of these concerns by not using !Export/!Import but it trades them for other problems, and it also requires ansible as a wrapper/orchestrator, which is a third set of problems. IMO, it's worth it, but it's not a tradeoff that needs to be made anymore when Pulumi and friends exist.

i am a moron
Nov 12, 2020

"I think if there’s one thing we can all agree on it’s that Penn State and Michigan both suck and are garbage and it’s hilarious Michigan fans are freaking out thinking this is their natty window when they can’t even beat a B12 team in the playoffs lmao"
I’m on my phone so can’t effortpost, but I think the difference in opinions here might be that if you’re fully leaning into TFC/TFE some of that isn’t really an issue. And for_each loops, dynamic blocks, and other improvements made to TF actually work really well in the latest TF versions.

12 rats tied together
Sep 7, 2006

I do think a lot of this stuff is "better now", in terraform. Like I'm pretty sure you can output an entire module by just declaring an output with a name and a value of "module.name", which gives anyone who calls you a big fat json blob containing all the outputs of your child module. You used to have to thread these through individually by name, and it sucked rear end, especially if any of them were conditionally created, because terraform still sucks poo poo at null and does random poo poo any time you feed it one. You also used to not be able to output anything except for string values, so you had to join your subnet ids with a pipe and then split them in your caller, but again I'm also pretty sure you can output complex types.

Really though, what I want to be able to do, is define e.g. a bunch of different types of ways of routing, and then I want a module that takes a RoutingType parameter, and I can just pass it 12RatsCoolVpnRoutingBehavior, and the module will pull it in and call "build()" on it, and everything just works. And then I can be like hey all these types of module can take any sort of RoutingBehavior from this enumerated list of different types of routing behavior, which I've imported from a package that was built by my devops team, and they've either baked in the subnet ids or theyve written some code to figure out the right ones, and I never have to care or think even a little bit about it except for typing "import companyname.infra.routing" and picking one in an intellisense drop down menu.

The Fool
Oct 16, 2003



I mean, for that specific scenario we just read the outputs from the hub network workspace

Feral Integral
Jun 6, 2006

YOSPOS

What's the latest poo poo people are using for CI these days? Last thing I worked on was jenkins and a bunch of plugins

Hadlock
Nov 9, 2004

Github Actions

drunk mutt
Jul 5, 2011

I just think they're neat

Hadlock posted:

Github Actions

Extremely Penetrated
Aug 8, 2004
Hail Spwwttag.
My little SaaS shop still has the majority of its components on EC2, with newer stuff developed locally in docker and then GitHub Actions'd into ECS. Almost every component is a dependency; you need the full stack in every dev environment. But a dev environment is created by getting EC2 going, then editing + manually running terraform in every component's repo to get ECS up, with a PR per repo. This ECS pattern is obviously poo poo and won't scale beyond a handful of components.

Is this finally a good time for us to use EKS? Have a helm chart from each repo, then just pull down which ones you want when a new environment is needed and deploy it to a new namespace in some premade cluster? How do I sell my Devs on it, it took them like a year to stop bitching about managing docker locally.

Vulture Culture
Jul 14, 2003

I was never enjoying it. I only eat it for the nutrients.

12 rats tied together posted:

I do think a lot of this stuff is "better now", in terraform. Like I'm pretty sure you can output an entire module by just declaring an output with a name and a value of "module.name", which gives anyone who calls you a big fat json blob containing all the outputs of your child module. You used to have to thread these through individually by name, and it sucked rear end, especially if any of them were conditionally created, because terraform still sucks poo poo at null and does random poo poo any time you feed it one. You also used to not be able to output anything except for string values, so you had to join your subnet ids with a pipe and then split them in your caller, but again I'm also pretty sure you can output complex types.
I strongly recommend, in general, not exporting complete module outputs as a single variable. Terraform's DAG tracks lifetimes and sensitivity of variables independently, but this happens at the level of an individual resource output (which includes module outputs). By collapsing your submodule outputs into a single output variable, which is now one map, you a) lose the ability to reference a promised identifier as soon as it materializes, and b) you mark the entire output as sensitive/insensitive when there's a good chance you have a mix of both. If you use terraform-docs, you now have nonsense (or, in the best case, confusingly indirected) module documentation about what you output.

e: this is fine from root modules from the DAG perspective (though mixed sensitivity still remains an issue)

Vulture Culture fucked around with this message at 16:10 on Mar 14, 2023

FISHMANPET
Mar 3, 2007

Sweet 'N Sour
Can't
Melt
Steel Beams

Feral Integral posted:

What's the latest poo poo people are using for CI these days? Last thing I worked on was jenkins and a bunch of plugins

I'm "still" using Azure DevOps. We don't have access to GitHub Actions, but even if we did, a lot of the stuff I'm doing in Azure DevOps doesn't seem to be possible in GitHub Actions. Microsoft isn't really saying much about what their preferred future is, considering they have two competing products (Azure DevOps Pipelines and GitHub Actions). In true Microsoft fashion, they're not going to truly "deprecate" anything when people are using it and, importantly, paying for it, but it does seem like a lot of their tutorials are more and more geared towards deploying the thing in GitHub Actions instead of Azure DevOps Pipelines. But they don't really seem to have feature parity either. Azure DevOps does feel much more "enterprisey" to me, which is beneficial for some of the stuff I'm doing with it.

New Yorp New Yorp
Jul 18, 2003

Only in Kenya.
Pillbug

Hadlock posted:

Github Actions

This or Azure Pipelines. GH Actions lacks out of the box approval workflows which makes setting up gated continuous delivery a pain in the rear end.

drunk mutt
Jul 5, 2011

I just think they're neat

New Yorp New Yorp posted:

This or Azure Pipelines. GH Actions lacks out of the box approval workflows which makes setting up gated continuous delivery a pain in the rear end.

Eh, we've just created a workflow in a project template repo that runs to setup the "environment" and the approval block. It is kind of lovely, but in the end isn't all that much of a pain.

12 rats tied together
Sep 7, 2006

The Fool posted:

I mean, for that specific scenario we just read the outputs from the hub network workspace

i am a moron posted:

I’m on my phone so can’t effortpost, but I think the difference in opinions here might be that if you’re fully leaning into TFC/TFE some of that isn’t really an issue.
Even in TFE, or with a hub module to my understanding, you declare your dependency on a module and you gain access to its outputs. You still have to, in code, take those outputs and pass them to other things like local resources or more modules. Terraform lets you pass data around freely (ish) but the only way to pass behavior around is to invoke a module.

Vulture Culture posted:

I strongly recommend, in general, not exporting complete module outputs as a single variable. [...]

a) lose the ability to reference a promised identifier as soon as it materializes,

b) you mark the entire output as sensitive/insensitive when there's a good chance you have a mix of both.

For the hidden C of terraform-docs: I don't use it, when I had to write terraform still I used the terraform language server instead. B, I never put passwords in terraform because it's not worth the labor of having to audit access to state files, and I recommend the same to anyone who asks.

I don't understand what you mean in A.

12 rats tied together
Sep 7, 2006

Extremely Penetrated posted:

Is this finally a good time for us to use EKS?
I mean, if the question is "are we running into an issue that is fundamental to ECS and is solved by EKS", the answer is a resounding No.

I want to clarify first to any of my coworkers reading this thread that I mean this in the most charitable possible way: when it comes to ECS vs EKS the default choice is ECS and there are 2 reasons to ever pick EKS: 1, you have a strong dependency on code someone else wrote, or 2, you just feel like it.

If you just feel like it, by all means, switch to helm and eks. I would probably start by investigating why helm looks easier and seeing if you can't instead make things easier for yourself with no new tools. For example:

Extremely Penetrated posted:

getting EC2 going, then editing + manually running terraform in every component's repo to get ECS up, with a PR per repo.
This seems like a really low hanging fruit that you could probably 5-10x the productivity of with some effort.

The Fool
Oct 16, 2003


12 rats tied together posted:

I don't understand what you mean in A.

If you have a module that deploys multiple resources and output the entire module as a single block, you aren't able to access any of those values unless all of those resources are deployed.

Where if you have individual outputs they become available as soon as the dependent resource makes them available.

The Fool
Oct 16, 2003


12 rats tied together posted:

Even in TFE, or with a hub module to my understanding, you declare your dependency on a module and you gain access to its outputs. You still have to, in code, take those outputs and pass them to other things like local resources or more modules. Terraform lets you pass data around freely (ish) but the only way to pass behavior around is to invoke a module.

With a workplace model, changes can be run independently and are immediately available through the workspace outputs. The consuming team runs a data call to read them.

With a module model, the consuming team needs to update their config to ensure using the new module version, and if the module deploys resources, needs to potentially account for that as well.

(Yes, I know we were talking about a data only module)

Both models have their use case, and we actually use both.

The most common use for workspace outputs is networking related, but we have a data only module that provides a bunch of environment info for the current run.

12 rats tied together
Sep 7, 2006

I think I understand but when presented with the axes of "cleaner code" but "dag walk takes longer in terraform apply due to dependency blocking" I will slam that gauge to max on the cleaner code side every time.

The Fool
Oct 16, 2003


When you're doing modules for the consumption of others making GBS threads out an entire modules worth of outputs at once usually isnt the cleaner option.

Especially with TFC/TFE good variables and good outputs are self documenting.

fletcher
Jun 27, 2003

ken park is my favorite movie

Cybernetic Crumb

Docjowles posted:

Loops and conditionals were bolted on after the language was largely “done” in the weirdest, shittiest way imaginable and despite writing terraform professionally for like 5 years I still gently caress them up or run into bizarre issues all the time.

Ugh I was dealing with this the other day. I have like 40 of these repeated in my terraform code and I could not for the life of me figure out how to just create a list variable to do it:
code:
resource "aws_ecr_repository" "my-cool-repo" {
  name = "fletcher/my-cool-repo"
}

resource "aws_ecr_lifecycle_policy" "my-cool-repo-policy" {
  repository = aws_ecr_repository.my-cool-repo.name

  policy = <<EOF
{
    "rules": [
        {
            "rulePriority": 1,
            "description": "Delete all untagged",
            "selection": {
                "tagStatus": "untagged",
                "countType": "imageCountMoreThan",
                "countNumber": 1
            },
            "action": {
                "type": "expire"
            }
        }
    ]
}
EOF
}

freeasinbeer
Mar 26, 2015

by Fluffdaddy

fletcher posted:

Ugh I was dealing with this the other day. I have like 40 of these repeated in my terraform code and I could not for the life of me figure out how to just create a list variable to do it:
code:
resource "aws_ecr_repository" "my-cool-repo" {
  name = "fletcher/my-cool-repo"
}

resource "aws_ecr_lifecycle_policy" "my-cool-repo-policy" {
  repository = aws_ecr_repository.my-cool-repo.name

  policy = <<EOF
{
    "rules": [
        {
            "rulePriority": 1,
            "description": "Delete all untagged",
            "selection": {
                "tagStatus": "untagged",
                "countType": "imageCountMoreThan",
                "countNumber": 1
            },
            "action": {
                "type": "expire"
            }
        }
    ]
}
EOF
}

For each and locals?

There is also dynamic blocks but that doesn’t fit this use case based on a quick over view

Extremely Penetrated
Aug 8, 2004
Hail Spwwttag.

fletcher posted:

Ugh I was dealing with this the other day. I have like 40 of these repeated in my terraform code and I could not for the life of me figure out how to just create a list variable to do it:


Sure, we've implemented this. Here's the lifecycle rules, we wanted ours to keep images tagged for an environment and purge the rest:
code:
variable "ecr_tags" {
  type = list(string)
  default = [
    "dev",
    "staging",
    "prod"
  ]
}

locals {
  tag_rules = [
    for env in var.ecr_tags :
    {
      rulePriority = index(var.ecr_tags, env) + 1
      description  = "keep ${env} images"
      selection = {
        tagStatus     = "tagged",
        tagPrefixList = ["${env}"],
        countType     = "sinceImagePushed",
        countUnit     = "days",
        countNumber   = 1095
      },
      action = {
        type = "expire"
      }
    }
  ]
  default_rules = [
    {
      rulePriority = length(var.ecr_tags) + 1
      description  = "Remove untagged images"
      selection = {
        tagStatus   = "untagged",
        countType   = "sinceImagePushed",
        countUnit   = "days",
        countNumber = 7
      },
      action = {
        type = "expire"
      }
    },
    {
      rulePriority = length(var.ecr_tags) + 2,
      description  = "Purge the rest of the tagged images",
      selection = {
        tagStatus   = "any",
        countType   = "sinceImagePushed",
        countUnit   = "days",
        countNumber = 30
      }
      action = {
        type = "expire"
      }
    }

  ]
  ecr_lifecycle_rules = concat(local.tag_rules, local.default_rules)
}
Then you apply them to whatever ECR repositories. Mine were made in the same state but you could use a data lookup here.
code:
resource "aws_ecr_lifecycle_policy" "components" {
  for_each   = var.repository_names
  repository = aws_ecr_repository.components[each.key].name

  policy = jsonencode(
    {
      rules = local.ecr_lifecycle_rules
    }
  )
}

freeasinbeer
Mar 26, 2015

by Fluffdaddy
For what they are trying to do I think this is what they want:

code:

locals {
  repo = [
    "repo1",
    "repo2"
  ]
}

resource "aws_ecr_repository" "repo" {
  for_each = toset(local.repo)
  name     = each.value
}

resource "aws_ecr_lifecycle_policy" "repo-policy" {
  for_each   = aws_ecr_repository.repo
  repository = each.value.name

  policy = <<EOF
{
    "rules": [
        {
            "rulePriority": 1,
            "description": "Delete all untagged",
            "selection": {
                "tagStatus": "untagged",
                "countType": "imageCountMoreThan",
                "countNumber": 1
            },
            "action": {
                "type": "expire"
            }
        }
    ]
}
EOF
}

luminalflux
May 27, 2005



fletcher posted:

Ugh I was dealing with this the other day. I have like 40 of these repeated in my terraform code and I could not for the life of me figure out how to just create a list variable to do it:
code:
resource "aws_ecr_repository" "my-cool-repo" {
  name = "fletcher/my-cool-repo"
}

resource "aws_ecr_lifecycle_policy" "my-cool-repo-policy" {
  repository = aws_ecr_repository.my-cool-repo.name

  policy = <<EOF
{
    "rules": [
        {
            "rulePriority": 1,
            "description": "Delete all untagged",
            "selection": {
                "tagStatus": "untagged",
                "countType": "imageCountMoreThan",
                "countNumber": 1
            },
            "action": {
                "type": "expire"
            }
        }
    ]
}
EOF
}

Creating ECR repos in terraform has been more headache than it's worth. we just opportunistically create the repo from CI using the aws-ecr circleci orb.

freeasinbeer
Mar 26, 2015

by Fluffdaddy

luminalflux posted:

Creating ECR repos in terraform has been more headache than it's worth. we just opportunistically create the repo from CI using the aws-ecr circleci orb.

You can also trigger a lambda on a failed docker vis cloudtrail to event bridge push to ECR to create it for you

Not mine, but a sample of someone else’s that’s very close to what my old company did: https://github.com/tradeparadigm/terraform-aws-ecr-repo-lambda

freeasinbeer fucked around with this message at 21:57 on Mar 15, 2023

The Iron Rose
May 12, 2012

:minnie: Cat Army :minnie:
Not everything that can go in terraform should go in terraform

On a related note I had to migrate 136 resources from one state file to two other state files, kill me

The source was a rat’s nest of unversioned modules on top of modules on top of modules. Sometimes you should repeat yourself, ahhhh.

The Fool
Oct 16, 2003


was something like terraformer not an option?

Hadlock
Nov 9, 2004

The Iron Rose posted:



On a related note I had to migrate 136 resources from one state file to two other state files, kill me

This seems like ideal work to hand off to a contractor

I'm not sure how to sell this angle but the next time I get assigned this trash task that's my plan. There is nothing more soul sucking in his line of work

The Fool
Oct 16, 2003


I mean, it's tedious but as long as you're not having to also make configuration changes its not too bad

luminalflux
May 27, 2005



The Iron Rose posted:

Not everything that can go in terraform should go in terraform

On a related note I had to migrate 136 resources from one state file to two other state files, kill me

The source was a rat’s nest of unversioned modules on top of modules on top of modules. Sometimes you should repeat yourself, ahhhh.

i had 6k lines of moved{} yesterday lol

The Iron Rose
May 12, 2012

:minnie: Cat Army :minnie:

The Fool posted:

was something like terraformer not an option?

Probably if I knew it existed before today! But I am changing up the structure a tad w/ some very minor config edits, and it strains credulity to imagine terraformer knows when to use a for loop over a complex map versus modularize and so on. Some simple shell scripting worked fine for the most part to handle it though.

There really is nothing more soul sucking than terraform janitoring though. Totally get why devs hate it. If it can go in application code, it probably should.

drunk mutt
Jul 5, 2011

I just think they're neat

luminalflux posted:

circleci orb.

Heh, people are still expecting to use CCI going forward and aren't moving off of it?

luminalflux
May 27, 2005



drunk mutt posted:

Heh, people are still expecting to use CCI going forward and aren't moving off of it?

i'm describing what we currently do but yeah I had a very prescient meeting yesterday morning about moving off CircleCI and what that would look like. Then later in the day their poo poo went sideways again.

fletcher
Jun 27, 2003

ken park is my favorite movie

Cybernetic Crumb

freeasinbeer posted:

For what they are trying to do I think this is what they want:

code:

locals {
  repo = [
    "repo1",
    "repo2"
  ]
}

resource "aws_ecr_repository" "repo" {
  for_each = toset(local.repo)
  name     = each.value
}

resource "aws_ecr_lifecycle_policy" "repo-policy" {
  for_each   = aws_ecr_repository.repo
  repository = each.value.name

  policy = <<EOF
{
    "rules": [
        {
            "rulePriority": 1,
            "description": "Delete all untagged",
            "selection": {
                "tagStatus": "untagged",
                "countType": "imageCountMoreThan",
                "countNumber": 1
            },
            "action": {
                "type": "expire"
            }
        }
    ]
}
EOF
}

Thanks! That looks promising, it's similar to what I had attempted previously but a little different. I wish I had saved what I tried before to compare it.

Ran into a strange error on terraform plan though, perhaps it doesn't like switching from my old way of doing things to this new way. I'll give it a shot on a fresh terraform state file to see if I can sort it out, maybe just need to blow away my existing state and then import my repos and policies into this style of doing it.

code:
Stack trace from the terraform-provider-aws_v4.58.0_x5 plugin:

panic: interface conversion: interface {} is nil, not *ecr.Repository

goroutine 387 [running]:
github.com/hashicorp/terraform-provider-aws/internal/service/ecr.resourceRepositoryRead({0xe686700?, 0xc00351c240}, 0xc004110200, {0xd1ba560?, 0xc0003cb400})
        github.com/hashicorp/terraform-provider-aws/internal/service/ecr/repository.go:186 +0x12cc
github.com/hashicorp/terraform-provider-aws/internal/provider.wrappedReadContextFunc.func1({0xe686700?, 0xc00351c240?}, 0x0?, {0xd1ba560?, 0xc0003cb400?})
        github.com/hashicorp/terraform-provider-aws/internal/provider/provider.go:810 +0x3e
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).read(0xe686700?, {0xe686700?, 0xc00351c240?}, 0xd?, {0xd1ba560?, 0xc0003cb400?})
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.25.0/helper/schema/resource.go:719 +0x87
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).RefreshWithoutUpgrade(0xc000d60540, {0xe686700, 0xc00351c240}, 0xc004114820, {0xd1ba560, 0xc0003cb400})
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.25.0/helper/schema/resource.go:1015 +0x585
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ReadResource(0xc001418168, {0xe686700?, 0xc00351c120?}, 0xc004561b80)
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.25.0/helper/schema/grpc_provider.go:613 +0x4a5
github.com/hashicorp/terraform-plugin-mux/tf5muxserver.muxServer.ReadResource({0xc00320ac60, 0xc00320acc0, {0xc004b09fe0, 0x2, 0x2}, {0x0, 0x0, 0x0}, {0x0, 0x0, ...}, ...}, ...)
        github.com/hashicorp/terraform-plugin-mux@v0.9.0/tf5muxserver/mux_server_ReadResource.go:26 +0x102
github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ReadResource(0xc001a72dc0, {0xe686700?, 0xc0034c3620?}, 0xc005174360)
        github.com/hashicorp/terraform-plugin-go@v0.14.3/tfprotov5/tf5server/server.go:748 +0x4b1
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ReadResource_Handler({0xcecb540?, 0xc001a72dc0}, {0xe686700, 0xc0034c3620}, 0xc004100070, 0x0)
        github.com/hashicorp/terraform-plugin-go@v0.14.3/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:349 +0x170
google.golang.org/grpc.(*Server).processUnaryRPC(0xc004c44000, {0xe695760, 0xc001f981a0}, 0xc005176900, 0xc0049bdfb0, 0x14dfd370, 0x0)
        google.golang.org/grpc@v1.53.0/server.go:1336 +0xd23
google.golang.org/grpc.(*Server).handleStream(0xc004c44000, {0xe695760, 0xc001f981a0}, 0xc005176900, 0x0)
        google.golang.org/grpc@v1.53.0/server.go:1704 +0xa2f
google.golang.org/grpc.(*Server).serveStreams.func1.2()
        google.golang.org/grpc@v1.53.0/server.go:965 +0x98
created by google.golang.org/grpc.(*Server).serveStreams.func1
        google.golang.org/grpc@v1.53.0/server.go:963 +0x28a

Error: The terraform-provider-aws_v4.58.0_x5 plugin crashed!

This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.

freeasinbeer
Mar 26, 2015

by Fluffdaddy

fletcher posted:

Thanks! That looks promising, it's similar to what I had attempted previously but a little different. I wish I had saved what I tried before to compare it.

Ran into a strange error on terraform plan though, perhaps it doesn't like switching from my old way of doing things to this new way. I'll give it a shot on a fresh terraform state file to see if I can sort it out, maybe just need to blow away my existing state and then import my repos and policies into this style of doing it.

code:
Stack trace from the terraform-provider-aws_v4.58.0_x5 plugin:

panic: interface conversion: interface {} is nil, not *ecr.Repository

goroutine 387 [running]:
github.com/hashicorp/terraform-provider-aws/internal/service/ecr.resourceRepositoryRead({0xe686700?, 0xc00351c240}, 0xc004110200, {0xd1ba560?, 0xc0003cb400})
        github.com/hashicorp/terraform-provider-aws/internal/service/ecr/repository.go:186 +0x12cc
github.com/hashicorp/terraform-provider-aws/internal/provider.wrappedReadContextFunc.func1({0xe686700?, 0xc00351c240?}, 0x0?, {0xd1ba560?, 0xc0003cb400?})
        github.com/hashicorp/terraform-provider-aws/internal/provider/provider.go:810 +0x3e
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).read(0xe686700?, {0xe686700?, 0xc00351c240?}, 0xd?, {0xd1ba560?, 0xc0003cb400?})
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.25.0/helper/schema/resource.go:719 +0x87
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).RefreshWithoutUpgrade(0xc000d60540, {0xe686700, 0xc00351c240}, 0xc004114820, {0xd1ba560, 0xc0003cb400})
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.25.0/helper/schema/resource.go:1015 +0x585
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ReadResource(0xc001418168, {0xe686700?, 0xc00351c120?}, 0xc004561b80)
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.25.0/helper/schema/grpc_provider.go:613 +0x4a5
github.com/hashicorp/terraform-plugin-mux/tf5muxserver.muxServer.ReadResource({0xc00320ac60, 0xc00320acc0, {0xc004b09fe0, 0x2, 0x2}, {0x0, 0x0, 0x0}, {0x0, 0x0, ...}, ...}, ...)
        github.com/hashicorp/terraform-plugin-mux@v0.9.0/tf5muxserver/mux_server_ReadResource.go:26 +0x102
github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ReadResource(0xc001a72dc0, {0xe686700?, 0xc0034c3620?}, 0xc005174360)
        github.com/hashicorp/terraform-plugin-go@v0.14.3/tfprotov5/tf5server/server.go:748 +0x4b1
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ReadResource_Handler({0xcecb540?, 0xc001a72dc0}, {0xe686700, 0xc0034c3620}, 0xc004100070, 0x0)
        github.com/hashicorp/terraform-plugin-go@v0.14.3/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:349 +0x170
google.golang.org/grpc.(*Server).processUnaryRPC(0xc004c44000, {0xe695760, 0xc001f981a0}, 0xc005176900, 0xc0049bdfb0, 0x14dfd370, 0x0)
        google.golang.org/grpc@v1.53.0/server.go:1336 +0xd23
google.golang.org/grpc.(*Server).handleStream(0xc004c44000, {0xe695760, 0xc001f981a0}, 0xc005176900, 0x0)
        google.golang.org/grpc@v1.53.0/server.go:1704 +0xa2f
google.golang.org/grpc.(*Server).serveStreams.func1.2()
        google.golang.org/grpc@v1.53.0/server.go:965 +0x98
created by google.golang.org/grpc.(*Server).serveStreams.func1
        google.golang.org/grpc@v1.53.0/server.go:963 +0x28a

Error: The terraform-provider-aws_v4.58.0_x5 plugin crashed!

This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.

🤔 I have zero idea why it’s spitting that out but I did actually run it to confirm it worked prior to posting.

fletcher
Jun 27, 2003

ken park is my favorite movie

Cybernetic Crumb

freeasinbeer posted:

🤔 I have zero idea why it’s spitting that out but I did actually run it to confirm it worked prior to posting.

Thank you for even going as far as testing it out! Much appreciated

12 rats tied together
Sep 7, 2006

there is a pretty good discord link over in this post https://forums.somethingawful.com/showthread.php?threadid=3753052&pagenumber=393#post530539723 and we have a reasonably active cloud yelling channel in it, where questions of this nature and other types of terraform yelling are always on topic

Adbot
ADBOT LOVES YOU

gnatalie
Jul 1, 2003

blasting women into space

Feral Integral posted:

What's the latest poo poo people are using for CI these days? Last thing I worked on was jenkins and a bunch of plugins

teamcity for onprem, gh for cLoUD. no complaints about either

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply