Consider hosting and running RITlug/teleirc NodeJS bots in Fedora's production environment using pre-defined Ansible role
Currently, a few sub-projects already use Teleirc with a bot hosted on telegram-irc.fedorainfracloud.org and there is currently an open Fedora Council ticket to consider an official endorsement of some Telegram groups / communities. For the groups that use Teleirc, it makes our IRC channels more accessible to those who find IRC difficult to use or have firewall limitations in place that prevent them from using IRC.
telegram-irc.fedorainfracloud.org
Recently, I used Ansible to automate the deployment of these bridge bots and put it all into an Ansible role, found here. There are likely some improvements to be made, but I believe this is a good first step to fully automated deployments.
I wanted to open discussion on if this is something Fedora Infrastructure is willing to consider. If Infra is willing to run this in production, then we can use my Ansible role and figure out a way to port the role to Fedora's Ansible environment.
This change means that if someone would like a new Teleirc bridge created, they would create a new ticket here to request one and provide the API token / chat ID for a member of Fedora Infra to use for setting up a new Teleirc bot.
I am happy to contribute supporting documentation for this, if desired.
We can discuss this at our next meeting / on list.
How responsive is upstream to issues/bugs/questions?
Would it be possible to run in openshift?
How often does it update or requite changes?
Metadata Update from @kevin: - Issue priority set to: Next Meeting (was: Needs Review)
I am currently the project lead and there are a few other developers involved. Responsiveness is not very fast, but there is a response. I would consider the project to be mostly mature in its current state.
Upstream provides Dockerfiles for Alpine and Fedora bases.
I would guess a major version upgrade once or twice a year and minor version upgrades every few months. Minor version upgrades usually require no changes to existing configs. Upstream adheres to semantic versioning.
Thanks for considering. :thumbsup:
hey @jflory7
I'm interested to know. Could we possibly use teleirc on top of matrix. That way any other new service that wanted a bridge in the future would just have to understand matrix and we're all in the same rooms.
Could we possibly use teleirc on top of matrix.
Hi @dustymabe. When you say this, what do you mean "on top of"? I'm trying to understand what you mean or what this looks like.
Could we possibly use teleirc on top of matrix. Hi @dustymabe. When you say this, what do you mean "on top of"? I'm trying to understand what you mean or what this looks like.
Disclaimer.. I'm in serious danger of talking about something I don't fully understand :smile:
Matrix is a protocol that can be the basis for many other clients to build on top of. There are matrix bridges for common platforms that already exist today. My thoughts are that if we could use set up an irc<->matrix bridge and a telegram<->matrix bridge then we have bridged irc/telegram (<irc<->matrix<->telegram). Then when the next new hot client comes out as long as there is a matrix bridge in place for it it can hook in as well and people can essentially choose to be on whatever client they prefer. Here is some of the faq: https://matrix.org/docs/guides/faq
irc<->matrix
telegram<->matrix
<irc<->matrix<->telegram
please someone who has more experience with matrix correct me where I'm wrong above
@vrutkovs - you might be able to help us understand ^^
Yes, https://github.com/tulir/mautrix-telegram/ would connect Matrix and Telegram rooms via a relaybot account (in Telegram chat) and Matrix contacts. This chat can also be bridged with an IRC room - Matrix contacts would appear as 'matrix_username[m]' by default.
There is also an option of full puppeting - Matrix bridge would act as MTProto client, so user messages in a bridged room would appear as if they were sent in a Telegram room. A similar situation with Matrix <-> IRC bridge
I see. I think I understand now. So, the tulir/mautrix-telegram bot is a fork / continuation of telematrix. I looked into telematrix before for this use case, but I share similar views to this blog post about its own challenges and difficulties to use.
I personally found the user experience lacking. In a non-Fedora channel I saw this implemented in, it added several new users to the IRC channel via Matrix, but if the person left the Telegram group, the member list didn't update. I found it hard to understand who was actually online and if someone were to mention a user's nick, it didn't actually send them a notification (something that is on the Teleirc roadmap).
This is my own personal experience with it and doesn't mean it isn't viable, but it's not my preferred method of bridging. Someone else would need to take initiative if this option is preferred though. I have enough bandwidth to dedicate myself to this approach using Ansible roles / container images to deploy RITlug/teleirc (because I already have a pre-existing involvement with that project).
Telematrix was pretty unstable. It used to disconnect without failing the container it was running in.
My personal Synapse +IRC bridge + Mautrix-telegram has been running in Openshift for ~6 month. Its been pretty stable so far, the metrics are especially useful to track the load
Okay, I see. This could be a valid option too then, but it is not something I can personally commit time to working on.
Also worth considering is that several of these Teleirc bridges already exist in the community.
Okay, I see. This could be a valid option too then, but it is not something I can personally commit time to working on. Also worth considering is that several of these Teleirc bridges already exist in the community.
:thumbsup: - my intent was to raise awareness in a possible future solution where matrix is the backbone and we bridge many different communication channels to it. The intent was not to derail your current efforts. Please proceed.
Agree, lets not derail this ticket and discuss Matrix-related things in https://pagure.io/fedora-infrastructure/issue/7399 instead
In general for these proposals we need to know: How much resources is needed - CPU - Memory - Disk - Database? (type and size per year) Who is going to take care of it when it breaks? Who is going to update it when things need updating? Who is going to write documentation for people to know how a service is supposed to work? Who is the person who will answer user questions? How is it managed? [This seems to be done via openshift and ansible]
@vrutkovs: Agree, lets not derail this ticket and discuss Matrix-related things in https://pagure.io/fedora-infrastructure/issue/7399 instead
This ticket probably affects that ticket, but if #7399 is approved and moves forward, the Teleirc bridges could be a short-term measure until that gets off the ground.
@smooge: How much resources is needed: - CPU
Minimal. Probably one or two?
@smooge: - Memory
~1-2GB, 4GB to be safe
For the existing 17 bridges I am running on #6781 today, memory usage is around 800-900MB.
@smooge: - Disk
No data from Teleirc is stored to disk. #6781 was allocated 40GB and currently uses 7.2GB after eight months of running between 10-17 bots.
@smooge: - Database? (type and size per year)
None. No data is stored by the bot. Things like images, videos, or files take advantage of the Imgur or Telegram APIs to send URLs over IRC.
The one advantage I like to the Teleirc bridges is that I can throw them literally anywhere and start running them without difficulty. There is no data to keep up with or migrate other than the configs.
@smooge: Who is going to take care of it when it breaks?
I'm happy to actively help with this until May 2019 (I'm already working on fedora-commops#189), but I will not be able to work on this after May 2019.
After May 2019, my hope is for Fedora Infrastructure to help running this if possible. I haven't come up with a plan yet for what will happen with the existing bots after May.
@smooge: Who is going to update it when things need updating?
Updating the bot means updating a task in Ansible. This could probably be abstracted to a variable. Take a look at this commit, it's pretty easy.
@smooge: Who is going to write documentation for people to know how a service is supposed to work?
I wrote the upstream docs. I'm happy to contribute a Fedora Infra-specific SOP to explain how to manage, configure, and deploy these bots.
@smooge: How is it managed? [This seems to be done via openshift and ansible]
I'm currently managing it with Ansible. I've battle-tested the Ansible automation over the last month or two. Theoretically, it should be easy to do in OpenShift too since upstream provides a Fedora container, but I've never tried it personally.
The problem here is that no one in infrastructure is using telegram (nor matrix or...) and have little time or energy to suck into them while doing our current work. We also have a very poor track record of running any sort of bots or other tools that do not have some sort of upstream team to care and support things. [Zodbot and other bots while run from Fedora Infrastructure are supported by volunteers who care and feed for them.]
Can you find others who are using telegram to help take over for you? That would help make sure that this is possible. [I am wanting to make sure that after May, we don't fall into a 'well its running in openshift, I have no idea if it actually connects or sends anything'. The same will go with the items in #7399 .
@smooge: Can you find others who are using telegram to help take over for you?
Could I start a SIG (similar to sysadmin-badges) for Telegram bridge administrators / volunteers? This way, the project runs in the production environment but I can invest more time into recruiting and training other sysadmins to help manage the bots other than just me.
sysadmin-badges
One way this could work:
sysadmin-teleirc
We could include the Ansible role in the master Ansible repo and run it on the host like this, or we could go for the OpenShift option. I haven't deployed to OpenShift before and would need to read more about it, but I'm willing to do this too with some initial guidance for Fedora's requirements.
Metadata Update from @smooge: - Issue assigned to smooge
OK the current plan will be: create sysadmin-teleirc which would allow for others to help run the server. continue to run this server in a cloud with the Service Level Expectation that this service is run by sysadmin-teleirc and they will maintain it/fix it.
@smooge This sounds good to me. :thumbsup: Thanks.
I have created said group and added jflory7 to it. Please let me know what I can do to help on this later. I am going to close this out for the mean time as I believe it will need further tickets when you are ready for things.
Metadata Update from @smooge: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
@smooge Thanks! No further action needed yet. I'll work on creating some resources around this group and promote it further over the next few months.
@jflory7 please fell free to add me to the sysadmin group.
@jflory7 I can help. Feel free to add me to the sysadmin-teleirc group.
@x3mboy @nb I want to document how I am doing things today with a SOP first before bringing new people in. If you're interested in helping, please chime in over on fedora-commops#195. Thanks!
Log in to comment on this ticket.