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

Don't override existing parameters #359

Open
sjparkinson opened this issue May 3, 2018 · 12 comments
Open

Don't override existing parameters #359

sjparkinson opened this issue May 3, 2018 · 12 comments

Comments

@sjparkinson
Copy link

[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
Copy link
Author

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

image

@et304383
Copy link

et304383 commented May 3, 2018

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
Copy link
Author

Thanks for highlighting that!

@jk2l
Copy link

jk2l commented May 5, 2018

+1 from “use previous value”

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

@sjparkinson
Copy link
Author

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
Copy link

njsnx commented May 17, 2018

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
Copy link

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
Copy link

mtb-xt commented Jun 12, 2018

+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
Copy link

RobReus commented Jul 1, 2020

+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 added a commit to RobReus/sceptre that referenced this issue Jul 1, 2020
@RobReus
Copy link

RobReus commented Jul 1, 2020

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

@WhiteWoodenWall
Copy link

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
Copy link
Contributor

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment