Is there a standard for argument validation in an action plugin?

Get Help
1

This may be just something that is simple that I’m overlooking.

I am developing a set of action plugins for working with our salesforce instance. I’m relatively new to module/plugin development.

There is a well defined standard for doing argument validation in a module with a defined argument spec. It even handles callbacks to validate via checking an environment variable.

I’ve seen some examples, and looked through several bits of the core code, and it seems like the argument validation is handled differently for each.

I want to make the code so there is a possibility that I might be able to contribute it back to the community at some point. I am wrestling with the idea of handling it with some code in module_utils so it works for the entire collection, but before I go down that road, I want to make sure that I’m not missing something obvious.

2

Depending on which ansible-core versions you support, you will find that ActionBase has helper functions for this, like validate_argument_spec(). This was added in Action Plugin argspec validation by sivel · Pull Request #77013 · ansible/ansible · GitHub, which got into ansible-core 2.13.0 apparently. Right now a few action plugins in ansible-core use it (pause, debug, script, async_status, and validate_argument_spec according to a quick grep); none of the collections I have checked out locally use it so far.

If you need to support older ansible-core versions, you can use the argument spec validator (ansible/lib/ansible/module_utils/common/arg_spec.py at devel · ansible/ansible · GitHub) directly, it was added for ansible-core 2.11. If you need to support ansible-base 2.10 and Ansible 2.9 as well, there’s nothing there - I created community.crypto/plugins/plugin_utils/action_module.py at main · ansible-collections/community.crypto · GitHub a longer time ago which copies the needed code and uses it before ansible-core 2.11, and uses ArgumentSpecValidator for ansible-core 2.11+. I wouldn’t use this for new code though, unless you really have to support ansible-base 2.10 and Ansible 2.9 as well.

1 Like
3

Thank you so much. I see it now.

That is exactly what I was looking for. I should have started with ‘debug’ because it’s there staring me in the face. lol

You’ve saved me a lot of misery with this.

Not sure if this needs to be another topic, but I would really like to support diff mode with this, is that even possible?

4

To find out whether a diff is wanted, you can check self._play_context.diff. That’s equivalent to module._diff for modules. Besides that you simply have to return the diff key in the return values, same as for modules.

Something you have to watch out for is no_log, since you have to handle this yourself for action plugins: if you have no_log=True in your argument spec, you have to take care yourself to censor that value when outputting it somewhere.

Also note that ansible-test’s sanity checks will not compare the argument spec to the documentation to see whether there are differences.

1 Like
5

I eventually found the value in self._task._diff eventually, but I know there can be ill effects if I’m not reading it from the right place. So I’ll get that switched aroundI’m pleased to say that the diff mode is beautiful though.

I’m glad you mentioned the no_log bit, because there is definitely some things for that.

I’m going to work on figuring out testing today. It seems there is a myriad of tools for testing, but I will start with ansible-test.

6

I’m not 100% sure it is really the right place, but at least it did work fine for me so far :slight_smile: Maybe someone from @Core can comment on this? Would be nice to know what the right place to get this (and similar values) from is.

7

Planning on making the same validation from modules to work for action plugins Controller argspec by bcoca · Pull Request #79720 · ansible/ansible · GitHub, but not there yet. Some core action plugins do add validation, but we are no where near to something that is standarized.

8

play_context should not be used by action plugins when task has the same property, it is a ‘temporary’ copy for when tasks are not yet templated, which should not be the case by the time the action plugin is loaded.

If you need to find the source for the different properties assigned to module, like diff, see this part of the code: