Split up the tasks into different tasks files

[aoyawale]

Looks like the main.yml it starting to get huge and hard to follow. We should break it down into roles and follow best practices.

[aoyawale]

Same for the rest of the files now I looked more into it. I can start working on this and make it cleaner.

[aoyawale]

For now the roles dir would be in this git project but, it would be better in the long run for each role to be its on project.

[aoyawale]

for the moment since we would need more projects to host the other roles. I'll convert this into tasks files instead. I'll still leave the roles area until that is decided.

[TheReal1604]

@jlozadad @xenithorb I think the things should be split up in roles - the ansible way is little niche to install rocket.chat - maybe for bigger deployments which need more automation in an easy way. Would be cool to have that. I would fork that repo and try to split it up - what you think guys?

[aoyawale]

@TheReal1604 I agree that it should be roles but, since there's barely any activity and such, I was trying to commit things to what we have right now. If we do roles then we should create a git repo for each.

[xenithorb]

In my professional life I would do exactly that, split things into per-repository roles and make them as modular and decoupled as possible. That being said, this role has always been a rather opinionated take on how to deploy a single instance of rocketchat to debian, ubuntu, centos, etc.

In other words, the scope of the role was to get things up and running with your choice of operating system, without trying to be a showcase of modern ansible best practices (this role started way before me and I picked it up somewhere around version 1.8)

The other aspect to this is that, from my observation, RocketChat hasn't expressed any direct interest to me in improving this role and seem to be very solidified around the snap platform. I too have moved onto various other containerized platforms and I also question whether ansible is still a way forward for deploying this software. That being said, I still use it for my own instance.

At the risk of hating my own words, the main.yml is huge indeed but if it works why fix it? And if it doesn't work, is it because main.yml is lengthy? Are you looking at develop? I merged a huge set of changes last month. I may have already split certain things, I'm just terrible about merging them into master because I haven't been able to maintain testing reliably enough (I find vagrant very porcelain and travis is even worse in terms of things breaking over time) in order to stamp it for production.

[TheReal1604]

@xenithorb thanks for your sight.

At the risk of hating my own words, the main.yml is huge indeed but if it works why fix it? And if it doesn't work, is it because main.yml is lengthy? Are you looking at develop? I merged a huge set of changes last month. I may have already split certain things, I'm just terrible about merging them into master because I haven't been able to maintain testing reliably enough (I find vagrant very porcelain and travis is even worse in terms of things breaking over time) in order to stamp it for production.

Its just an improvement thing - make it more "future proof" or you need a complete rework at some point in the future. :) I use ansible also to administrate our docker-hosts, rocket-chat itself is deployed via docker, mongo also. Maybe this could also be a way to go? Do you have any specific improvements in deploying it directly with all the depencies?

Anyways - thanks for the great work, That playbook looks like very much time invested til now. 👍

[aoyawale]

whatever works its fine by me. Either update this role or create multiple roles or create something more into containers. Although I seen more areas use RC in containers, there's still the use of ansible with containers.