What do extensions need to support?

[chrisburr]

From the BiLDx meeting.

TODO: Add more description.

[marianne013]

GridPP has always used its extension to simplify mapping by platform i.e. collapse everything into 'EL6', EL7' etc and using this as a the platform. Admittedly we haven't check lately if the vanilla DIRAC code is by now similar enough that we could stop having our own extension.

[marianne013]

We don't seem to be using any other Services in our extension, though we seem to have our own module to talk to voms servers to extract the users. This might be a historical artefact, but while it works I am not touching it.

[fstagni]

For the platform, you have done it by replacing the dirac-plarform script? Is your code here https://github.com/gridpp ? or where else?

[sfayer]

No, we patch the values as they go through the Matcher based on a simple lookup table in the CS:
https://github.com/ic-hep/GridPPDIRAC/blob/main/src/GridPPDIRAC/WorkloadManagementSystem/Service/MatcherHandler.py

(We also have an extra Optimizer module which allows us to set a default platform for users that don't specify one, the code for that is also in that repo).

[andresailer]

We have custom services, agents, and a DB, and python API and workflow modules, and the TransformationSystem plugin modules, and scripts/commands.

[hmiyake]

In our extension, we developed several sub systems, having standard Agent, DB, and Service handler.
Our client does not expose dirac command directly but provides own CLI.
In the codes we are widely using vanilla DIRAC's Client, Utilities, APIs and dirac commands.

We profited grately from plugin mechanism...TS, WMS, RSS, and RMS.
In Belle2, we have own AccountingType and Plotter in AccountingSystem...we understand we need to consider migration to other solution (say ES+Grafana), but if AccountingSystem is still supported by DiracX (even if for early version), we can earn some time for migration.
In that sense we want to know which component will be translated and which will be dropped, even as rough sketch.

We also developed various WebApp handlers (e.g. monitoring, dataset viewer) accessing own + vanilla services.

Our production system is independent from vanilla's, but closely depends on TS too. Especially we customized WorkflowTasks and TaskManager to change the behavior slightly.
So I'm interested how TransformationSystem is migrated in DiracX...if such module usage is not so largely different in DiracX, probably it is not so difficult for us to follow the change.

In WMS, we are using customized Optimizers (including our Scout job functionality), DownloadInputData, SiteDirector, and TaskQueueDB, etc.
Some are inherited with python style, or just copied and modified.
Generally the purpose of the customization is to add our functionality or change vanilla DIRAC's behavior.

If necessary we can provide detailed list of our dependency.