-
Notifications
You must be signed in to change notification settings - Fork 23.8k
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
Improve route53_facts to modern Ansible standards #31860
Conversation
There are a lot of changes here, but given the module's current return values are undocumented and the module is in preview status, I hope that the changes are acceptable. I have tested them against my existing route53 resources, they seem to work |
e58b4f9
to
c0fe95b
Compare
@mikedlr this PR contains a change to module_utils.aws.core to support the |
c0fe95b
to
dc87d69
Compare
I have tested this with our current |
try: | ||
return list_record_sets_with_backoff(client, params) | ||
except (botocore.exceptions.ClientError, botocore.exceptions.BotoCoreError) as e: | ||
module.fail_json_aws(e, msg="Couldn't list record sets") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If providing a hosted_zone_id that has been removed, this fails. Should it fail, or should record sets just be an empty dict if e.response['Error']['Code'] == 'NoSuchHostedZone' in list_record_sets_with_backoff()? Wondered something similar throughout reading this PR in a number of other places too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this spot @s-hertel - it's a great catch. To be honest I think it's a flaw with AWSRetry that this happens - retries for not found should be handled by calling functions.
But until there's consensus on that, I'll add a fix for this.
Edit: Ah, I'm thinking of retries for NotFound codes, this is a different situation. It's a tough call - I'm not sure whether it's better to return an empty result for a non existent hosted zone - in some ways the error message is clearer.
|
||
results = client.list_reusable_delegation_sets(**params) | ||
else: | ||
if module.params.get('delegation_set_id'): | ||
params['DelegationSetId'] = module.params.get('delegation_set_id') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think 'DelegationSetId' needs to be 'Id'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, I did not change this, how long has this bug been present! (Thanks again for spotting this)
next_marker: "{{ first_facts.NextMarker }}" | ||
max_items: 1 | ||
when: "{{ 'NextMarker' in first_facts }}" | ||
RETURN = ''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hurrah for RETURN docs :)
* Use built in retries, pagination * Return snake case * Document returns * Better tag handling * Deprecate resource_id parameter * Deprecate tags query method * Fail on multiple resource_ids
dc87d69
to
0635992
Compare
@s-hertel I've fixed the delegation set id bug. I think a module failure for a non existent hosted zone seems reasonable. |
@@ -43,15 +43,8 @@ | |||
required: false | |||
max_items: | |||
description: | |||
- Maximum number of items to return for various get/list requests | |||
required: false | |||
next_marker: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why delete the docs for the next_marker? IMO we should entirely remove the max_items and next_marker settings and use pagination internally, there doesn't seem to be a good reason to expose these. Obviously needs to be supported still for the deprecation cycle, but it seems like unnecessary complexity.
- name: setup of example for using next_marker | ||
route53_facts: | ||
query: hosted_zone | ||
max_items: 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get de-emphasizing next marker, but we shouldn't remove the example entirely I don't think.
resource_id = module.params.get('resource_id') | ||
if resource_id: | ||
if len(resource_id) > 1: | ||
module.fail_json(msg='Using multiple resource_ids is no longer supported. Use a loop') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can fail out on this without a deprecation cycle first.
Hey, there is something preventing this PR to be merged? I usually need to workaround the route53 info module because of this problem, and this PR works very well. |
Thank you very much for your interest in Ansible. Ansible has migrated much of the content into separate repositories to allow for more rapid, independent development. We are closing this issue/PR because this content has been moved to one or more collection repositories.
For further information, please see: |
SUMMARY
Fixes #49457
ISSUE TYPE
COMPONENT NAME
route53_facts
ANSIBLE VERSION