Create role to wrap new tower_inventory_source_update module about controller_configuration

[sean-m-sullivan]

Going to bring this up in meeting later this week, however, We have been skipping the update and other modules, should we add these in as roles in tower_utilties, or here?

[ericzolf]

I make the difference in my head (we should actually document them more formally):

• tower_configuration: tower is installed, everything independent from the underlying platform (pure OS or OpenShift), mainly a wrapper of awx.awx.
• tower_utilities: everything with a relation to the underlying platform (prepare, install, backup/restore) and/or with no relationship to awx.awx.

With those criteria, it's a clear candidate for the configuration collection, but those are my criteria.

[sean-m-sullivan]

That makes sense to me, and makes it clear. I was unsure so posed the question.

[sean-m-sullivan]

I went over all the modules and roles and all the current roles are up to date. I've found the following modules that could reasonably be used to be added.

In development:
tower_ad_hoc_command - tested and created
tower_ad_hoc_command_cancel - tested and created
tower_inventory_source_update - in progress
tower_project_update
tower_job_launch
tower_job_cancel
tower_workflow_launch

Not slated for development: The wait ones are problematic to do as a loop
tower_ad_hoc_command_wait
tower_job_wait
tower_export
tower_import
tower_job_list
tower_token
tower_meta

Depreciated:
tower_send
tower_recieve
tower_workflow_template - old version of this module

If there are modules not slated for development listed, that we think we should develop, please respond.

[sean-m-sullivan]

Haven't heard any movement on this, we can reopen a new issue if we want these modules, added, but do not see the need at this time.

Modules not implemented:
tower_ad_hoc_command_wait
tower_job_wait
tower_export
tower_import
tower_job_list
tower_token
tower_meta