Pilot manager handler simplifications

[fstagni]

First part for #8597

BEGINRELEASENOTES

*WMS
CHANGE: Removed several RPCs and DB calls for PilotManager

ENDRELEASENOTES

[aldbr]

ddev: just need to make sure that htcondor does not remove the outputs from the spool once you requested it once.

[iueda]

Checking the BelleDIRAC code following the question at the last Dops+Ddev meeting, we don't have any extension of PilotManagerHandler nor PilotAgentsDB, but I see some RPC calls with RPCClient('WorkloadManagement/PilotManager') such as getGroupedPilotSummary()

[fstagni]

Checking the BelleDIRAC code following the question at the last Dops+Ddev meeting, we don't have any extension of PilotManagerHandler nor PilotAgentsDB, but I see some RPC calls with RPCClient('WorkloadManagement/PilotManager') such as getGroupedPilotSummary()

That has been moved to DB-only call, no need to go through the RPC.

[fstagni]

Some info related to the removal of PilotOutput table and related methods:

Historically, running condor_transfer_data did not affect the job's presence in the queue, so it was possible to invoke it multiple times on the same job and retrieve the same output files each time.
However, this behavior changed recently in the HTCondor 25.x series. A successful condor_transfer_data now causes the job to become eligible to leave the queue shortly afterwards. This change was introduced because many users expected the job to be automatically cleaned up after retrieving the output, rather than having to run condor_rm separately.
So the answer depends on the HTCondor version in use: older versions allow repeated retrievals, while newer versions may remove the job from the queue after a successful transfer, preventing subsequent condor_transfer_data invocations.
Jamie (James Frey) also mentioned that the HTCondor team would be open to adding an option to preserve the old behavior if there is interest in such a use case.

This puts for the moment a halt on the attempt to simply remove the DIRAC functionality.

[fstagni]

Some info related to the removal of PilotOutput table and related methods:

Historically, running condor_transfer_data did not affect the job's presence in the queue, so it was possible to invoke it multiple times on the same job and retrieve the same output files each time.
However, this behavior changed recently in the HTCondor 25.x series. A successful condor_transfer_data now causes the job to become eligible to leave the queue shortly afterwards. This change was introduced because many users expected the job to be automatically cleaned up after retrieving the output, rather than having to run condor_rm separately.
So the answer depends on the HTCondor version in use: older versions allow repeated retrievals, while newer versions may remove the job from the queue after a successful transfer, preventing subsequent condor_transfer_data invocations.
Jamie (James Frey) also mentioned that the HTCondor team would be open to adding an option to preserve the old behavior if there is interest in such a use case.

This puts for the moment a halt on the attempt to simply remove the DIRAC functionality.

Functionality restored.

[iueda]

That has been moved to DB-only call, no need to go through the RPC.

Would it work not only in the system-side use cases, but also in client use cases?

I was expecting a Belle II colleague to ask this question with more details, but I don't see any yet, so I put my comment here after ~3 weeks.

[aldbr]

Would it work not only in the system-side use cases, but also in client use cases?

Were you using getGroupedPilotSummary from a client? Can you provide further details about your use case and you usage please? Right now I think it's not possible anymore, but we can potentially move that to the WebAppHandler if necessary.

[michmx]

Hi @aldbr. Sorry for jumping in late in the discussion. Yes, we provide a diagnostic tool to users to collect information about the operation status, particularly relevant when they have been waiting for jobs to be pulled by a pilot for a long time.

The tool retrieves the Sites by the optimizer from the JDL (determined at optimization), and uses information from the pilot summary to check if pilots have been running in the site(s) at all, like:

        dirac_rpc = RPCClient('WorkloadManagement/PilotManager')
        fromm = datetime.utcnow() - timedelta(days=1)
        to = datetime.utcnow()
        conddict = {'Site': sites, 'FromDate': fromm , 'ToDate': to}
        result = dirac_rpc.getGroupedPilotSummary(conddict,['GridSite'])

This is executed on the client. With the change in this PR, we need to reconsider how to retrieve pilot statistics from the client. If available in the WebAppHandler, we could use it in principle (I think, unless I am missing a detail about authorization).

[fstagni]

Hi @michmx , I added getGroupedPilotSummary in #8730 in the WebAppHandler. For you, this means moving to:

        dirac_rpc = RPCClient('Monitoring/WebApp')
        fromm = datetime.utcnow() - timedelta(days=1)
        to = datetime.utcnow()
        conddict = {'Site': sites, 'FromDate': fromm , 'ToDate': to}
        result = dirac_rpc.getGroupedPilotSummary(conddict,['GridSite'])   

Let me know if this is OK for you.

Cheers,
Federico

[michmx]

Yes, this is a simple change on our side. Thanks a lot!