Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Ability to include external file contents in cli parameters json #1803

Closed
tpakula-fender opened this issue Feb 18, 2016 · 10 comments
Closed

Ability to include external file contents in cli parameters json #1803

tpakula-fender opened this issue Feb 18, 2016 · 10 comments
Labels
closed-for-staleness feature-request A feature should be added or improved. needs-discussion

Comments

@tpakula-fender
Copy link

For instance, to create a new CloudFormation stack, I would like to do something like

aws cloudformation create-stack --cli-input-json file://mystack.cliparameters

where the contents of mystack.cliparameters is

{ "TemplateBody": "file://mystack.cloudformationtemplate", "Parameters": [ { "ParameterKey": "UserDataParam", "ParameterValue": "file://userdata.sh", "UsePreviousValue": false } }

mystack.cloudformationtemplate then contains the actual CloudFormation template, and userdata.sh contains the script used to bootstrap the instance at launch time.

Currently, I have to do

aws cloudformation create-stack --cli-input-json file://mystack.cliparameters --template-body file://mystack.cloudformationtemplate

...and specify the userdata explicitly within mystack.cliparameters which can get very messy with newlines if the userdata script is more than just a few lines.
@jamesls
Copy link
Member

jamesls commented Feb 25, 2016

There was a similar request a while back here: #1097

In that scenario, they wanted to be able to specify binary contents as a value, which isn't possible in a JSON document. The most reasonable way to do this would be to reference a file in the JSON document.

We've explored several options, but the main constraint we're running into is that we'd need this to be backwards compatible.

The solution you've proposed could work. However, if there's existing users that want to specify the literal string value of file://mystack.cloudformationtemplate and we change this behavior to now interpret this as mean "insert the contents of this file", this will be a breaking change.

Another solution proposed was to support something besides JSON. YAML would allow for custom tags (i.e !file), one of which could be a "file" tag. Another option would be to extend JSON to support something like:

{"foo": file:///path/to/file}     # Note there's no quotes around the file path
{"foo": File("/path/to/file")}

If we can come up with something that's backwards compatible, I think this is something we should do.
I'm interested to hear what others have to say.

@jamesls jamesls added feature-request A feature should be added or improved. others-chime-in labels Feb 25, 2016
@tpakula-fender
Copy link
Author

Ahh, I see where my suggestion might break things. CloudFormation itself does something like the JSON extension you've proposed, so maybe similar to the following in the CLI parameters JSON:

{ "ParameterKey": "UserDataParam", "ParameterValue": { "Fn::ExtFile": "/path/to/file" } }

Bonus: the door is then open to adding other functions without breaking backwards compatibility by introducing new.

@jamesls
Copy link
Member

jamesls commented Feb 27, 2016

Very interesting idea. If we only apply this for scalar values (strings, integers, booleans, floats), then it should be entirely backwards compatible. Previously the value had to be a string, so providing a dictionary type would cause a validation error, so all we would do now is pre-process the data, look for the {"Fn::ExtFile" ....} where a string type was previously used and replace that value with a string.

@jamesls jamesls mentioned this issue Mar 11, 2016
Open
@hsupu
Copy link

hsupu commented Jan 5, 2017 •
edited
Loading

Could this bug be fixed soon? It has exists for one year.

I found this issue from https://forums.aws.amazon.com/thread.jspa?threadID=225033

@ASayre
Copy link
Contributor

ASayre commented Feb 6, 2018

Good Morning!

We're closing this issue here on GitHub, as part of our migration to UserVoice for feature requests involving the AWS CLI.

This will let us get the most important features to you, by making it easier to search for and show support for the features you care the most about, without diluting the conversation with bug reports.

As a quick UserVoice primer (if not already familiar): after an idea is posted, people can vote on the ideas, and the product team will be responding directly to the most popular suggestions.

We’ve imported existing feature requests from GitHub - Search for this issue there!

And don't worry, this issue will still exist on GitHub for posterity's sake. As it’s a text-only import of the original post into UserVoice, we’ll still be keeping in mind the comments and discussion that already exist here on the GitHub issue.

GitHub will remain the channel for reporting bugs.

Once again, this issue can now be found by searching for the title on: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-The AWS SDKs & Tools Team

@ASayre ASayre closed this as completed Feb 6, 2018
@salmanwaheed
Copy link

salmanwaheed commented Feb 6, 2018 via email

@salmanwaheed
Copy link

salmanwaheed commented Feb 6, 2018 via email

@jamesls
Copy link
Member

jamesls commented Apr 6, 2018

Based on community feedback, we have decided to return feature requests to GitHub issues.

@jamesls jamesls reopened this Apr 6, 2018
@TRT-GruffM
Copy link

This is still an issue 2 years on. Perhaps your backlog management needs looking at.

@github-actions
Copy link

Greetings! It looks like this issue hasn’t been active in longer than one year. We encourage you to check if this is still an issue in the latest release. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or upvote with a reaction on the initial post to prevent automatic closure. If the issue is already closed, please feel free to open a new one.

@github-actions github-actions bot added closing-soon This issue will automatically close in 4 days unless further comments are made. closed-for-staleness and removed closing-soon This issue will automatically close in 4 days unless further comments are made. labels Sep 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
closed-for-staleness feature-request A feature should be added or improved. needs-discussion
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@jamesls @hsupu @ASayre @tpakula-fender @salmanwaheed @diehlaws @TRT-GruffM