-
Notifications
You must be signed in to change notification settings - Fork 46
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
Allow users to opt-out of changing instance name tags #36
base: master
Are you sure you want to change the base?
Conversation
Hey @jimsheldon @hikerspath @spier 😄 Can one of you take a look at this? Let me know what you think. |
@mbillow thanks for putting in the effort to describe your proposal as a PR. That makes it a lot easier to understand what you have in mind here. Could you elaborating a bit on why the changed instance name tags caught you by surprize? Do you think that the current behavior of this module is so surprizing in this regard that we should really set the Thanks again for your PR and I am looking forward to the conversation here and where it leads. |
I have two ASGs that deploy very different applications that both use this module. By default, the instance template defines the tag This works, but it changes the name of the instances from
where everything is clearly distinguished by application name to:
which is completely useless without playing around with what fields are displayed in the console/are queried for in the CLI. A possible work around without changing code would be to do something like
At a minimum it should be clearly stated that the current behavior is "expected." I couldn't find anywhere in the README that stated this and it took some digging in CloudTrail to figure out what was actually happening. Is this worth a potentially breaking change? 🤷🏼♂️ Probably not, which is why I did this the way I did. Personally, I feel that documenting the current behavior and allowing a way to easily opt-out (this PR) is fine. |
This is fantastic extra context @mbillow! |
Thanks for the contribution! We are reviewing this and will respond as soon as possible |
@jimsheldon @spier Is it possible to get a rough ETA on this getting merged? I'd like to avoid having to switch my TF over to my fork, if possible. |
Hello @mbillow I am reviewing this and wondering if it would be better to control this behavior through a tag on the ASG itself, rather than a global setting? With this approach, the lambda function would either always change the name tag or never change it. It might be better to let the ASG control that behavior? If you look at #34 the approach there uses a unique Thanks |
@jimsheldon I made the requested change and updated the docs to reflect the changes I made. This leaves the default (untagged) behavior the same but the following tag will stop it from changing the tag {
key = "asg:update_instance_name"
value = "false"
propagate_at_launch = true
} Let me know if you want anything else here. 😄 |
@mbillow Thanks for providing the above code snippet. Would you mind also contributing a test to our terratest? Here is the link to our current test file: https://github.com/meltwater/terraform-aws-asg-dns-handler/blob/master/terratest/test/asg_dns_handler_test.go |
@mbillow Hello, unfortunately the code that you submitted drone's build isn't passing. Would you be able to update your code and also submit a test with it? Let us know if you have any additional questions. |
I was very surprised when my instance names changed after adding this. I much prefer their original names, so I added a way to opt-out of of them being change. 😄