Question/Feature Request: How to handle "overriding" environment specific parameters

[tiny-dancer]

Hey all,

We're in the need of using parameter store for environment specific credentials (from within the same account).

What would be the recommendation for handling this?

Off hand, two potential approaches could be:

Path-based (enhancement)

/{service}/environment-{environment}

the environment would be an optional override parameter only taking into account when the environment- prefix is used, therefore existing functionality should remain the same.

For example with the below params:

• /A/bob = baseExample
• /A/environment-prod/bob = prodExample

When retrieving for, the value would be:

• Service A, environment dev: baseExample
• Service A, environment prod: prodExample

Service-based:

/{service-environment}

The downside of this approach is the lack of ability to provide a "base" parameter that is constant across all environments without implementing the logic client side.

Thanks!

[nickatsegment]

For SSM backend, we use separate AWS accounts. I'm going to assume you've considered doing but can't.

The path-based solution I believe is essentially the same as the idea of prefixes or namespaces from #128, except for some minor differences. That said, 3.x is not on our radar for the near future.

The service-based approach you could implement yourself with a shell script, but I understand that having it baked into chamber would be easier. You might consider forking chamber in the meantime, adding a required environment flag or something.

[stale]

This issue has been automatically marked stale because it has not had any activity in the last 60 days. If no further activity occurs within 7 days, it will be closed. Closed does not mean "never", just that it has no momentum to get accomplished any time soon.
See CONTRIBUTING.md for more info.

[stale]

Closing due to staleness. Closed does not mean "never", just that it has no momentum to get accomplished any time soon.
See CONTRIBUTING.md for more info.