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.

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

[Discussion] User input Parameters #2

Open
dekz opened this Issue Sep 24, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@dekz
Copy link

dekz commented Sep 24, 2015

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

This comment has been minimized.

Copy link
Member

doapp-ryanp commented Sep 24, 2015

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:

  • We expose an extension point in awsm.json that is for interactive user input (we leverage the JAWSCli class prompting code). This extension point will define a replacement token in your 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"]
...
  • Note the env var defn in the resource/action(s) awsm.json file(s). We could write some code that after prompting the user would then optionally go off and use the jaws env command to set this env with the value they put in for all stages

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

@dekz

This comment has been minimized.

Copy link
Author

dekz commented Sep 24, 2015

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

This comment has been minimized.

Copy link
Member

boushley commented Sep 26, 2015

@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

This comment has been minimized.

Copy link
Member

boushley commented Sep 26, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.