awsm-org / awsm

AWSM: Amazon Web Services Modules – Re-usable, standardized and optimized Lambda functions ready for deployment and easy installation into serverless projects
170 stars 12 forks source link

[Discussion] User input Parameters #2

Open dekz opened 8 years ago

dekz commented 8 years ago

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 or jaws 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.

doapp-ryanp commented 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:

...
"cloudFormation": {
  ...
  "Resources":{...},
  "userInputs": {
    "JAWS_USERS_DT_NAME": {
      "type":"string",
      "default":"users"
    }
  }
}

awsm.json in resource/action dir

...
"envVars":[ "JAWS_USERS_DT_NAME"]
...

Obviously alot more thought needs to be put into this, but just an idea

dekz commented 8 years ago

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.

boushley commented 8 years ago

@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.

boushley commented 8 years ago

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.