Rocket.chat Rockon non-functional

[Hooverdan96]

Based on @wwwizzarrdry's comment I took a stab at getting the rocket.chat Rockon to run. Same negative outcome unfortunately. When reviewing the logs it seems that the current Rockon is missing some settings (related to Mongo DB) that are now required in the newer versions of rocket.chat.
When I reviewed the installation information on their website, it seems it now relies on some Mongo DB replication service (or something to that effect) that requires an additional container to be run once separately (mongo replica container)
So, I suspect the Rockon needs to be revamped and some install docs need to be created (or maybe the rocket.chat solution docks are sufficient as reference).

[phillxnet]

@Hooverdan96 Or maybe we just drop this Rock-on. Especially given we have heard nothing more about it's dis-function in the past few months. So quicker to just drop and the additional requirements adds complexity which could increase it's instability/moving parts. I don't myself see chat servers as a likely high-on-the-list item for Rock-ons myself. And the lack of feedback on this breakage may be evidence that at least this one is not a popular choice for at least our current users.
As always @FroggyFlox your thoughts are welcome here.
I think within this repo we need to be a little more active in simply removing Rock-ons if they fall out of repair, especially as our Rock-on maintenance teams is not growing in proportion to the Rock-on count. Hence if folks wish to maintain they can always pick a prior broken Rock-on from git history and mend as they see fit: and if it's in keeping with our current standards (such as they are) we can always re-introduce.

Obviously not keen on discontinuing stuff that folks have running but there has been zero interest/feedback since this issue was opened on this particular Rock-on ( > 3 months) and from what I read it's basically dead in the water from our point of view: hence delete suggestion. It's forever in our git history anyway.

[magicalyak]

I'll try to look at both but should I resubmit new ones or try to fix the old ones?

[phillxnet]

@magicalyak Hello again, yes I think new ones is the way to go now actually. We really need to clean house of all broken Rock-ons in this Repo as we have limited resources they end up hanging around for an unreasonable amount of time before fixes end up arriving. Hence the new proposed policy of delete rapidly upon broken states having been verified. This gives our developers more time to re-introduce and test well without casuing folks to continually fall over a known broken Rock-on untill we get around to fixing it. Deletes can be done (tested) pretty fast, but fixes always take far longer to 1) be provided, and 2) be reviewed. So hence the delete first and re-introduce if the skill/will is forth-coming.

Nice to hear from you again by the way.