Naming conventions for AWS Systems Manager parameters

[Nightsphere]

A consistent naming convention is need for each parameter in the AWS Systems Manager (SSM). This will help keep each account type easily separated and simpler to keep track of as more accounts are created.

After looking through the SSM dashboard, I believe there are 2 options we have for accomplishing what we want:

1. Add a path to the parameter with the param type as a 'folder' name. SSM parameter names are not unlike S3 bucket names, in the sense that there is no explicit hierarchy, but the parameter name can have forward slashes to simulate it. This would look like something like: /user-pool/infomapper/individual/individual-name, or /user-pool/infomapper/organization/org-name /user-pool/infomapper/community/community-name

2. Add a property to the parameter that describes the parameter type. This has already been done with the addition of the "name" property to each parameter. The name property will be used to display the account name in a non-sluggified, more human readable form on the InfoMapper Builder's sign in page. The same could be done with a property name of "accountType" with a value of "individual", "organization", or "community".

[smalers]

As discussed verbally, I think it may be better to use mixed cases so that sluggifying the property does not mangle names badly. AWS policies and other data also seem to use mixed case so it would be possible to cross-reference consistently. It is also important to retain some level of scoping where appropriate. Therefore, the syntax might look like:

/UserPool/InfoMapper/Individual/JoeSmith
/UserPool/InfoMapper/Organization/OpenWaterFoundation
/UserPool/InfoMapper/Community/SomeCommunity

The above would allow the same account name to be used in different types, should that be necessary, whereas omitting the account type from the property name would not allow.

As for what is actually being stored, we need to get clear on the use of System Manager. Are they called "parameters", "properties", "keys"? The general term "properties" seems most clear to users. I suggest that Josh create documentation describing the properties that are going to be stored in the system manager, for example as below. This format has worked well in other documentation.

Property (path)	Description	Default
/UserPool/InfoMapper/Individual/JoeSmith	Contains what? It seems that additional information is needed in the property name, as per the next row.
/UserPool/InfoMapper/Individual/JoeSmith/SomeThing	What is it?	None - must be specified.

Also, the developer documentation needs to be clear on whether these properties are accessed only by the service account. How does System Manager keep the "hash tables" separate from each other? Will there be private data that needs to be protected from each account/user?

Also, need to think about how configuration data will be listed. For example, what is done to list all accounts? Is there a way to get properties matching /UserPool/InfoMapper/*/*, for example?

[Nightsphere]

According to AWS, the entire name (for example) "/UserPool/InfoMapper/Individual/JoeSmith" is the name of the Parameter. The parameter object itself contains some metadata fields such as Type, Tier, Description, etc.

Another one of these fields is called "Value"; This is also a string, but we can give it a JSON string and provide any of our own properties we want to it. These properties in the Value field is what will be used by the code to differentiate different User Pools. I agree with the use of the word properties, and will refer to them as such in the documentation.

The tables are kept apart by each Parameter name being unique, so there can only be one "/UserPool/Infomapper/Individual/JoeSmith". Steve and I talked about how to deal with multiple Joe Smiths by appending a number to the Parameter name. There shouldn't be any private or sensitive data stored in the Parameter store.

The GetParametersByPathCommand from the SDK and the get-parameters-by-path command from the AWS CLI allows the option to recursively obtain all Parameters from a 'path' in the Parameter store. For example, using the path "/UserPool/Infomapper/Individual/" with the recursive option would return all Individual account Parameters.

All given Parameter properties are provided as a JSON string in the Parameter "Value" property, and could be obtained once the necessary Parameters are acquired using the commands above.