Don't override existing parameters

[sjparkinson]

[failed] create change set custom/oar-ecs-cluster/eu-west-1/ecs-cluster
An error occurred (ValidationError) when calling the CreateChangeSet operation: Parameters: [NexusDockerAuth] must have values

We've manually set a NoEcho parameter because it contains a secret key. As your documents highlight, we shouldn't commit the value to configuration.

It'd be really helpful if sceptre didn't try and override parameter values if they are not provided, that way we can just lean on the values stored in AWS.

Currently we'd have to fiddle around with CLI arguments and must then store secrets in both AWS and wherever we're running secptre.

[sjparkinson]

i.e. mimic the existing functionality available via the AWS CloudFormation console.

[et304383]

Seems similar to #77 which the authors have rejected (incorrectly IMO).

This is absolutely a valid request and it would be nice if we could specify a default value for any field in the config to be "use previous value" somehow.

[sjparkinson]

Thanks for highlighting that!

[jk2l]

+1 from “use previous value”

Without this support it’s makes scepter much less flexible than aws cli

[sjparkinson]

One thing we've tried was defining a Default value. However when we deploy, that value overrides any existing values in the stack if no parameters are defined in the sceptre configuration.

[njsnx]

It seems like an option here would be to check if a Parameter exists in the template but doesn't exist in stack config, assume that the existing value it already has (on stack updates) should be used.
Another Option might be in stack config to supply something like NoEcho or something similar to the Parameter Key's value than when the config is parsed, it can see this and check there already is a value.

Another nice idea would be to have the Parameter value to be set by asking for input when launch-stack is run but when it comes to update-stack commands, it uses existing values unless supplied via arguments. This would work nicely in pipeline scenarios.

[et304383]

I'd rather not have to edit stack config after a create stack call.

I'd rather be able to somehow specify an update stack value of use previous. This should be a simple interface.

If create, here's the value
If update, use previous

[mtb-xt]

+1 on supporting 'use previous value' - my use case - creating RDS clusters.
Imagine a template with two parameters set from env variables - db password and db snapshot to create aurora cluster from.
I don't want to specify the password and the snapshot every time I need to update my cluster, and I don't want to hardcode those parameters either, for security and reusability reasons.

On a side note - sceptre makes it very hard to have these parameters dynamic - if I use 'user variables' in my environment config, then even a describe-env command will fail with a cryptic error ''None' has no attribute 'db_password'', if I run it without a --var parameter. Ok, I know about such a parameter, but my team mates do not - so I need to create a wrapper script or write a node in a readme file. If I use environment variables, then the variables have to be exported before sceptre picks them up, really inconvenient.

So, having the ability to reuse certain parameters would make my user experience better.

[RobReus]

+1 on supporting 'UsePreviousValue'. My use-case:

All infra deployments are done via sceptre. With sceptre, we also setup ECS and ECS services + tasks. We have AWS CodePipelines to build and deploy new docker images. We want to be able to update the CloudFormation stack within CodePipeline with the new docker image tag without this change to be overwritten the next time Sceptre is ran.

I feel like this change should not be that hard to implement, and can provide major benefits.

Alternatively, you can configure the CloudFormation parameter to use a SSM Parameter which is updated by CodePipeline, and then executes a CloudFormation update. This would also make Sceptre use that same SSM Parameter. However, then you have the issue where this parameter does not exists initially (so create stack fails), or you put this parameter in cloudformation, and have the update issue again.

[RobReus]

I just submitted a pull request which implements this feature. Could you guys let me know if this is what you expected?

[WhiteWoodenWall]

But late but just wanted to add a +1 for this.

I am currently trying to use sceptre to manage multiple AWS environments, but am having to exclude stacks with parameters that are hidden (like RDS password) or where the parameters are changed by other software such as ECS.

Being able to set these to reuse the value saved in AWS would make life a lot easier.

[alex-harvey-z3q]

@WhiteWoodenWall someone sent in this PR and we decided against merging/releasing as part of v4.5.x. However, if you think this would solve your problem and be worthwhile, we could look at reopening and merging.
#1476 Let us know.