Import feature

[eymerich]

Hello, I have a question about importing. I was trying to test a way to "recover" a missing status, starting from a very simple stack defined in a .tf file with method = "string" and stack_file_content.

When importing it back, the stack importer doesn't seem to set any method metadata (or at least that's how it appears to me when examining the code). As a result, after the new state has been set, the following plan/apply triggers a stack rebuild by flagging that property as:

+ method = "string" # forces replacement

I tried to tinker with the source code by setting up a compatible method (matching my .tf configuration) like: d.Set("method", "string") in resource_stack.go. This seems to avoid the issue mentioned above.

I was wondering if this stack replacement behavior is an intentional project design choice, or if there's something behind this decision. Alternatively, would it be more appropriate to set up a method that equals the source .tf configuration I'm importing the resource from? For the latter approach, I wasn't able to reference the original method from my script through the d *schema.ResourceData function parameter.

Perhaps a side effect of #41 ?

[grulicht]

Hi @eymerich ,
thanks a lot for using the Portainer Terraform provider and for taking the time to report this issue – your detailed reproduction and example repo are super helpful! 🙌

We're investigating the root cause and will include a fix in one of the upcoming releases. We'll make sure to notify you once it's available. 🚀

[grulicht]

Hi @eymerich ,
New release version v1.12.2 with patch is out! 🙌🏽

Example usage for terraform import:

terraform import portainer_stack.standalone_string 3-4-standalone-string

[eymerich]

Great! thank you for the quick fix :)