Isn't Chamber supposed to split Parameter Store variables ?

[rom1gal]

Hi all,

Based on this documentation and some others found on the Internet, I really thought Chamber was able to split a given parameter into an environment variable, no matter how many levels of / we have.

For instance, according to the documentation chamber exec production -- program with a parameter like /production/mysql/password would set a MYSQL_PASSWORD environment variable. However it seems it is not the case : you need to specify each parameter path until the last / : chamber exec production/mysql -- program to get a MYSQL variable using the same example.

In my case I have many parameter with undefined path sizes /production/myvar but also /production/partnerA/username but I do not want to feed chamber with production and production/partnerA but only production yet having MYVAR and PARTNERA_USERNAME...

Is my understanding of how chamber works is correct ?

Thanks in advance !

[bhavanki]

I haven't been involved in this project previously, but would like to respond. (I'm a Segment employee.)

I spent some time poking around with chamber and the SSM parameter store, and it seems that when the name of an SSM parameter is a path, then all but the last component of the path is considered the service name, and only the last component is the key. So, a parameter name "alpha/beta/gamma" is interpreted by chamber as a secret with key "gamma" for the service "alpha/beta".

The interpretation is consistent from what I have seen. So, extending the example, chamber list alpha would not include the secret stored in "alpha/beta/gamma", but chamber list alpha/beta would. Also, chamber exec alpha wouldn't include anything for our parameter, but chamber exec alpha/beta would define a GAMMA environment variable.

So, I can only conclude that the passage in the linked AWS blog post is incorrect, at least based on how chamber works today, five years later. Maybe it worked differently at the time of writing. I also think that the chamber README needs to explain this, as right now it pretty much says nothing.

Despite all that, I think the use case described here is valid. I was thinking that a --recursive option (maybe restricted to the SSM storage option) for commands like list, exec, and possibly export would do the trick.

An alternative for the desired effect on environment variable names is to use a key name with '.' as a separator. So, to get a variable named MYSQL_PASSWORD under "production", use a chamber key of mysql.password. In SSM, that leads to a parameter named production/mysql.password, and it'll show up when working with the "production" service.

chamber write production mysql.password tiger