How to make module work with older systems

[mcso...@redhat.com]

Hi folks, I have run into https://github.com/ansible/ansible/issues/28813 - git_config not working with el6 systems. I would like to get it fixed, and I am happy to do so myself.

What is the best way to handle such compatibility issues? I am working on lvm2 and we face similar issues there - older versions not supporting certain options and it is getting worse when newer versions do require the option.

I guess module just should check git version, and ideally store it somewhere for future use, so it does not need to run git version each time.

Is it common for modules to "gather facts" - e.g. in this case get git version "git.version" and perhaps feature flags - "git.flags.supports_includes" and save it?

Is there a convention or other way to define a "module" namespace for facts discovered during run-time, or are any gathered facts polluting global namespace?

And if multiple modules are using git, it would be rather shared, than each module doing it on its own.

Would I then need a mechanism for invalidating facts (e.g. when updating system), so they would have to be rediscovered?

Minor updates should be fine, and I am not sure doing major system upgrades inside a playbook is the best idea. Clean install and use ansible for configuration seems much cleaner to me.

Cheers,

-- Martian

[Toshio Kuratomi]

On Oct 19, 2017 1:04 AM, <mcso...@redhat.com> wrote:

Hi folks, I have run into https://github.com/ansible/ansible/issues/28813 - git_config not working with el6 systems. I would like to get it fixed, and I am happy to do so myself.

What is the best way to handle such compatibility issues? I am working on lvm2 and we face similar issues there - older versions not supporting certain options and it is getting worse when newer versions do require the option.

I guess module just should check git version, and ideally store it somewhere for future use, so it does not need to run git version each time.

Cache invalidation is one of programming's harder problems.  So, solve the git version problem but ignore the urge to cache your results for now.

-toshio

Is it common for modules to "gather facts" - e.g. in this case get git version "git.version" and perhaps feature flags - "git.flags.supports_includes" and save it?

Is there a convention or other way to define a "module" namespace for facts discovered during run-time, or are any gathered facts polluting global namespace?

And if multiple modules are using git, it would be rather shared, than each module doing it on its own.

Would I then need a mechanism for invalidating facts (e.g. when updating system), so they would have to be rediscovered?

Minor updates should be fine, and I am not sure doing major system upgrades inside a playbook is the best idea. Clean install and use ansible for configuration seems much cleaner to me.

Cheers,

-- Martian

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/54f31f3f-1030-4c58-aa46-6a7ef30d4aee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mcso...@redhat.com]

On Thursday, October 19, 2017 at 3:11:17 PM UTC+2, Toshio Kuratomi wrote:

Cache invalidation is one of programming's harder problems.  So, solve the git version problem but ignore the urge to cache your results for now.

-toshio

That's true, and ansible is already caching a good deal of information subject to change - for example logical volume sizes which can change automatically outside of ansible control - e.g. thin-pool or snapshot can grow when over threshold, and it is strongly recommended to set it up that way for thin-pools.

So I wonder if it would be a good idea to have an implicit "notify" for updated packages.

For updates outside of ansible control - there is a space for TOCTOU race anyway.

Also in this particular case, when git does not support includes, the whole configuration must take that into account, and better there are no includes to rely upon. So I am prone to think it would be an improvement to have that flag in facts and available globally.

And the next thing: to use git_config, the git must be installed, so it is most likely preceded by an equivalent of `package: name=git state=present`.

-- Martian