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

Allow users to opt-out of changing instance name tags #36

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

mbillow
Copy link

@mbillow mbillow commented Jul 12, 2021

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

@mbillow
Copy link
Author

mbillow commented Jul 13, 2021

Hey @jimsheldon @hikerspath @spier 😄

Can one of you take a look at this? Let me know what you think.

@spier
Copy link
Contributor

spier commented Jul 14, 2021

@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?
Also curious what you use them for, and how the original names set by AWS by default are better for that use case than the ones set by this module?

Do you think that the current behavior of this module is so surprizing in this regard that we should really set the update_instance_name_tag flag to false by default? (not sure if that would qualify as a breaking change but we can worry about that later)

Thanks again for your PR and I am looking forward to the conversation here and where it leads.

@mbillow
Copy link
Author

mbillow commented Jul 14, 2021

Could you elaborating a bit on why the changed instance name tags caught you by surprize?

I have two ASGs that deploy very different applications that both use this module. By default, the instance template defines the tag Name={name of app}. Each of these application has it's own subdomain (app1.localdomain and app2.localdomain) and I wanted the DNS records to be #instanceid.{name of app}.localdomain.

This works, but it changes the name of the instances from {name of app} to their instance id. This turns the listing of nodes from something like:

Name                 Instance ID
--------             --------------
application-one      i-12345abcdef
application-one      i-67890ghijkl
application-two      i-1a2b3c4d5e6
application-two      i-f7g8h9i0j1k

where everything is clearly distinguished by application name to:

Name                 Instance ID
--------             --------------
i-12345abcdef        i-12345abcdef
i-67890ghijkl        i-67890ghijkl
i-1a2b3c4d5e6        i-1a2b3c4d5e6
i-f7g8h9i0j1k        i-f7g8h9i0j1k

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 app1-#instanceid.app1.localdomain but that just seems redundant and messy.

Do you think that the current behavior of this module is so surprizing in this regard that we should really set the update_instance_name_tag flag to false by default? (not sure if that would qualify as a breaking change but we can worry about that later)

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.

@spier
Copy link
Contributor

spier commented Jul 14, 2021

This is fantastic extra context @mbillow!
Thanks a lot for this, I understand this much better now.

@jimsheldon
Copy link
Contributor

Thanks for the contribution!

We are reviewing this and will respond as soon as possible

@mbillow
Copy link
Author

mbillow commented Jul 22, 2021

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

@jimsheldon
Copy link
Contributor

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 asg:multihost_pattern tag to control what the lambda function does, could you do something similar here?

Thanks

@mbillow
Copy link
Author

mbillow commented Aug 10, 2021

@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 Name tag:

tag {
  key                 = "asg:update_instance_name"
  value               = "false"
  propagate_at_launch = true
}

Let me know if you want anything else here. 😄

@cydowens
Copy link

@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

@cydowens
Copy link

cydowens commented Sep 3, 2021

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

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.

4 participants