Replies: 2 comments 2 replies
-
@alimanfoo totally agree that this does make the stages hard to run manually. There are two reasons we have resisted adding the tf vars as files:
That said it definitely would not be hard to add a command line option to output the variables as well and I wouldn't be opposed to that. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I've been trying to learn more about how nebari works by browsing through the rendered infrastructure code in the "stages" directory. One thing I found confusing initially is that the rendered infrastructure code is not actually complete, because it doesn't include the terraform input variable definitions files (.tfvars.json).
Because these files aren't present, it's hard to build a complete picture of how the nebari config files is translated into infrastructure code. It's also harder to tinker with the infrastructure code, because you can't cd into one of the stages sub-folders and run terraform CLI directly.
Looking at the nebari source code I see that the terraform variable definitions files are not written during the rendering step, but are written during deployment. I also see that they are written as temporary files.
Can I suggest that the input variable definitions files are not written as temporary files, but instead are written as normal files. E.g., if they were written to files named "terraform.trvars.json" within the stages sub-folders alongside the rest of the terraform code, that would be natural. I believe terraform would then automatically see and use them, so would even remove the need to add them as cli "-var-file" parameters.
Can I also suggest that the variable definitions files be written during by the nebari render command, rather than only being written during the deploy command. This would create a clear separation between rendering of complete infrastructure code, and then deployment. This separation is potentially nice for a power user of nebari because it can help to learn more about how nebari works, and provides a mechanism to tinker with the generated infrastructure code and potentially patch or alter it prior to deployment, which could be a nice way to make experimentation easier.
Beta Was this translation helpful? Give feedback.
All reactions