Bug 1565223

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

repo: https://softwarefactory-project.io/r/software-factory/sf-config
file: ansible/roles/sf-influxdb/tasks/influxdb_configuration.yml

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
https://storyboard.openstack.org/#!/story/2001736

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.