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 handling of complex RPC's #591
Conversation
Also includes a fix for #582 now |
Hi , Looks to be working fine without this fix ,Could you please verify once with latest Ansible collections.
@chidanandpujar No branches or pull requests You’re receiving notifications because you commented. |
As per @chidanandpujar comment, it is working without your changes. |
These changes work for me to resolve the issues I noted in #589 - I believe them to be safe and not cause any changes in behaviour (mostly because it doesn't appear the current behaviour works) but I don't have an extensive library of tasks to check these against as I'm working on a brand new deployment. But you may want to rework them, as I'm not familiar with ansible's best practices for module development.
This change does three things:
Port usage of _check_type_dict to support Ansible 4+
I've tried to maintain compatibility with Ansible 2.9 by adding a fallback.
Changes the type of attrs, kwargs, and filter to list, avoiding round-tripping them from list to string to list. This is a problem, because safe_eval will not process lists with certain keywords that are common in JunOS configs.
I believe this is a safe change, as if a user has e.g. "kwarg: 'foo'" Ansible will transparently convert it to "['foo']".
Allows an RPC to have nested configuration - this is required for e.g. validate, which needs to generate:
This is done recursively.