route53_health_check: Add feature to create multiple health checks without updating existing health check #1143

mandar242 · 2022-05-10T16:54:50Z

SUMMARY

Might fix #88

Update [06/30/2022]:
This PR adds three new parameters to route53_health_check module.

health_check_id=dict(type='str', aliases=['id'], required=False),
health_check_name=dict(type='str', aliases=['name'], required=False),
use_unique_names=dict(type='bool', required=False),

health_check_id (alias id): when set, can be used to update and also delete health checks.
use_unique_names and health_check_name (alias name): these are used together to make use of health check name as a unique identifier to create/update/delete health check and also assign a name to the health check.

Update [05/20/2022]:
Based on discussion between 15 May to 19 May below, the approach of adding ignore_existing parameter has been discarded for the time being.
The progress on this WIP PR put on hold until route53_info return value issue gets resolved. #1236

Added parameter ignore_existing that allows to create multiple route53 healthchecks with similar parameters instead of updating existing healthcheck (example: create multiple route53 healthchecks with different paths to same server).

ISSUE TYPE

Feature Pull Request

COMPONENT NAME

route53_health_check

ADDITIONAL INFORMATION

Consider following example from the issue.

- name: set up route53 health checks
  connection: local
  become: false
  route53_health_check:
    failure_threshold: 3
    ip_address: '{{ ip_address }}'
    port: 80
    request_interval: 30
    resource_path: '{{ item }}'
    state: present
    type: HTTP
    #ignore_existing: True
  register: result
  with_items:
    - /some_status1
    - /other_status2

With ignore_exisitng parameter, it will create two healthchecks to same sever with different resource_path.

Without ignore_existing parameter, it will create first healthcheck to sever, then start creating the second healthcheck but as it's having same server/ip_address, it updates the existing healthcheck instead, so creates only single healthcheck at the end of the task.

ansibullbot · 2022-05-10T16:55:25Z

cc @jillr @markuman @s-hertel @tremble @zimbatm
click here for bot help

softwarefactory-project-zuul · 2022-05-10T17:16:05Z

Build failed.

markuman · 2022-05-11T12:03:36Z

some documentation mismatches

ERROR: plugins/modules/route53_health_check.py:0:0: doc-default-does-not-match-spec: Argument 'ignore_existing' in argument_spec defines default as (False) but documentation defines default as (None)
ERROR: plugins/modules/route53_health_check.py:0:0: parameter-type-not-in-doc: Argument 'ignore_existing' in argument_spec defines type as 'bool' but documentation doesn't define type
ERROR: plugins/modules/route53_health_check.py:0:0: undocumented-parameter: Argument 'ignore_existing' is listed in the argument_spec, but not documented in the module documentation

mandar242 · 2022-05-11T20:24:19Z

some documentation mismatches

ERROR: plugins/modules/route53_health_check.py:0:0: doc-default-does-not-match-spec: Argument 'ignore_existing' in argument_spec defines default as (False) but documentation defines default as (None)
ERROR: plugins/modules/route53_health_check.py:0:0: parameter-type-not-in-doc: Argument 'ignore_existing' in argument_spec defines type as 'bool' but documentation doesn't define type
ERROR: plugins/modules/route53_health_check.py:0:0: undocumented-parameter: Argument 'ignore_existing' is listed in the argument_spec, but not documented in the module documentation

fixed.

alinabuzachis

My first impression is that the bug is inside find_health_check(). This function doesn't consider the path while filtering and, looking at this task example, since all of the other parameters match, it will update the health check instead of creating a new one (because it will match the health check even if the path is different).
I would probably add the path as a matching criteria for find_health_check() and see what happens.
Probably we don't need to add a new parameter.

mandar242 · 2022-05-13T01:11:01Z

My first impression is that the bug is inside find_health_check(). This function doesn't consider the path while filtering and, looking at this task example, since all of the other parameters match, it will update the health check instead of creating a new one (because it will match the health check even if the path is different). I would probably add the path as a matching criteria for find_health_check() and see what happens. Probably we don't need to add a new parameter.

Hi @alinabuzachis, adding resource_path to find_health_check() as a matching criteria does seem to work.
Only issue I faced with it is that it breaks exisitng playbook tasks from the integration tests.
https://github.com/ansible-collections/community.aws/blob/main/tests/integration/targets/route53_health_check/tasks/main.yml#L997

There is a possiblity of having health_check of type HTTP_STR_MATCH and HTTPS_STR_MATCH having only search_string and not having resource_path https://github.com/ansible-collections/community.aws/blob/main/tests/integration/targets/route53_health_check/tasks/main.yml#L868.

And if we try to update that health_check to add resource_path to it, the code creates a new health_check instead of updating it as it does not match existing health_check that only has search_string.

So modified a code block inside find_health_checks() to handle this https://github.com/ansible-collections/community.aws/pull/1143/files#diff-b42357f59bc920b042c0be021e76c32b30b0ff8c8a466c541c993836802aa030R280

But this change again fails to allow creating multiple health_checks
If we want to create multiple health checks that only differ in resource_path this fails due to above modification.

- name: set up route53 health checks
     route53_health_check:
       failure_threshold: 3
       ip_address: '1.1.1.1'
       port: 80
       request_interval: 30
       resource_path: '{{ item }}'
       state: present
       type: HTTP_STR_MATCH
       string_match: 'my-test-string-to-match'
     register: result
     with_items:
       - /some_status1
       - /other_status2
       
# This creates a health_check and then updates it's resource_path, ultimately creation only single health check.

In my opinion, ignore_exisiting parameter, could be the best way forward as it adds the functionality of multiple creation and does not affect/break existing functionality and playbooks.

alinabuzachis · 2022-05-16T16:35:13Z

My first impression is that the bug is inside find_health_check(). This function doesn't consider the path while filtering and, looking at this task example, since all of the other parameters match, it will update the health check instead of creating a new one (because it will match the health check even if the path is different). I would probably add the path as a matching criteria for find_health_check() and see what happens. Probably we don't need to add a new parameter.

Hi @alinabuzachis, adding resource_path to find_health_check() as a matching criteria does seem to work. Only issue I faced with it is that it breaks exisitng playbook tasks from the integration tests. https://github.com/ansible-collections/community.aws/blob/main/tests/integration/targets/route53_health_check/tasks/main.yml#L997

There is a possiblity of having health_check of type HTTP_STR_MATCH and HTTPS_STR_MATCH having only search_string and not having resource_path https://github.com/ansible-collections/community.aws/blob/main/tests/integration/targets/route53_health_check/tasks/main.yml#L868.

And if we try to update that health_check to add resource_path to it, the code creates a new health_check instead of updating it as it does not match existing health_check that only has search_string.

So modified a code block inside find_health_checks() to handle this https://github.com/ansible-collections/community.aws/pull/1143/files#diff-b42357f59bc920b042c0be021e76c32b30b0ff8c8a466c541c993836802aa030R280

But this change again fails to allow creating multiple health_checks If we want to create multiple health checks that only differ in resource_path this fails due to above modification.
- name: set up route53 health checks
     route53_health_check:
       failure_threshold: 3
       ip_address: '1.1.1.1'
       port: 80
       request_interval: 30
       resource_path: '{{ item }}'
       state: present
       type: HTTP_STR_MATCH
       string_match: 'my-test-string-to-match'
     register: result
     with_items:
       - /some_status1
       - /other_status2
       
# This creates a health_check and then updates it's resource_path, ultimately creation only single health check.
In my opinion, ignore_exisiting parameter, could be the best way forward as it adds the functionality of multiple creation and does not affect/break existing functionality and playbooks.

My suggestion should create a different heath checks every time the existing resource_path is different than the new one we want to set. The problem may arise when an update should be performed. One solution would be to only update resource_path when None is defined, otherwise create a new one always. If you have already a resource_path value and you want to update it, you should first assign None and then update with the new value (Similar to how that should work for IPAddress https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.update_health_check. Not sure if I really like the approach). The other solution that comes to mind (and as Mandar suggested) is adding an additional param.
Any thoughts @tremble @markuman?

markuman · 2022-05-16T18:40:13Z

In my opinion, ignore_exisiting parameter, ....

If something like that will be introduces, it must be purge_health_checks.

But the entire problem is spread over multiple collections and modules (communit.general.gitlab_project_variable, community.proxysql.proxysql_scheduler....).
Imo the only clean way out of this, is to introduce a new parameter that fits the requirements.
Once the new parameter is introduced, the previous can be drained out some major releases later.

One major issue is, that there are more options per health check that are currently not suppored by community.aws, when I just take a look at the console.

the entire name parameter is missing (which unfortunately isn't also a unique key), enable/disable a health check might be also interesting (without deleting it) and so on.
With the given approach, thinks get far more complicated in the future.

strictly speaking, the only way to update an existing route53 health check is, when you provide its id (because AWS doesn't provide a primary key defined by the user). otherwhise the module must always create a new health check. So the current behaviour must be treated as a bug.
But fixing the current behaviour would result in a breaking change.
So the only two things what we can do now is (imo)

introduce a new id parameter that updates existing health checks
throw some deprecation warnings that the current usage without the usage of id parameter will change in the future.

That also means, that a community.aws.route53_health_check_info module is missing and must be releases first or in parallel. Otherwise it is impossible to determine ids of existing health checks

mandar242 · 2022-05-16T19:05:27Z

In my opinion, ignore_exisiting parameter, ....

If something like that will be introduces, it must be purge_health_checks.

But the entire problem is spread over multiple collections and modules (communit.general.gitlab_project_variable, community.proxysql.proxysql_scheduler....). Imo the only clean way out of this, is to introduce a new parameter that fits the requirements. Once the new parameter is introduced, the previous can be drained out some major releases later.

One major issue is, that there are more options per health check that are currently not suppored by community.aws, when I just take a look at the console.

the entire name parameter is missing (which unfortunately isn't also a unique key), enable/disable a health check might be also interesting (without deleting it) and so on. With the given approach, thinks get far more complicated in the future.

strictly speaking, the only way to update an existing route53 health check is, when you provide its id (because AWS doesn't provide a primary key defined by the user). otherwhise the module must always create a new health check. So the current behaviour must be treated as a bug. But fixing the current behaviour would result in a breaking change. So the only two things what we can do now is (imo)
1. introduce a new `id` parameter that updates existing health checks

2. throw some deprecation warnings that the current usage without the usage of `id` parameter will change in the future.
That also means, that a community.aws.route53_health_check_info module is missing and must be releases first or in parallel. Otherwise it is impossible to determine ids of existing health checks

With the HealthCheckId being required parameter for updating the existing health checks as per api documentation,

In my opinion I think the way suggested by @markuman is best way possible here.
So we can make changes such as

Add a new id parameter for HealthCheckId, which is a required param for updating existing health checks.
If id is not provided in the task, then create new health checks irrespective of existing ones.

My only concern here though is that could this change break any existing playbooks that are used for updating health checks?

markuman · 2022-05-16T19:26:45Z

If id is not provided in the task, then create new health checks irrespective of existing ones.

My only concern here though is that could this change break any existing playbooks that are used for updating health checks?

If the id is not provided, keep the behaviour as it is, just throw warnings that it will change in the future...
That should keep backwards compatibility. And that also means, that the origin issue cannot be solved that fast.

alinabuzachis · 2022-05-17T12:24:45Z

In my opinion, ignore_exisiting parameter, ....

If something like that will be introduces, it must be purge_health_checks.

But the entire problem is spread over multiple collections and modules (communit.general.gitlab_project_variable, community.proxysql.proxysql_scheduler....). Imo the only clean way out of this, is to introduce a new parameter that fits the requirements. Once the new parameter is introduced, the previous can be drained out some major releases later.

One major issue is, that there are more options per health check that are currently not suppored by community.aws, when I just take a look at the console.

the entire name parameter is missing (which unfortunately isn't also a unique key), enable/disable a health check might be also interesting (without deleting it) and so on. With the given approach, thinks get far more complicated in the future.

strictly speaking, the only way to update an existing route53 health check is, when you provide its id (because AWS doesn't provide a primary key defined by the user). otherwhise the module must always create a new health check. So the current behaviour must be treated as a bug. But fixing the current behaviour would result in a breaking change. So the only two things what we can do now is (imo)

introduce a new id parameter that updates existing health checks

throw some deprecation warnings that the current usage without the usage of id parameter will change in the future.

That also means, that a community.aws.route53_health_check_info module is missing and must be releases first or in parallel. Otherwise it is impossible to determine ids of existing health checks

@markuman I guess we can use directly community.aws.route53_info to query health checks. We have the same issue in community.aws.route53_info regarding the returned result, as already noted in ecs_taskdefinition. The output is not returned as snake_case but as CamelCase. To unsure consistency across all the modules, we should have snake_case results in my opinion. We could probably deprecate the CamelCase result and introduce a new result dict containing the snake_case params/ or directly the snake_case params inside the existing result. How would you suggest to handle that from community perspective?

markuman · 2022-05-17T12:31:44Z

To unsure consistency across all the modules, we should have snake_case results in my opinion. We could probably deprecate the CamelCase result and introduce a new result dict containing the snake_case params/ or directly the snake_case params inside the existing result. How would you suggest to handle that from community perspective?

I fully agree here.
Furthermore, the returned parameter names of the _info module must also match the parameter names of the none _info module. So that you can pass the output directly into the input - imo...and in an ideal world.
An anti-example is ec2_group and ec2_group_info.
Maybe that's also something for the next community meeting.

markuman · 2022-05-17T12:33:12Z

@markuman I guess we can use directly community.aws.route53_info to query health checks.

That works also for me. But the route53_healt_check module documentation must refer to route53_info then.

markuman · 2022-05-17T12:55:09Z

strictly speaking, the only way to update an existing route53 health check is, when you provide its id (because AWS doesn't provide a primary key defined by the user). otherwhise the module must always create a new health check.

some other thoughts I came across with ....
this is not an ideal process, because users must update their task with the matching health check it, once a healtcheck is created - if they just want one health check.
What do you think of a paremeter like use_unique_names: default(yes). So that the module treaded health check names as unique keys? When the name exists already, it can be updated. @mandar242 @alinabuzachis

alinabuzachis · 2022-05-17T13:46:37Z

strictly speaking, the only way to update an existing route53 health check is, when you provide its id (because AWS doesn't provide a primary key defined by the user). otherwhise the module must always create a new health check.

some other thoughts I came across with .... this is not an ideal process, because users must update their task with the matching health check it, once a healtcheck is created - if they just want one health check. What do you think of a paremeter like use_unique_names: default(yes). So that the module treaded health check names as unique keys? When the name exists already, it can be updated. @mandar242 @alinabuzachis

@markuman Like this approach!

mandar242 · 2022-05-17T19:37:49Z

some other thoughts I came across with .... this is not an ideal process, because users must update their task with the matching health check it, once a healtcheck is created - if they just want one health check. What do you think of a paremeter like use_unique_names: default(yes). So that the module treaded health check names as unique keys? When the name exists already, it can be updated. @mandar242 @alinabuzachis

@markuman @alinabuzachis I like the approach here. But would this need to add name or health_check_name parameter to route53_health_check first?
as route53_health_check currently does not support health_check_name, none of the created health checks using the module can be assigned name if I remember correctly?
https://github.com/ansible-collections/community.aws/blob/main/plugins/modules/route53_health_check.py

markuman · 2022-07-01T19:06:15Z

Ups, wrong clicked ... sry

softwarefactory-project-zuul · 2022-07-01T19:25:00Z

Build succeeded.

✔️ ansible-galaxy-importer SUCCESS in 4m 48s (non-voting)
✔️ build-ansible-collection SUCCESS in 5m 10s
✔️ ansible-test-sanity-docker-devel SUCCESS in 12m 47s (non-voting)
✔️ ansible-test-sanity-docker-milestone SUCCESS in 10m 56s
✔️ ansible-test-sanity-docker-stable-2.12 SUCCESS in 11m 06s
✔️ ansible-test-sanity-docker-stable-2.13 SUCCESS in 10m 22s
✔️ ansible-test-units-community-aws-python38 SUCCESS in 6m 17s
✔️ ansible-test-units-community-aws-python39 SUCCESS in 5m 46s
✔️ ansible-test-splitter SUCCESS in 2m 37s
✔️ integration-community.aws-1 SUCCESS in 7m 02s
⚠️ integration-community.aws-2 SKIPPED
⚠️ integration-community.aws-3 SKIPPED
⚠️ integration-community.aws-4 SKIPPED
⚠️ integration-community.aws-5 SKIPPED
⚠️ integration-community.aws-6 SKIPPED
⚠️ integration-community.aws-7 SKIPPED
⚠️ integration-community.aws-8 SKIPPED
⚠️ integration-community.aws-9 SKIPPED
⚠️ integration-community.aws-10 SKIPPED
⚠️ integration-community.aws-11 SKIPPED
⚠️ integration-community.aws-12 SKIPPED
⚠️ integration-community.aws-13 SKIPPED

softwarefactory-project-zuul · 2022-07-01T19:45:28Z

Build succeeded.

✔️ ansible-galaxy-importer SUCCESS in 3m 59s (non-voting)
✔️ build-ansible-collection SUCCESS in 5m 06s
✔️ ansible-test-sanity-docker-devel SUCCESS in 10m 00s (non-voting)
✔️ ansible-test-sanity-docker-milestone SUCCESS in 10m 54s
✔️ ansible-test-sanity-docker-stable-2.12 SUCCESS in 10m 10s
✔️ ansible-test-sanity-docker-stable-2.13 SUCCESS in 11m 09s
✔️ ansible-test-units-community-aws-python38 SUCCESS in 7m 06s
✔️ ansible-test-units-community-aws-python39 SUCCESS in 5m 43s
✔️ ansible-test-splitter SUCCESS in 2m 31s
✔️ integration-community.aws-1 SUCCESS in 7m 29s
⚠️ integration-community.aws-2 SKIPPED
⚠️ integration-community.aws-3 SKIPPED
⚠️ integration-community.aws-4 SKIPPED
⚠️ integration-community.aws-5 SKIPPED
⚠️ integration-community.aws-6 SKIPPED
⚠️ integration-community.aws-7 SKIPPED
⚠️ integration-community.aws-8 SKIPPED
⚠️ integration-community.aws-9 SKIPPED
⚠️ integration-community.aws-10 SKIPPED
⚠️ integration-community.aws-11 SKIPPED
⚠️ integration-community.aws-12 SKIPPED
⚠️ integration-community.aws-13 SKIPPED

plugins/modules/route53_health_check.py

changelogs/fragments/1143-route53_health_check-update-delete-by-id-and-name.yml

softwarefactory-project-zuul · 2022-07-05T19:48:27Z

Build succeeded.

✔️ ansible-galaxy-importer SUCCESS in 3m 42s (non-voting)
✔️ build-ansible-collection SUCCESS in 5m 38s
✔️ ansible-test-sanity-docker-devel SUCCESS in 16m 36s (non-voting)
✔️ ansible-test-sanity-docker-milestone SUCCESS in 17m 18s
✔️ ansible-test-sanity-docker-stable-2.12 SUCCESS in 16m 57s
✔️ ansible-test-sanity-docker-stable-2.13 SUCCESS in 16m 30s
✔️ ansible-test-units-community-aws-python38 SUCCESS in 5m 55s
✔️ ansible-test-units-community-aws-python39 SUCCESS in 6m 42s
✔️ ansible-test-splitter SUCCESS in 2m 28s
✔️ integration-community.aws-1 SUCCESS in 8m 37s
⚠️ integration-community.aws-2 SKIPPED
⚠️ integration-community.aws-3 SKIPPED
⚠️ integration-community.aws-4 SKIPPED
⚠️ integration-community.aws-5 SKIPPED
⚠️ integration-community.aws-6 SKIPPED
⚠️ integration-community.aws-7 SKIPPED
⚠️ integration-community.aws-8 SKIPPED
⚠️ integration-community.aws-9 SKIPPED
⚠️ integration-community.aws-10 SKIPPED
⚠️ integration-community.aws-11 SKIPPED
⚠️ integration-community.aws-12 SKIPPED
⚠️ integration-community.aws-13 SKIPPED

softwarefactory-project-zuul · 2022-07-07T05:28:58Z

Build succeeded (gate pipeline).

softwarefactory-project-zuul · 2022-07-07T05:29:01Z

Pull request merge failed: Resource not accessible by integration, You may need to manually rebase your PR and retry.

tremble · 2022-07-07T06:27:20Z

regate

softwarefactory-project-zuul · 2022-07-07T06:46:10Z

Build succeeded (gate pipeline).

✔️ ansible-galaxy-importer SUCCESS in 7m 01s (non-voting)
✔️ build-ansible-collection SUCCESS in 5m 18s
✔️ ansible-test-sanity-docker-devel SUCCESS in 11m 36s (non-voting)
✔️ ansible-test-sanity-docker-milestone SUCCESS in 10m 34s
✔️ ansible-test-sanity-docker-stable-2.12 SUCCESS in 11m 00s
✔️ ansible-test-sanity-docker-stable-2.13 SUCCESS in 11m 02s
✔️ ansible-test-units-community-aws-python38 SUCCESS in 6m 18s
✔️ ansible-test-units-community-aws-python39 SUCCESS in 6m 10s
✔️ ansible-test-splitter SUCCESS in 2m 35s
✔️ integration-community.aws-1 SUCCESS in 7m 09s
⚠️ integration-community.aws-2 SKIPPED
⚠️ integration-community.aws-3 SKIPPED
⚠️ integration-community.aws-4 SKIPPED
⚠️ integration-community.aws-5 SKIPPED
⚠️ integration-community.aws-6 SKIPPED
⚠️ integration-community.aws-7 SKIPPED
⚠️ integration-community.aws-8 SKIPPED
⚠️ integration-community.aws-9 SKIPPED
⚠️ integration-community.aws-10 SKIPPED
⚠️ integration-community.aws-11 SKIPPED
⚠️ integration-community.aws-12 SKIPPED
⚠️ integration-community.aws-13 SKIPPED

softwarefactory-project-zuul · 2022-07-07T06:46:13Z

Pull request merge failed: Resource not accessible by integration, You may need to manually rebase your PR and retry.

patchback · 2022-07-07T07:21:33Z

Backport to stable-4: 💚 backport PR created

✅ Backport PR branch: patchback/backports/stable-4/8d3fec8e5331590c5d8f22f5e55acbb115ae39cb/pr-1143

Backported as #1324

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

…thout updating existing health check (#1143) * Add health_check_name / name parameter support to naming health checks during creation * Handle create/update when health_check when name is unique identifier * Fix bug: tags not specified but name is specified resulting in python error * Add integration tests for as unique identifier * code cleanup to remove redundant usage of manage_tags * Feat: ability to Update and Delete health checks by ID * Add integration tests for testing update/delete health check by ID * Minor fix, improve login to handle find_health_check() call * Use required_together param * Added changelogs fragment * use fqdn for examples, fix changelog variable names (cherry picked from commit 8d3fec8)

…thout updating existing health check (#1143) (#1324) [PR #1143/8d3fec8e backport][stable-4] route53_health_check: Add feature to create multiple health checks without updating existing health check This is a backport of PR #1143 as merged into main (8d3fec8). SUMMARY Might fix #88 Update [06/30/2022]: This PR adds three new parameters to route53_health_check module. health_check_id=dict(type='str', aliases=['id'], required=False), health_check_name=dict(type='str', aliases=['name'], required=False), use_unique_names=dict(type='bool', required=False), health_check_id (alias id): when set, can be used to update and also delete health checks. use_unique_names and health_check_name (alias name): these are used together to make use of health check name as a unique identifier to create/update/delete health check and also assign a name to the health check. Update [05/20/2022]: Based on discussion between 15 May to 19 May below, the approach of adding ignore_existing parameter has been discarded for the time being. The progress on this WIP PR put on hold until route53_info return value issue gets resolved. #1236 Added parameter ignore_existing that allows to create multiple route53 healthchecks with similar parameters instead of updating existing healthcheck (example: create multiple route53 healthchecks with different paths to same server). ISSUE TYPE Feature Pull Request COMPONENT NAME route53_health_check ADDITIONAL INFORMATION Consider following example from the issue. - name: set up route53 health checks connection: local become: false route53_health_check: failure_threshold: 3 ip_address: '{{ ip_address }}' port: 80 request_interval: 30 resource_path: '{{ item }}' state: present type: HTTP #ignore_existing: True register: result with_items: - /some_status1 - /other_status2 With ignore_exisitng parameter, it will create two healthchecks to same sever with different resource_path. Without ignore_existing parameter, it will create first healthcheck to sever, then start creating the second healthcheck but as it's having same server/ip_address, it updates the existing healthcheck instead, so creates only single healthcheck at the end of the task. Reviewed-by: Mark Chappell <None>

…thout updating existing health check (ansible-collections#1143) * Add health_check_name / name parameter support to naming health checks during creation * Handle create/update when health_check when name is unique identifier * Fix bug: tags not specified but name is specified resulting in python error * Add integration tests for as unique identifier * code cleanup to remove redundant usage of manage_tags * Feat: ability to Update and Delete health checks by ID * Add integration tests for testing update/delete health check by ID * Minor fix, improve login to handle find_health_check() call * Use required_together param * Added changelogs fragment * use fqdn for examples, fix changelog variable names This commit was initially merged in https://github.com/ansible-collections/community.aws See: ansible-collections@8d3fec8

Merge release changelogs into main branch SUMMARY Cherrypicks from: Prepare 3.5.0 release (ansible-collections#1124) Prepare release 4.3.0 (#1125) Prepare 5.0.1 with minor bugfixes (ansible-collections#1123) Prepare 5.0.2 release (ansible-collections#1143) ISSUE TYPE Docs Pull Request COMPONENT NAME Merge in the changelogs from 3.5.0, 4.3.0, 5.0.1 and 5.0.2 into the main changelog ADDITIONAL INFORMATION Reviewed-by: Gonéri Le Bouder <goneri@lebouder.net>

mandar242 requested review from tremble, markuman, alinabuzachis and jatorcasso May 10, 2022 16:54

mandar242 changed the title ~~route53_health_check: Add feature to create multiple health checks without updating existing health check~~ [WIP] route53_health_check: Add feature to create multiple health checks without updating existing health check May 10, 2022

ansibullbot added WIP Work in progress feature This issue/PR relates to a feature request module module needs_triage plugins plugin (any type) labels May 10, 2022

ansibullbot removed the needs_triage label May 11, 2022

This comment was marked as outdated.

Sign in to view

alinabuzachis reviewed May 12, 2022

View reviewed changes

This comment was marked as outdated.

Sign in to view

mandar242 requested a review from alinabuzachis May 13, 2022 17:49

markuman closed this Jul 1, 2022

markuman reopened this Jul 1, 2022

Added changelogs fragment

79e2aa6

alinabuzachis reviewed Jul 4, 2022

View reviewed changes

plugins/modules/route53_health_check.py Outdated Show resolved Hide resolved

markuman reviewed Jul 4, 2022

View reviewed changes

changelogs/fragments/1143-route53_health_check-update-delete-by-id-and-name.yml Outdated Show resolved Hide resolved

use fqdn for examples, fix changelog variable names

9620848

mandar242 requested review from markuman and alinabuzachis July 6, 2022 17:51

alinabuzachis approved these changes Jul 6, 2022

View reviewed changes

markuman approved these changes Jul 7, 2022

View reviewed changes

markuman added backport-4 PR should be backported to the stable-4 branch mergeit Merge the PR (SoftwareFactory) labels Jul 7, 2022

tremble merged commit 8d3fec8 into ansible-collections:main Jul 7, 2022

patchback bot mentioned this pull request Jul 7, 2022

[PR #1143/8d3fec8e backport][stable-4] route53_health_check: Add feature to create multiple health checks without updating existing health check #1324

Merged

renovate bot mentioned this pull request Aug 8, 2022

chore(deps): update dependency community.aws to v4.1.1 linxside/ansible-ee#44

Merged

1 task

tremble mentioned this pull request Oct 5, 2022

[6.0.0] route53_health_check - Make health_check_name a required parameter ansible-collections/amazon.aws#1111

Closed

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

route53_health_check: Add feature to create multiple health checks without updating existing health check #1143

route53_health_check: Add feature to create multiple health checks without updating existing health check #1143

mandar242 commented May 10, 2022 •

edited

Loading

ansibullbot commented May 10, 2022

softwarefactory-project-zuul bot commented May 10, 2022

markuman commented May 11, 2022

mandar242 commented May 11, 2022

This comment was marked as outdated.

alinabuzachis left a comment •

edited

Loading

mandar242 commented May 13, 2022 •

edited

Loading

This comment was marked as outdated.

alinabuzachis commented May 16, 2022

markuman commented May 16, 2022 •

edited

Loading

mandar242 commented May 16, 2022

markuman commented May 16, 2022

alinabuzachis commented May 17, 2022

markuman commented May 17, 2022

markuman commented May 17, 2022

markuman commented May 17, 2022 •

edited

Loading

alinabuzachis commented May 17, 2022

mandar242 commented May 17, 2022

markuman commented Jul 1, 2022

softwarefactory-project-zuul bot commented Jul 1, 2022

softwarefactory-project-zuul bot commented Jul 1, 2022

softwarefactory-project-zuul bot commented Jul 5, 2022

softwarefactory-project-zuul bot commented Jul 7, 2022

softwarefactory-project-zuul bot commented Jul 7, 2022

tremble commented Jul 7, 2022

softwarefactory-project-zuul bot commented Jul 7, 2022

softwarefactory-project-zuul bot commented Jul 7, 2022

patchback bot commented Jul 7, 2022 •

edited

Loading

route53_health_check: Add feature to create multiple health checks without updating existing health check #1143

route53_health_check: Add feature to create multiple health checks without updating existing health check #1143

Conversation

mandar242 commented May 10, 2022 • edited Loading

SUMMARY

ISSUE TYPE

COMPONENT NAME

ADDITIONAL INFORMATION

ansibullbot commented May 10, 2022

softwarefactory-project-zuul bot commented May 10, 2022

markuman commented May 11, 2022

mandar242 commented May 11, 2022

This comment was marked as outdated.

alinabuzachis left a comment • edited Loading

Choose a reason for hiding this comment

mandar242 commented May 13, 2022 • edited Loading

This comment was marked as outdated.

alinabuzachis commented May 16, 2022

markuman commented May 16, 2022 • edited Loading

mandar242 commented May 16, 2022

markuman commented May 16, 2022

alinabuzachis commented May 17, 2022

markuman commented May 17, 2022

markuman commented May 17, 2022

markuman commented May 17, 2022 • edited Loading

alinabuzachis commented May 17, 2022

mandar242 commented May 17, 2022

markuman commented Jul 1, 2022

softwarefactory-project-zuul bot commented Jul 1, 2022

softwarefactory-project-zuul bot commented Jul 1, 2022

softwarefactory-project-zuul bot commented Jul 5, 2022

softwarefactory-project-zuul bot commented Jul 7, 2022

softwarefactory-project-zuul bot commented Jul 7, 2022

tremble commented Jul 7, 2022

softwarefactory-project-zuul bot commented Jul 7, 2022

softwarefactory-project-zuul bot commented Jul 7, 2022

patchback bot commented Jul 7, 2022 • edited Loading

Backport to stable-4: 💚 backport PR created

mandar242 commented May 10, 2022 •

edited

Loading

alinabuzachis left a comment •

edited

Loading

mandar242 commented May 13, 2022 •

edited

Loading

markuman commented May 16, 2022 •

edited

Loading

markuman commented May 17, 2022 •

edited

Loading

patchback bot commented Jul 7, 2022 •

edited

Loading