-
Notifications
You must be signed in to change notification settings - Fork 28
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
Accept scripts without requiring additional Base64 encoding #91
Comments
@0x2b3bfa0 I think is not a great idea. |
Ideally, performing the following modification to the pertaining template line would be enough on the CML side: |
@0x2b3bfa0 Its breaking CML but also basic terraform provider. Now the TPI is not accepting the base64 encoded script. |
@0x2b3bfa0 one of the main reasons also is that base64 is far more robust than this heredoc. It's terribly painful to make this work through a template |
Users have been able to use custom script in Azure and AWS in base64 so we are not worse! |
@DavidGOrtega, given that the provider still is in its early stages of development, I think that we can afford introducing this change without breaking anything. As stated above, CML wouldn't have to use the here document syntax and can continue to provide scripts in Base64 to avoid string escaping issues. |
Follow-up of iterative/cml#168Currently, |
@0x2b3bfa0 @DavidGOrtega |
Because Terraform has an inbuilt |
Yeah (obviously 😬 ) but not sure I follow what are you suggesting wrt the choice of whether to expect file contents encoded or not (meaning: from the user). |
I propose1 to accept raw scripts in both Currently,
Expecting only raw scripts doesn't “take away any benefits”, it just avoids polluting the API with a redundant argument. See the collapsed comment below for some examples. Footnotes |
This comment was marked as outdated.
This comment was marked as outdated.
@0x2b3bfa0 - due to this I suggest to think whether it's beneficial to drop the b64 encoded field support. Hence the suggestion to have both co-exist.
|
See #91 (comment); |
When using variable "input" {
}
output "output" {
value = base64decode(var.input)
} terraform apply -var input="$(base64 input)" |
With the risk of repeating the point a bit 😄 Agreed the I don't think that this startup_script = base64decode("{{startup_script_base64}}") is an equally convenient alternative to this: startup_script_base64 = "{{startup_script_base64}}" And saving the user the need to convert their input is a good perk UX wise, when hitting a common use cases, and if I catch the drift here, it can be very common. It might be worth "polluting the api" with another (optional) field. Same thing in CLI This might save the users a few minutes scratching their heads building the tf config and the code/commands around it, and more importantly, keeping terraform configs as flat+simple as possible on the user end, so they can debug their inputs outside of terraform and get full easy visibility to what the provider gets as inputs / vars. |
I'm also leaning towards this
|
If we're talking of existing Terraform power users, it looks like we have irreconcilliable differences with regard to their alleged expectations. ⚔️ 😅
Neither do I: to my mind, the former is much more convenient both for users and for ourselves. 😈
Providing a Base64–encoded script is not a valid2 use case, unless proven otherwise. It's just something we do internally on CML to avoid the need of escaping our runner templates. If this argument accepted arbitrary binary data (as opposed to UTF–8 text), it would make sense to use Base64 as the only/preferred input format, but this is not the case. This argument is not mapped to the cloud–init user data value read by cloud instances. It's just being injected into a bigger templated script, and providing binary data wouldn't have other effect beyond upsetting the shell interpreter: terraform-provider-iterative/iterative/resource_runner.go Lines 340 to 342 in 2dd6c60
Moreover, the current approach is doubly inconvenient: the primary3 consumer of the Currently, this option “run[s] the provided Base64-encoded Linux shell script during the instance initialization”, so users have4 to execute User DataJust for reference, the official AWS provider accepts both forms, exactly like in your proposal, although other providers only take plain text.
Footnotes
|
Indeed, it might be nice to reduce the ambiguity, by aligning their behavior 😄 |
Given the status of the current API, this can be safely demoted to p2-nice-to-have and will be addressed tangentially when reworking the |
I think this can just be closed.
|
I thought this issue about allowing |
even if it is, that shouldn't require any changes to tpi like has been discussed in this thread. There is already a related issue on cml to accept a file for that parameter. plaintext, base64, or file don't need different interfaces in the terraform scheme for the |
iterative/cml#1167 indeed |
Terraform support for heredocs and files would play nicely with literal scripts and wouldn't require users to encode them in advance or resort to file and string encoding functions. We might still use the latter internally for foolproof escaping of templated files, but users should be able of writing plain scripts manually.
The text was updated successfully, but these errors were encountered: