Skip to content

Conversation

@synfinatic
Copy link
Contributor

Would be nice to use a single yaml file for multiple envs and pick certain stacks to deploy on a per-env basis.

All stacks must have at least one resource or AWS returns an error,
hence we need to be able to disable a stack within stacker if we don't
want it to launch in certain configurations
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a little late to test for this - any reason not to do it right at the beginning, since you already have the stack?

@phobologic
Copy link
Member

Cool! This is a feature we've been talking about here as well. I'm actually curious how this works with other stack actions - like destroy, etc? Will it lead to issues with those?

Also - could you add the enabled flag (probably set to true) with a comment about what it means to https://github.com/remind101/stacker/blob/master/conf/example.yaml - we've used that as a source of documentation for the most part, till we have actual documentation. I'd just set it to true for each stack, and mention that that is the default.

Thanks!

@mwildehahn
Copy link
Contributor

+1 i've been using this locally for a couple months now, i forgot to submit a PR for it. I called it ignore but its functionally the same thing.

re: destroy, in my case if its ignored, it wasn't built, so shouldn't be destroyed. i think that works the same with this.

@phobologic
Copy link
Member

Ok - so if destroy gets a stack that doesn't exist, it just ignores it currently?

Should there be a CLI arg to ignore this flag? Probably not - not sure there's any reason you'd want to do that, this seems like something you'd mostly use in a dev stack.

@synfinatic
Copy link
Contributor Author

Yep, if you call destroy on a stack which isn't there, it skips it and moves on. I'd argue against a CLI flag as that is more knobs to confuse the user.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: updated -> submitted

@synfinatic
Copy link
Contributor Author

Anything else?

@phobologic
Copy link
Member

Looks good - thanks!

phobologic added a commit that referenced this pull request Nov 10, 2015
@phobologic phobologic merged commit 4b785cb into cloudtools:master Nov 10, 2015
@synfinatic synfinatic deleted the adt-add-enabled-flag-v2 branch November 16, 2015 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants