subclassing ActionModule classes

[jhawkesworth]

Hello

I'm working on versions of file copy and template for windows.

I've push a 'first pass' PR here https://github.com/ansible/ansible/pull/9611 and here https://github.com/ansible/ansible-modules-core/pull/384 but there's things I want to improve, specifically the action plugins, which at the

moment are pretty much copy 'n' pasted versions of their non-windows counterparts.

So obvious thing to do is subclass ActionModule and just have the windows versions doing windows things.

I notice there's no precedent for this at the moment.  Is this just because the need hasn't really arisen or a desire to keep

things simple.

Thought it was worth asking before I plunged in.

BTW I'm also going to move the file hash functions to use SHA1

Jon

[Michael DeHaan]

module_utils/ has a good place to put shared code, and has a common library of powershell things therein.

There is no provision for subclassing, but this will get you the capabilities you want, I think.

--
You received this message because you are subscribed to the Google Groups "Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-deve...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jhawkesworth]

Thanks, that's a good idea I'll look into using module_utils/ - I was more thinking along the lines of reusing the python logic used for templates (where most of the good stuff is happening on the controller not in the actual powershell modules), but no reason I couldn't pull some of that into module_utils.

[James Cammarata]

Also, for what it's worth, using a base class for each individual plugin type is something I'm actively working on in the v2 branch of code. For example, all action plugins, connection plugins, etc. will have their own base class to share code and remove these redundancies.

[Chris Church]

We don't really have a precedent in 1.x for subclassing action plugins. Since the only differences between copy/win_copy and template/win_template are the remote modules they use (copy vs. win_copy, file vs. win_file), I think it would make sense to define those as variables.

For example, lib/ansible/runner/action_plugins/template.py would add the following class variables and use those instead of the hardcoded module names:

class ActionModule(object):

file_module = 'file'

copy_module = 'copy'

# ... the rest of the module

That change would allow lib/ansible/runner/action_plugins/win_template.py to be implemented as nothing more than this:

from ansible.runner.action_plugins.template import ActionModule as BaseActionModule

class ActionModule(BaseActionModule):

file_module = 'win_file'

copy_module = 'win_copy'

module_utils/powershell.ps1 is still the best place for code shared between remote modules.

Thoughts?

[jhawkesworth]

I like it.  It only adds a little complexity in return for some good reuse.

For what it's worth I have a windows unarchive module which I'm working on which where I'd like to reuse the unarchive action plugin in the same way.

[Michael DeHaan]

Seems like a good idea to me - I'm open to exploring it under the v2 subtree once we fold it in, and should keep track of this idea for now.

Right now, I'm trying to lock down core changes on the old branch, and we'd likely have to repeat efforts slightly as this moves over.

[jhawkesworth]

I have updated  https://github.com/ansible/ansible/pull/9611 with the 'copy and paste' implementations for now.  Sounds like it is just the wrong time for this particular idea, but people can at least try out the modules now even if v2 subtree needs to be ready to go before it actually gets merged in.

Jon

[Michael DeHaan]

Thanks -- we're going to plow through things though this should be easier soon.   Appreciate your bearing with us.