Open dekz opened 8 years ago
I really like this idea.
So for your specific example - the dynamodb table name - The table name must be defined in CloudFormation resources, so your awsm mod would expose this resource in awsm.json:resources.cloudFormation.Resources
. HOWEVER as you state, the user should have control over the name AND your code needs to know this name.
Here is an initial proposal to get the ball rolling:
awsm.json:resources.cloudFormation.Resources
that will be replaced before injection into project. Ex:...
"cloudFormation": {
...
"Resources":{...},
"userInputs": {
"JAWS_USERS_DT_NAME": {
"type":"string",
"default":"users"
}
}
}
awsm.json
in resource/action
dir
...
"envVars":[ "JAWS_USERS_DT_NAME"]
...
jaws env
command to set this env with the value they put in for all stagesObviously alot more thought needs to be put into this, but just an idea
Yeah this sounds like a really good start.
Maybe this is also related, but when a resource is created I don't not know its full ARN, I can wild card it but that be error prone.
For example in here I want to update the IAM Role with the new resource created.
I almost want a reference to that resource ARN described a few lines later.
@dekz too bad GetAtt
doesn't support Dynamo DB ARN.
@doapp-ryanp That sounds like a good proposal. When do you see prompting for these values? If we prompt on module install
then we would need to prompt for inputs for each stage, and then we would need to prompt on stage creation for all of the values.
Seems like it might be best to prompt for these values on Deploy. To that end it might be best to make the replacement syntax a bit more unique to try and avoid conflicts.
Also seems like it might be helpful to store the answers to these questions in the jaws.json
file inside of the stage, and do the substitution when running deploy resources
. This would make it easier to change values, especially if the value is used in multiple locations in the CF template.
This is definitely something we need to figure out though, every module I've thought of creating so far needs this.
Also, we should consider whether we can avoid creating our own substitution mechanism. Would be cool to just use CloudFormation parameters for this.
We specify in awsm.json
that we have certain parameters, that way the CLI can know to ask the user and allows us to give a description or context of some sort. Then in our CloudFormation snippet we can assume there is a parameter with the name we provided.
We could then store a set of parameters for each stage, and maybe even allow using env variables if the names match. Using environment variables would be great for something like Dynamo Table where you want to specify it in the Resources template and in the code.
Thoughts on using CloudFormation parameters for this?
Thoughts on using environment variables as the storage mechanism for this? Maybe not the only storage mechanism, but might be a good enough start.
Currently I can supply additional CloudFormation resources in an Awsm module. For example a DynamoDB resource. I do not want to dictate the Table Name and would prefer the input to come from the user either during
jaws module install
orjaws deploy resources
.Do you have any thoughts on exposing Parameter References to allow configuration? Perhaps similar to
envVars
for a lambda?An example of this would be the DynamoDB table name perhaps. Or the number of RWThroughput.