Add ability to run on Fedora

[smacz42]

All I did was split the installation tasks in tasks/main.yml into tasks/apt.yml and tasks/dnf.yml which will be determined by the ansible_pkg_mgr variable that is gathered in the beginning of the play.

Several tasks were not necessary using DNF, but the basic structure of the tasks is the same.

Two variables got renamed to differentiate the difference in required packages on apt-based systems vs dnf-based systems.

The documentation has also been updated to reflect these changes.

[nickjj]

Hi,

Sorry for the delayed response. Missed this in my inbox.

I really do appreciate the contribution but I would feel uncomfortable merging this because I don't work with Fedora on a regular basis. It also gives the impression that the role may also start supporting CentOS and other distros which I'm not crazy about because I don't use those distros personally.

[smacz42]

Even though you don't work with Fedora, I see that you use travis for your CI, which should be able to test this role against Fedora with no additional work on your part if I add the tests. Since the differences are only in the installation and not in the setup, I don't see much of a problem with maintenance as it stands. What changes for one of them will most likely be changing for the other too.

As this is one of the most popular docker installation roles on galaxy, I would hope there would be some way to integrate support for other distros. Is there some work that could be done to get this support added?

[MindTooth]

Could it easily be updated to include support for CentOS as well?

[nickjj]

Anything could be done, but the issue is I do not run CentOS in production so it's difficult to maintain those distributions from a role level. If you want support for those distributions you might want to create a local fork, or look for another Docker role that supports them.

[Sispheor]

@nickjj about supporting other Distro you can add testing framework like Molecule.

[nickjj]

@Sispheor I have an automated test suite running which supports multiple distros. The issue is, I don't want to make this role a lot more complex and be responsible for supporting code for operating systems I do not personally run in production.

[Sispheor]

I understand.
But if we fork, we split the community.
The fork would support other distro and so the community would not even have to use the main one.
My point of view is that it's better to federate people around the same thing.
Linus Torvalds doesn't use all modules available in the Linux kernel but still merge stuff from the community.

[nickjj]

It comes with a lot of baggage to redesign the role to support more than just Debian based distros.

For example, for setting the Docker version it expects being able to set apt pins, so if we wanted to keep the same API and functionality, every supported distro would need to support the same pin features as Debian.

Then there's dealing with things like users and groups, which I'm not sure works the same on Fedora.

Then there's installation specific things, like the location of where binaries are and whether or not the distro uses systemd because a lot of the configuration of this role expects a specific version of systemd to be present. The same goes for cron jobs.

And finally, we have all of the apt specific variables. We would need a completely different set of dependencies for every distro and also ensure it works for multiple supported versions of each distro.

Then, there's having to create specific tasks to detect which distro tasks should run, which slows down the role for everyone. Then, there's rewriting the documentation to support all of the variables and somehow trying to expose everything in such a way where the role defaults aren't changed too much to keep backwards compatibility to a maximum.

Then, it would also require for me to become an expert in Fedora, CentOS, RedHat and others because I wouldn't feel comfortable merging in PRs without really being able to understand and verify the changes being made. Tests help, but they don't catch everything and they don't help determine best practices, etc..

I'm not saying it'll never happen, but it's not really as simple as just adding 50 lines of yaml and calling it a day. There's a lot of implications.

[Sispheor]

The most used repo is already dealing with this part of multiple distro.

After that, you would not have to become an expert or each distro. The community would enhance and fix stuff for you and final testing script would be the same for all and validate that we have Docker working at the end of the process.

About user: Ansible already provide a module that do the interface. So same for both Redhat/Debian family. You already use this module in your role so no change required.

About systemd: Both Debian and RH use systemd

completely different set of dependencies: yes. So depending of the "ansible_os_family", run a single task that takes care of dependencies.

Actually, I'm looking for a repo that is alive with a good community where I can contribute. The geerlingguy repo is nice but not updated often.

After all those years with Docker, we still don't have a "Rockstar Ansible repo" to install it.

[nickjj]

Those are fair points but I kind of like trying to be a dependable Debian / Ubuntu based choice for installing Docker / Docker Compose. I think this role got to the point it has because I'm comfortable working with these distros and have used this role in dozens of real projects over the years.

I do appreciate community support, and there have been a number of PRs merged in by others in this role, but this process requires all code to be thoroughly reviewed and tested before it gets merged. I can only do those reviews when I fully understand the implications of what the changes do.

Also when support issues start rolling in for Fedora or CentOS, I'm not going to be able to answer those questions without an extensive amount of Googling since I'm not familiar with how they work. When weird edge cases arise, I wouldn't feel happy having to answer someone "sorry, I never used CentOS in production before".

It doesn't seem like the right move to drastically complicate this role in all areas (implementation, documentation and support) to add additional distros that 3 people have asked for in 4 years.

I continue to leave this PR open because if tons of people start requesting support for these distros and some folks step up and commit to being able to do full time support for it, then perhaps support could be added to the role in the future.