Add a selection of DebOps roles for apps not yet covered

[ypid]

CC: @drybjed, @it-praktyk
Updates/supersedes: #13

[jdauphant]

Thanks @ypid for your efforts.
I am sorry but this list isn't for the promotion of all debops works, no offense.

There alternative of roles your propose, some are more popular.
Why promote https://github.com/debops/ansible-gitlab and not https://github.com/geerlingguy/ansible-role-gitlab ?
debops/ansible-elasticsearch have 3 others alternatives, like the one from elastic: elastic/ansible-elasticsearch that have 10 times more stars.
I am not saying your roles are less good, but it's a complicated to accept that because of your involved in debops.
We have a bias about our own contributions.

I have 80 github project about Ansible and I still have only put 3 on this list:

• jdauphant/ansible-role-nginx -> the second stared role of galaxy
• jdauphant/ansible-freebsd-playbooks -> the most stared ansible freebsd playbook example (that I may remove because it become to be old)
• jdauphant/patch-openssl-CVE-2014-0160 -> that have been feature by ansible blog and show an example of a quick playbook to patch a lot of servers

I didn't put role like jdauphant/ansible-role-ssl-certs because it's still uncertain that's the best way to do it.

[ypid]

Why promote https://github.com/debops/ansible-gitlab and not https://github.com/geerlingguy/ansible-role-gitlab ?

@drybjed wrote this together for the debops nginx role compared to the nginx role by geerlingguy on reddit. Could not find it right now but in short: When you compare DebOps roles with most of the other roles (even those with 3 digit+ stars) you will find DebOps roles are really well designed and all of the DebOps roles fit nicely together. Plus they are really well documented.

I could not even find one word about databases in https://github.com/geerlingguy/ansible-role-gitlab which apparently installs gitlab. Compared to that, https://github.com/debops/ansible-gitlab does everything for you.

@drybjed and me often face the situation when needing a role for something that all the existing roles are far too limited for the long run so a proper one has to be written from scratch.

So, it is not always about github stars :) An analogy might be MS Windows (more "stars") vs. GNU/Linux (better designed and succeeding in the long run) on the desktop.

[jdauphant]

Ok

I totally agree that stars isn't attesting the quality of the project. For Ansible, I have nearly created half of the Ansible roles that have used because I wasn't satisfied by their design.
And I also use FreeBSD over GNU/Linux, because I prefer the FreeBSD design (this sentence is just here to advertise about FreeBSD).

Objectivity

To return to the PR, you come with 8 of your roles, I have to inspect the objectivity.
I am sure that you are convinced that you do better (but you still are member of the Debops project).
Good points for Debops project is your multiple contributors that share the same value and develop Debops but it's not enough to convince me to add all the roles.

If I merge it, I will have objectivity problems on the roles sections (2/3 of the roles will be yours). I will need more to justify that I didn't have the time to review all the projects.

Some minor search in the role

Interrogating thing

• all the roles have dependencies (at the minimum debops/ansible-secret )
  • I tend to be dependency less, I don't now the necessity of debops/ansible-secret
  • I personally don't like dependency, I prefer composition. You will see that are commun rule of all of my roles. I also didn't like the dependency management of Ansible
• access to the documentation take lot of steps (I particular to access the first example)
  • I didn't have example on the repository
  • After accessing the docs, I have to click to access the first example
  • the link in debops/ansible-gitlab is broken
  • I personally have preferences for roles that have documentation in the README, it will appear in Github and Galaxy (When you want to get things done, I didn't have the time to explore everything and done is better than perfect, personal point of view)
• I have difficulty to read the "defaults/main.yml", I prefer code as documentation and don't like too much verbosity in comments (personal point of view, I know that the comments are used to generate the documentation, but I prefer not having to generate the doc and instead having a highly readable code )

Good stuff

• using list or map for nginx role but the multiple yaml
• Focusing on one OS is a good thing also, because having multiple OS and wanting to manage it the same way is an edge case, we should do the roles that manage well 80% of the usecase

Conclusion

It's just surface and little research, I didn't cover a tenth of what I should do.
I just didn't know because I didn't have the time to explore that.

You can put role conventions and/or articles about your positions. (I have my own conventions in mind but never take times to write it).
I didn't have time to go further, I will let people intervene (it's probably better that isn't a Devops team member).
If you role are better and get used: It will also be proved by time and will have naturally a better fit for this list.

[jdauphant]

Also just to be clear, I didn't judge the project as a whole (already done with #9) but the debops roles as individual projects

[ypid]

Thanks for your detailed feedback!

I tend to be dependency less, I don't now the necessity

Agreed if convenient. Most of the dependencies of DebOps are "soft dependencies". Ref: debops/debops-playbooks#192

the link in debops/ansible-gitlab is broken

Good point, I thought that might come up :) Fixed (but it might take awhile for it to get built).

I personally have preferences for roles that have documentation in the README

Would make the README pretty long for some DebOps roles :)

I didn't have time to go further, I will let people intervene (it's probably better that isn't a Devops team member).

Sounds good to me. Lets see what the time brings. I will take a step back from the issue then :)

[jdauphant]

I personally have preferences for roles that have documentation in the README

Would make the README pretty long for some DebOps roles :)

There not need to put all the documentation in the README, but the basic stuffs to start with it could be helpful (and examples, they are the best way to get somethings).