-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Cleanup a deprecation warning (ipaddr filter) #10518
Cleanup a deprecation warning (ipaddr filter) #10518
Conversation
Hi @VannTen. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
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.
Hey Max, look like we have crossed path again :D.
Thanks for the PR, cleanup PRs are always very much appreciated 🙏 .
I have a small comment about dependencies, galaxy compat is still somewhat very new in Kubespray and we didn't hear that much from users about it. I think we would be very interested about any improvement in that area. I have left a small comment about dependencies, let me know if you have any insight into that it would super nice! Otherwise lgtm as is.
/lgtm
@@ -9,6 +9,8 @@ authors: | |||
tags: | |||
- infrastructure | |||
repository: https://github.com/kubernetes-sigs/kubespray | |||
dependencies: |
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'm wondering what we should do about dependencies in general here, we have some check mostly on ansible core that is required to be 2.14.x currently. I'm wondering how we should handle these things in galaxy though. Do you have insight about that? Maybe we could also add ansible-core there?
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.
Hi Arthur, long time no see indeed :)
I don't think ansible-core should go there.
From ansible docs on the subject, it looks like it's expected to treat ansible-core specially with the meta/runtime.yml file, and all other collections in the dependencies keys in galaxy.yml.
Note that they encourage collections authors to not depend on other collections, but I don't think kubespay should feel too concerned by that.
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.
Ok so I checked and I think ansible-core would be the same as the collection ansible.builtin. It seems to follow the same version (~ish). Could you add this to dependencies: ansible.builtin: ">= 2.14.0 <2.15.0
(there's a bug in ansible-core 2.15 preventing to run kubespray currently).
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.
The way the above documentation is written, it looks to me that ansible-core should be treated specially and not put in dependencies
.
We recommend that collections work as standalone, independent units, depending only on ansible-core. However, if your collection must depend on features and functionality from another collection, list the other collection or collections under
dependencies
in your collection’sgalaxy.yml
file. Use themeta/runtime.yml
file to set the ansible-core version that your collection depends on.
To me that reads like deps check for ansible-core specifically should go in meta/runtime.yml
, as it is currently.
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.
Hmmm ok but then I'm wondering it is really useful to have a requirement on ansible.utils, shouldn't the minimum version of Ansible implicitly include that already somehow ?
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.
Apparently you can install ansible-core standalone, (but installing ansible would indeed have ansible.utils I think)
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.
Okok well then nvm both are fine then, as you want 👍
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.
And thanks for the valuable insights into this 🙏
/ok-to-test |
/lgtm |
a99a27e
to
8fbc3a9
Compare
Just occurred to me that I could just as well fix the other instances of |
/lgtm |
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.
@VannTen Thank you 👍
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: floryut, MrFreezeex, VannTen The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
What this PR does / why we need it:
Fix the the deprecation warning related to the ipaddr filter in calico role.
https://docs.ansible.com/ansible/latest/collections/ansible/netcommon/ipaddr_filter.html
Does this PR introduce a user-facing change?: