[9.0] feat: Add diracx secrets in SiteDirector

[Robin-Van-de-Merghel]

BEGINRELEASENOTES

*SiteDirector
CHANGE: Connect SiteDirector to DiracX to use secrets.

ENDRELEASENOTES

[Robin-Van-de-Merghel]

Rebased on #8233

[aldbr]

I agree this is not intuitive, and this was done before we introduced typing, but I think list[str] is the "default" case

[Robin-Van-de-Merghel]

It can't be list[str] the default. In fact, if it is, it will instantly crash. In pseudo code:

if its_a_str:
  # Add in db as if it was 1 stamp

if its_an_int:
  # Transform to a list

# Add in db as if it was multiple IDs

If we have a list[str], the code will go in the last case and try to insert stamps as IDs.

[Robin-Van-de-Merghel]

See if we need also \"

[Robin-Van-de-Merghel]

To be removed

[Robin-Van-de-Merghel]

If someone has an idea.

[aldbr]

The more I think about it, the more I wonder whether it makes sense to go that far at the moment: may be we shouldn't try to adapt the DIRAC agents and should stop to the legacy adaptor within DIRAC.

Why?

• Because then we need to define how DIRAC will interact with DiracX: should it be a user defined in the config? Should it get a special token?
• Then we also need to adapt DiracX for this temporary use case.

It's not super clear, but IIUC, in the roadmap we state that the Pilot Submission should be implemented once the Tasks and the Pilot authentication will be available: https://github.com/DIRACGrid/diracx/blob/main/docs/roadmap.md#current-status

A DiracX Site Director would be able to contact diracx-logic directly, without passing by the routers, which would be much easier to manage I think.

Any opinion?

[fstagni]

I tend to agree with you.

[Robin-Van-de-Merghel]

Discussed above: won't be done. It will be done in DiracX directly.