-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move current terraform into a GCP specific module #514
Conversation
## Cloud provider abstractions | ||
|
||
We will use completely different terraform code for each cloud provider, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would love to know what you think of this, @consideRatio @damianavila @sgibson91 @GeorgianaElena
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is similar to what I was thinking about over lunch. Each cloud provider we deploy to via terraform has it's own submodule, and we have a top-level variable like cloud_provider
that we use in some logic to import the correct module when doing a terraform plan/apply. It means more code to maintain, but as of yet I don't know of a more elegant solution and terraform isn't a truly cloud-agnostic tool (it's dependent on the provider).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each cloud provider we deploy to via terraform has it's own submodule, and we have a top-level variable like cloud_provider that we use in some logic to import the correct module when doing a terraform plan/apply.
I tried this, and unfortunately you can't use a variable to specify which module to load in terraform :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Boo! :( In which case, I think this solution is good enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if @andersy005 or @cmd-ntrf with significant experience with terraform could comment about this for us? Anderson and Félix, do you think it is a reasonable approach to have separate terraform code for deploying infrastructure to separate cloud providers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a sensible proposal. Since terraform is not agnostic from the cloud provider I think any attempt to make that happen will look-like weird and, most likely, difficult if not impossible to do it in a sane way. But, hey, I do not have a lot of experience with terraform and I might be missing something...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM from what I can tell and feel comfortable relying on @yuvipanda's judgement given that it has been explicit deliberation on the decision regarding making room for separate terraform code for different cloud providers.
I went ahead and made some off topic adjustments to the URLs 🙉
Co-authored-by: Erik Sundell <erik.i.sundell@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I said in the specific comment, I think this is a sensible idea.
I think this has enough approval to be merged? |
@sgibson91 this might require you to rebase some of the terraform code you are working on wrt private clusters |
We will use completely different terraform code for each cloud provider,
under
terraform/<cloud-provider>
. This is much simpler than trying to abstractthem away into a 'lowest common denominator' set of modules.
Ref #512