@awegrzyn I would like to do the same for monitoring and to only load the monitoring backend only if really needed (e.g. when running online). Any chance stuff like the influxdb backend and company can be moved to a separate library which is not linked by the main one? Same for consul and the configuation backend.

Hi, yes I could it, but, unless I'm missing something, this will also affect other software using these libraries directly (Readout, QC, DD, ...).
Could you also clarify which issue you're addressing by doing this?

We have an issue where too many libraries are being loaded from CVMFS when doing the asynchronous reconstruction. This is in particular true on the grid, where we cannot do anything in the short term but cleanup our dependency tree. Monitoring (and Configuration) are currently responsible for bringing in everywhere curl, ApMon, ppconsul (and probably related stuff like some boost library and ssl).

Okay, understood, adding @vascobarroso

Just for reference:

• Monitoring has only 1 required dependency => boost, the rest can be removed from alidist (is ApMon still required on Grid?)
• Configuration indeed depends on ppconsul, curl and boost, but is it still used in DPL? In final system AliECS was supposed to push all the values, and Configuration library should not be needed anymore

@costing can we remove ApMon from Monitoring? Do we use it for anything?
@awegrzyn:

• are you sure Monitoring does not depend on curl? Keep in mind that we aim to have the same distribution between what we run on the grid and what we run during data taking.
• For configuration we use the "command-line" backend... I could of course move it on our side if you do not use it and you do not plan to push anything via Configuration anymore.

@Barthelemy is this also the case for QC? Do you use the Configuration package at all?

are you sure Monitoring does not depend on curl? Keep in mind that we aim to have the same distribution between what we run on the grid and what we run during data taking.

Yes that's fair. I don't know how Monitoring is used on the Grid though... which backend is used, if any?
curl is optional, and it is used for InfluxDB v2 HTTP backend (and should not be used in production as it has pretty large overhead). On FLPs and EPNs monitoring values are pushed to Unix socket (boost only).

It uses my internal DPLWebSocket backend, which does not have any extra dependency. Indeed I guess we can simply drop both the influxdb / curl and ApMon stuff. @costing would that be ok for you?

@davidrohr do we use the influxdb backend on the EPNs?

you mean for monitoring?
We have

--monitoring-backend influxdb-unix:///tmp/telegraf.sock

Ok, so I guess for monitoring we can easily drop only ApMon. @costing could you confirm you do not receive any metrics from the workflows which are using it and that you do not foresee that to happen?

All tests pass. Also tested on the staging with ITS and minimal workflow. InfoLogger messages are still there.

Ciao @ktf , as far as I know the payloads don't send data via ApMon so yes, it can be disabled.

Ok.. alisw/alidist#4585 then.

@ktf It seems curl can be removed as well.

Regarding Configuration, do you know if there's anyone using Configuration service? QC is not. Maybe it could be removed already?

@awegrzyn isn't curl used by the influxdb backend?

Regarding configuration, I am only using the command-line and the file based backends. Maybe we could start by dropping consul support? How is readout configured?

@awegrzyn isn't curl used by the influxdb backend?

There are 6 InfluxDB backends, the only difference is transport they use. Only one (influxdbv2) uses curl and I don't think it's used in production (as it's not even production ready).

Regarding configuration, I am only using the command-line and the file based backends. Maybe we could start by dropping consul support? How is readout configured?

I need to figure it out, lemme create ticket for that: https://alice.its.cern.ch/jira/browse/OCONF-716