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

elb_target_group: only drain all elb targets if targets is an empty list and modify_targets is true #39715

Closed
wants to merge 7 commits into from

Conversation

Daemoen
Copy link
Contributor

@Daemoen Daemoen commented May 4, 2018

… targets

SUMMARY

The current default of 'True' is dangerous because you would not expect to change targets unless you want to change targets. It is safer to change this to false and prevent unexpected default assumptions. This was the first approach. Rather than changing a default, now check if targets is an empty list. Now if targets and modify_targets options are omitted from the play all targets are not drained.

ISSUE TYPE
  • Bugfix Pull Request
COMPONENT NAME

elb_target_group.py

ANSIBLE VERSION

2.5+

ADDITIONAL INFORMATION

Related to #39709

@ansibot
Copy link
Contributor

ansibot commented May 4, 2018

cc @wimnat
click here for bot help

@ansibot ansibot added aws bug This issue/PR relates to a bug. cloud community_review In order to be merged, this PR must follow the community review workflow. module This issue/PR relates to a module. needs_triage Needs a first human triage before being processed. support:community This issue/PR relates to code supported by the Ansible community. labels May 4, 2018
@willthames
Copy link
Contributor

Not 100% convinced this is the best fix. If the targets aren't changing at all, then they shouldn't all be drained.

I'd like to see (either here or in the associated issue) a minimum test case, rather than changing default behaviour - I've never hit this issue, and I'd like to understand why.

@ansibot ansibot removed the needs_triage Needs a first human triage before being processed. label May 4, 2018
@willthames
Copy link
Contributor

willthames commented May 4, 2018

In this case, modify_targets is really purge_targets. It will only have an effect if you explicitly set targets, afaict, but if you run elb_target_group with what you think is a single new target, it will remove all other targets.

I agree that the default behaviour should be not to purge targets, and also think modify_targets should be renamed to purge_targets (with a backward compatible modify_targets alias)

@Daemoen
Copy link
Contributor Author

Daemoen commented May 4, 2018

Based on what ive seen, that's not quite what it's doing. Behaviorally, 'purge targets' (we'll go with that name for now, for clarity sake in behavior) is purging all targets in the group, even when 0 targets are being supplied. If it is supposed to only take effect when a target is supplied, then that may be the ultimate cause of the bug, and should be investigated further.. I'll post a concrete example of my playbook later, as its on the work machine, but it definitely does not have any targets associated with the play (just with the target group)

@Daemoen
Copy link
Contributor Author

Daemoen commented May 4, 2018

Ok, so reading through the code more thoroughly:
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/cloud/amazon/elb_target_group.py#L56-#L60
Plus:
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/cloud/amazon/elb_target_group.py#L120-#L124

https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/cloud/amazon/elb_target_group.py#L685

Based on the second link above, we see that it literally behaves as 'unless you pass the parameter, it will wipe out all targets'.... Why would someone think to pass modify_targets: false when they aren't passing targets in the first place and modify_targets is an optional parameter

Reverted to default behavior
Updating naming convention based on input from team
Added slightly stronger documentation (suggested note)
Added alias for purge_targets to preserve current syntax
@@ -119,7 +120,7 @@
version_added: 2.5
targets:
description:
- A list of targets to assign to the target group. This parameter defaults to an empty list. Unless you set the 'modify_targets' parameter then
- A list of targets to assign to the target group. This parameter defaults to an empty list. Unless you set the 'purge_targets' parameter then
Copy link
Contributor

Choose a reason for hiding this comment

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

s/This parameter defaults to an empty list./This parameter defaults to None.

The line below should be edited too since to drain all targets it must be set to an empty list to use in conjunction with purge_targets.

Copy link
Contributor

Choose a reason for hiding this comment

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

It still does not default to an empty list, it defaults to None. It will appear null in the invocation.

if module.params.get("modify_targets"):
if module.params.get("targets"):
if module.params.get("purge_targets"):
if module.params.get("targets") == []:
Copy link
Contributor

Choose a reason for hiding this comment

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

I think if module.params.get("targets"): is right here. It indicates that the module needs to compare the current targets with the targets the user provided and remove any that the user hasn't provided. If the comparison within this if is wrong and the wrong targets get removed then that should be fixed.

If I provide

...
purge_targets: true
targets:
      - Id: i-01234567
        Port: 80
      - Id: i-98765432
        Port: 80

and then in a second playbook:

...
purge_targets: true
targets:
      - Id: i-01234567
        Port: 80

I would expect target i-98765432 to be purged after the second playbook. But with this patch this if would now be false, so the path on line 538 would be used and all targets would be purged regardless of the target I want to keep.

I was thinking this line should be changed: https://github.com/ansible/ansible/pull/39715/files#diff-c008972f0ccccd4a4d9b8c1de95c4d08L538 to elif module.params.get("targets") == [] or elif module.params.get("targets") is not None

@Daemoen
Copy link
Contributor Author

Daemoen commented May 4, 2018

Removed the empty list check, but im hesitant to change the else: as it would change the current default behavior (fixing my own issue, but changing wimnat's expected behavior currently). In this case, 'core' can make the final decision on how to handle it and I can change quickly. I already tested the various methods for that line and have it saved as a comment locally.

@ansibot
Copy link
Contributor

ansibot commented May 7, 2018

The test ansible-test sanity --test pep8 [explain] failed with 1 error:

lib/ansible/modules/cloud/amazon/elb_target_group.py:124:58: W291 trailing whitespace

click here for bot help

@ansibot ansibot added ci_verified Changes made in this PR are causing tests to fail. needs_revision This PR fails CI tests or a maintainer has requested a review/revision of the PR. and removed community_review In order to be merged, this PR must follow the community review workflow. labels May 7, 2018
- A list of targets to assign to the target group. This parameter defaults to an empty list. Unless you set the 'modify_targets' parameter then
all existing targets will be removed from the group. The list should be an Id and a Port parameter. See the Examples for detail.
- A list of targets to assign to the target group. The list should be an Id and a Port parameter.
Defaults to 'None.' See the Examples for detail.
Copy link
Contributor

Choose a reason for hiding this comment

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

No quotes for None, makes it unclear if it's python None/yaml null or a string.

Copy link
Contributor

Choose a reason for hiding this comment

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

Feel free to add here as well something along the lines of prior to 2.6 all targets were drained if this option was None and I(purge_targets) was True. As of 2.6, to drain all targets this option must be set to an empty list to use in conjunction with I(purge_targets).

@@ -535,7 +537,7 @@ def create_or_update_target_group(connection, module):
status_achieved, registered_instances = wait_for_status(connection, module, tg['TargetGroupArn'], instances_to_remove, 'unused')
if not status_achieved:
module.fail_json(msg='Error waiting for target deregistration - please check the AWS console')
else:
elif module.get.parames("targets") is None:
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be elif module.get.parames("targets") is not None: or elif module.get.parames("targets") == []:

@s-hertel
Copy link
Contributor

s-hertel commented May 7, 2018

shippable is complaining because:
2018-05-07 18:10:24 ERROR: Found 1 pep8 issue(s) which need to be resolved:
2018-05-07 18:10:24 ERROR: lib/ansible/modules/cloud/amazon/elb_target_group.py:124:58: W291 trailing whitespace (100%)

@ansibot ansibot removed the ci_verified Changes made in this PR are causing tests to fail. label May 7, 2018
@ansibot
Copy link
Contributor

ansibot commented May 7, 2018

The test ansible-test sanity --test pep8 [explain] failed with 1 error:

lib/ansible/modules/cloud/amazon/elb_target_group.py:124:56: W291 trailing whitespace

click here for bot help

@ansibot ansibot added the ci_verified Changes made in this PR are causing tests to fail. label May 7, 2018
@ansibot ansibot added community_review In order to be merged, this PR must follow the community review workflow. and removed ci_verified Changes made in this PR are causing tests to fail. needs_revision This PR fails CI tests or a maintainer has requested a review/revision of the PR. labels May 7, 2018
@s-hertel s-hertel changed the title Changing modify_targets default to prevent unexpected draining of elb targets elb_target_group: only drain all elb targets if targets is an empty list and modify_targets is true May 9, 2018
@s-hertel
Copy link
Contributor

s-hertel commented May 9, 2018

@wimnat Hi, do you mind reviewing this?

@@ -477,7 +481,7 @@ def create_or_update_target_group(connection, module):
module.fail_json_aws(e, msg="Couldn't update target group")

# Do we need to modify targets?
if module.params.get("modify_targets"):
if module.params.get("purge_targets"):
Copy link
Contributor

Choose a reason for hiding this comment

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

This change will mean that new targets will not get registered if purge_targets is False, which is not what would be expected.

We could really use a test suite to catch this kind of thing.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, maybe purge_targets is not the right name for this. @willthames Do you have a problem with this fix if the option name remains 'modify_targets'?

Copy link
Contributor

Choose a reason for hiding this comment

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

This seems like a problem with overloading what purge_ means. The code does what I'd expect, but not what I'd expect a purge_targets option to do. @Daemoen, what do you think?

@ansibot ansibot added needs_revision This PR fails CI tests or a maintainer has requested a review/revision of the PR. and removed community_review In order to be merged, this PR must follow the community review workflow. labels May 9, 2018
@wimnat
Copy link
Contributor

wimnat commented May 11, 2018

Just a little background on this...

When I initially wrote the module for my use case there was no modify_targets parameter.

I would create a target group and ELB and then an ECS service. The ECS service was responsible for putting targets in to the target group. I would never have targets parameter in my task.

When I ran a new deploy of my application, the target group module would remove all the targets that ECS had put in there before then updating the ECS service and then ECS would put the targets back.

This was obviously bad as there would be a period where all targets were removed before ECS put targets in so I added the modify_targets flag so that all that was happening was the module was checking the target group existed and not worrying about targets.

It was just a quick fix - maybe if i'd thought about it some more i would of just said if targets is None don't change targets but... i didn't :P

As for purge_targets defaulting to yes, i always disagree with most people when it comes to this. I see ansible as a tool to reach desired state - IMO it should always purge unless said otherwise IF the parameter is passed. E.g. with tags - if you've passed a set of tags then you shouldn't have to worry about some other tags be present unless you explicitly say 'purge_tags=no'. Same for targets. I think this is a good change to take in to account whether the targets param is None.

Hope that makes sense.

Anyway, with this change things should still work for me as I expect so LGTM

- A list of targets to assign to the target group. The list should be an Id and a Port parameter.
Defaults to None. See the Examples for detail.
Prior to 2.6, all targets were drained if targets was None and I(purge_targets) was True. As of 2.6,
to drain all targets, this option must be set to an empty list to use in conjustion with I(purge_targets).
Copy link
Contributor

Choose a reason for hiding this comment

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

spelling: conjunction

@ansibot ansibot added affects_2.6 This issue/PR affects Ansible v2.6 stale_ci This PR has been tested by CI more than one week ago. Close and re-open this PR to get it retested. labels May 19, 2018
@ansibot ansibot added the needs_repo This PR no longer has an associated branch as it was removed by the submitter. label Aug 31, 2018
@ansibot ansibot added support:core This issue/PR relates to code supported by the Ansible Engineering Team. and removed support:community This issue/PR relates to code supported by the Ansible community. labels Sep 16, 2018
@ansibot ansibot added needs_maintainer Ansibot is unable to identify maintainers for this PR. (Check `author` in docs or BOTMETA.yml) support:community This issue/PR relates to code supported by the Ansible community. and removed support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels Oct 2, 2018
@ansibot ansibot removed the needs_maintainer Ansibot is unable to identify maintainers for this PR. (Check `author` in docs or BOTMETA.yml) label Nov 9, 2018
@ansibot ansibot added the needs_rebase https://docs.ansible.com/ansible/devel/dev_guide/developing_rebasing.html label Dec 4, 2018
@ansibot
Copy link
Contributor

ansibot commented Dec 15, 2018

@Daemoen Your branch does not contain a shippable.yml file. Please rebase your branch to trigger running of current tests.

click here for bot help

@ansibot ansibot added the needs_shippable This PR lacks a shippable.yml in its tree. Please rebase your branch to include the latest CI tests. label Dec 15, 2018
@threewordphrase
Copy link

Bump - this is causing unexpected behavior (ECS services throw 503 errors instead of doing rolling deployments). If there is any way I can help push this PR along I would be happy to, just let me know.

@Daemoen
Copy link
Contributor Author

Daemoen commented Jan 23, 2019

Wow, not sure what happened here. I thought we had closed out and resolved this weeks ago, just noticed it hanging around at the top of my notifications. I can take a look at it later today.

@gundalow
Copy link
Contributor

gundalow commented Sep 3, 2019

@Daemoen Hi, are you able to look at this still?
Looks like there are people here that would find this useful and be able to test it.

I notice your source branch has been deleted, so you may need to create a fresh PR & branch.

@gundalow gundalow added the pr_day Has been reviewed during a PR review Day label Sep 3, 2019
@gundalow
Copy link
Contributor

Assuming not, so closing.

@gundalow gundalow closed this Oct 25, 2019
@ansible ansible locked and limited conversation to collaborators Dec 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_2.6 This issue/PR affects Ansible v2.6 aws bug This issue/PR relates to a bug. cloud module This issue/PR relates to a module. needs_rebase https://docs.ansible.com/ansible/devel/dev_guide/developing_rebasing.html needs_repo This PR no longer has an associated branch as it was removed by the submitter. needs_revision This PR fails CI tests or a maintainer has requested a review/revision of the PR. needs_shippable This PR lacks a shippable.yml in its tree. Please rebase your branch to include the latest CI tests. pr_day Has been reviewed during a PR review Day stale_ci This PR has been tested by CI more than one week ago. Close and re-open this PR to get it retested. support:community This issue/PR relates to code supported by the Ansible community.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants