search

displague / deprecated-terraform-provider-linode

[OLD] Terraform provider plugin for Linode Cloud resources.. See
https://github.com/terraform-providers/terraform-provider-linode
Mozilla Public License 2.0
15 stars 5 forks source link

support random root password #17

Closed akerl closed 5 years ago

akerl commented 6 years ago

This is just a first pass to unblock my current workflow.

Without this, I can't push my statefile to a github repo because it ends up containing the temp password.

displague commented 6 years ago

@paddycarver What are your thoughts on this? I would also enjoy an option to disregard a hand-crafted root_pass requirement. I understand that persistence must be maintained between state comparisons, and the word "random" would provide that in this case.

Would Hashi recommend an approach more like https://www.terraform.io/docs/providers/random/r/string.html ( more details here, https://www.terraform.io/docs/providers/random/index.html )?

@akerl As I go through #16 and successive reviews, I will likely remove the legacy linode_linode options that the @btobolaski APIv3 provider supported in favor of linode_instance fields and conventions that match the Linode APIv4 naming and structural conventions, more than the changes that exist in the provider today. These changes will be coming soon and seek to remove wizard-like elements of the resource in favor of representing the cloud provider API in a stateful way. (I've invited you to #linodego on the Gophers Slack)

displague commented 6 years ago

@akerl I updated the examples (and the examples README.md) to show the use of the random provider https://github.com/displague/terraform-provider-linode/blob/master/examples/main.tf#L149 (it takes an extra step when running from the development plugin directory).

Is your approach preferable because the random password is not stored in state?

akerl commented 6 years ago

Yea; in my case I'm storing the TF and state in a github repo, so having the password land in state is problematic. In theory I could just change the password w/ a provisioner, but that feels crufty?

I'm a big fan of the idea of just not having root PW be a required field 😄

cliedeman commented 6 years ago

Looks like this pain point has been around for a long time. It seems the current solution aside from workarounds is to use one of the state backends.

Won't making the root password optional and creating a random one not stored in state make it extremely easy to lose the root password? Could be very confusing behaviour for a new user.