Description of problem:
I would like to introduce advanced karma bot to #rdo, #softwarefactory and other interested channels on freenode and other networks and provide detailed community statistics as well as a nice way to explicitly express gratitude for others' work.
Please don't underestimate the impact of such tool just because default implementations are basic and limited in usefulness. Let me demonstrate the possibilities, I just need a machine :)
Especially, I require persistant database storage because I intend to properly analyze the data over time so losing them periodically defeats the purpose.
In other words I need:
a) persistant backed up machine where I will run the bot and the database myself
b) a replacable VM and a backed up database storage somewhere
Thanks in advance for you help.
I wonder if we could reuse influxdb included in Software Factory for this, since it's "data over time".
This could be also expanded to feed a general "badges" system like https://badges.fedoraproject.org/about
So, my biggest doubt is where to place this service. I'm not sure we should dedicate a full VM to this, maybe we can reuse some existing machine?
The rdobot is running on the Sensu server, maybe we could centralize the new bot there. wdyt?
Influxdb describes itself as "scalable datastore for metrics, events, and real-time analytics" which sounds exactly like what I need - I'm happy to try that.
And yes, I'm also wondering where to place this service for a long time, yet anywhere is fine, really. As long as I have sufficient access to the machine to maintain the bot without bothering anyone else, I don't care which machine in particular.
It is easy to create a dedicated db in influx with a specific user and credential for your bot (to avoid to use the same db than sf metrics). I can create a short doc if needed. The db and user creation are describe in sf-config ansible role for influxdb
I was looking at InfluxDB and related tools and it indeed looks like the right tool for the job.
Once the data are in InfluxDB there are many ways to visualize/aggregate them.
So having found the DB, I can ansiblize the whole thing and not care where it runs at all ;)
Running along rdobot sounds good to me, so what about the Sensu server Javier mentioned?
I need to know the system it's going to run on and available libraries to proceed further.
> maybe we could centralize the new bot there
It's just new plugin, we should reuse the same bot vs adding new one, but for development and testing, new staging bot environment would be good.
Feels like we need a containers management solution (hint: starts with O, ends with T) to run all those apps!
Related, IRC Bot Consolidation in openstack-infra
So upstream is likely to use limnoria, the supybot descendant which makes sense given it's compatible with currently used supybot plugins.
Certain top secret bot instance I'd like to integrate with also uses limnoria.
Finally, rdobot uses errbot but there is no explicit reason binding it to that framework.
Without too deep research (I wrote a simple plugin) I found errbot to be a better implementation, but limnoria seems not horrible so I think proper solution would be to align with upstream.
I could add my karma plugin to rdobot which is ansiblized and already runs somewhere, but that's errbot. Maybe we should port it to limnoria to achieve unity instead.
Also, there seems to be no active driver for the upstream IRC Bot Consolidation effort so if we had a strong case for errbot we could discuss using that instead, but that doesn't seem like a path of least resistance to me.
So at this point I still don't know which bot or which machine to use :-/
Let's see David's opinion. If I were to implement this, I'd go for an errbot extension and run it on the same server as rdobot.
Karma in the description is just one use-case,
should we consider more general ChatOps approach?
BTW for community activity tracking might be worth integrating with badges.fedoraproject.org
We have not had any activity in the bug for a long time, closing. Feel free to reopen if you think this is needed in the RDO infrastructure.