Backfilling the Maxwell HPC User demands on resources the Maxwell HPC cluster correlates with the data taking of the EuXFEL and photon experiments on site. During low demand, we backfill sections of the cluster with opportunistic grid jobs through a dedicated ARC CE. As demand can change quickly and for data taking responsiveness is crucial, evacuation time has to be in the order of seconds. Authentification As users require long-running jobs over several days and rely on their AFS-HOME directories as well as scratch and long-term storage mounted over NFSv4, token handling is crucial. We implemented a token renewal service to allow for such long-running jobs to access the mounted network home directories over their whole lifetime. Chaining Storage and High-Throughput Computing to each other Event-driven Automatised Workflows and FaaS-Offloading Consolidating the interactive analysis and Grid infrastructure at DESY. Classic workflow engines rely primarily on “polling” the different states in their connected systems such as storage instances and compute clusters. In contrast event based workflows allow for a “push” approach, where different actions can be combined, chained and forked to powerful workflows. To integrate various systems into such a workflow engine, a common message bus for exchanging events as well as a function registry for acting on events is needed. With dCache Storage Events as prime example [4], we are working on combining our storage instances and offline computing resources into one workflow environment, e.g., to allow new files to automatically initiate their own processing as for calibration tasks. Here, a dCache instance creates for each file change a Storage Event and relays it over the Kafka bus. To react on matching events and initiated further actions, functions are registered in a dynamically scalable OpenWhisk Function-As-A-Service platform. However, FaaS lambdas are intended as primarily low-latency, fast processing programs with a standardised API, we are working on offloading the actual heavy processing tasks via functioninalised remote submission to our HTCondor batch system. Combined with anonymous jobs, this allows for dynamically scaling out to computing resources. Anonymous Jobs with Authorization Tokens While classical jobs run under a user ID and read files belonging to such an user ID, this requires a common global identify namespace over all involved resources. Moving from authentication to an authorisation based resource control will allow to be more secure and especially flexible with function workflows. In a token-based scheme, only a central token generator and authentication instance is be needed. Here, a lambda token generator is the only compute instance matching an identity to resources. On a matching event, it request on behalf of the ID authorisation tokens from the storage and compute elements. The tokens can be strictly limited to the needs of the actual processing event, e.g., requesting from a dCache instance read-only Macaroon tokens [4] for input files and limit write abilities to a confined output path. Similarly a submit token to the HTCondor batch system might be requested and added to the compute event. The aim is for a self-sufficient event, that includes as tokens all necessary file inputs and outputs as well as compute resources. Followingly, a compute job based on such a self-sufficient event could run locally under an anonymous user and stage files in/out by its Macaroons. Such an anonymous job could also be scaled out to other compute resources, as it is decoupled from the inital ID namespace. Anonymous Job File I/O Macaroon LRMS Token predef. Fcn/Job f(x) LRMS Storage Storage { "read": { "path": "/pnfs/.../myinfile.root", "macaroon": "MDAx...97MK", "endpoint": "https://dcache-door.in:2880" }, "write": { "path": "/pnfs/.../output.d", "macaroon": "MDAx...5JCg", "endpoint": "https://dcache-door.out:2880" } "exec": { "function": "my_fcn_ns.my_reprocessing_fcn" },