Plannable Import: Don't fail, but create resource, if not exist
### Terraform Version ```shell Terraform v1.5.2 ``` ### Use Cases In our CI/CD system, I want to import resources, that eventually already had been created. If they do not exist, terraform could safely create them using the existing configuration. My concrete example: I have some (AWS) Lambda functions, that had been created by terraform. When being executed for the first time, the functions will create a LogGroup with the function name in CloudWatch. Unfortunately, the default config for these LogGroups doesn't fit our needs (e.g. no log retention being set). When I add the LogGroup to the terraform configuration, applying will fail in most (but not all!) cases, because it tries to create the LogGroup with the existing name. ### Attempted Solutions In similar situations, we added some commands before doing the "apply" and imported the resources using the CLI import command or just deleted the resource. The new `import` block would be a game changer for us... Thanks to CDKTF, as a workaround we can make the "import" block optional and check the existence of the resource using AWS API. ### Proposal I see two possible ways to tackle this: 1. Flag in the CLI, which allows to ignore "Cannot import non-existent remote object" errors 2. Optional property in the "import" block, which tells terraform how to proceed, when resource does not exist. Option 2 feels best for me, because the behavior can be configured individually for each resource/import. The config could look
Posted by DJAlPee on Aug 4, 2023, 9:49 AM
Tags
Related issues
- The issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).
- I probably could have beared with it if it was only limited to programming, but it showing up in creative fields has made me feel all sor...
- I hate that I'm in deep enough to know what you mean.
- The biggest problem with “AI” is that big corps are shoving it down our throats.
- in the middel of a coding session with 5.6 sol.
- [Hero Run] 535B-A23B on 18T tokens
Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments
reliability (Other)
The issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).
I probably could have beared with it if it was only limited to programming, but it showing up in creative fields has made me feel all sor...
I hate that I'm in deep enough to know what you mean.
The biggest problem with “AI” is that big corps are shoving it down our throats.
in the middel of a coding session with 5.6 sol.
[Hero Run] 535B-A23B on 18T tokens
I hate that this is how AI is being used..
inexperienced protobuf user here -- why do non-googlers generally use protobuf?
Plannable Import: Don't fail, but create resource, if not exist
### Terraform Version ```shell Terraform v1.5.2 ``` ### Use Cases In our CI/CD system, I want to import resources, that eventually already had been created. If they do not exist, terraform could safely create them using the existing configuration. My concrete example: I have some (AWS) Lambda functions, that had been created by terraform. When being executed for the first time, the functions will create a LogGroup with the function name in CloudWatch. Unfortunately, the default config for these LogGroups doesn't fit our needs (e.g. no log retention being set). When I add the LogGroup to the terraform configuration, applying will fail in most (but not all!) cases, because it tries to create the LogGroup with the existing name. ### Attempted Solutions In similar situations, we added some commands before doing the "apply" and imported the resources using the CLI import command or just deleted the resource. The new `import` block would be a game changer for us... Thanks to CDKTF, as a workaround we can make the "import" block optional and check the existence of the resource using AWS API. ### Proposal I see two possible ways to tackle this: 1. Flag in the CLI, which allows to ignore "Cannot import non-existent remote object" errors 2. Optional property in the "import" block, which tells terraform how to proceed, when resource does not exist. Option 2 feels best for me, because the behavior can be configured individually for each resource/import. The config could look
Comments (0)
No comments yet. Start the discussion.