Hi all, thank you for welcoming me and for the gre...
# atmos
l
Hi all, thank you for welcoming me and for the great work you are doing 🙂 I'm here because I need help with my Atmos configuration. I'm using Atmos 1.198.0 to create the infrastructure in AWS via Terraform. In my setup I'm using S3 backend, I have the terraform workspace disabled and the key set to something like <stack name>/<atmos component>.terraform.tfstate. I'm using the function !terraform.output to retrieve the id of some components (for example in the EC2 I use it to get the Id of the security groups) and everything works correctly. However, for performance reasons, I want to use the !terraform.state function, but this function cannot read the state from the backend. From the logs, it appears that even though the workspace is disabled, when the function tries to read the state from the S3 bucket, it looks in the wrong path, specifically at _<workspace_key_prefix>/default/<stack name>/<atmos component>.terraform.tfstate._ Given that when workspaces are disabled and the default one is used, the function should not append either the workspace_key_prefix or the workspace name so that its behavior aligns with Terraform. Is there a way to force this behavior, or is something being misconfigured? I also tried to upgrade Atmos to the latest version (1.202.1), but the behavior remains the same. With this version, however, it seems there are some authentication-related issues. I'm using Atmos internal authentication with AWS SSO configured as the provider. When I run a command such as atmos describe component an error like panic: authContextWrapper.GetChain should not be called is thrown. From the debug logs, the error seems related to the !terraform.output function, specifically when it tries to create the AuthManager for one of the nested components. The !terraform.state function instead does not have this problem. May someone help me on resolving these issues? Thanks a lot 🙂
e
Hey there! Welcome 🎉
Regarding the panic can you please create a GitHub issue for that - it shouldn't happen
Regarding using state with workspaces disabled, that should work, and what you describe sounds correct. But I think we also lack documentation on this use-case and should improve it.
From what you describe maybe the state function was not tested with workspaces disabled - and that gives us something to go on.
Could I trouble you to open an issue for this? We’ll promptly look into it
l
Hey, thanks for the response 🙂 I've created the following github issues https://github.com/cloudposse/atmos/issues/1921 https://github.com/cloudposse/atmos/issues/1920 Please let me know if they are fine or if I have to modify/add something
🙏 1