Wrote up on confluence (https://confluence.skatelescope.org/pages/viewpage.action?pageId=188653621).
Ported rucio-analysis to gitlab, adjusted CI to package and push helm chart. Got it hooked up to ArgoCD.
RSE integration support (w/ coral).
Discussion w/ blue-lavender about getting AUS storage onboarded. Work on ArgoCD GitOps integration of rucio-analysis.
RSE integration support (w/ coral).
Threads (w/ coral). Coral can now use Rucio to transfer data (but with issues).
Work on ArgoCD GitOps integration of rucio-analysis.
Emails (w/ purple), RSE integration support (w/ coral). General catching up. Coral can now use Rucio to transfer data (altered policy package and fixed sync script).
Problem with Coral's application.yaml. Expenses.
Deployed on dev machine. Runs every 15mins. Sync script is "true" sync in that it will match what the IAM lists; it's not just addititive operations.
Some conversations with Paul. Conclusions follow.
Regarding the issue of not knowing which type (ESCAPE, SKA) of token is being presented to storage, and thus how to map paths per VO, there are two solutions:
Solution: The token obtained from a client_credential grant has the same group membership information as that retrieved from an authorization code flow, e.g. /escape/ska Blocker: INDIGO IAM doesn't currently support wlcg.groups in tokens obtained from a client_credential grant, although the WLCG-AuthZ-WG-JWT profile doesn't forbid this. It is possible that groups could be attached to a client that issues tokens via client_credentials (with group membership presumably defined by its sub claim?).
or
Solution: Use the iss claim to narrow down the VO part of the mapped path. Blocker: The ESCAPE instance of INDIGO IAM uses the same iss claim for all VOs. It doesn't currently support multi-VO.
TODO: still need to refactor to remove references to rucio wrappers (just use the python clients rucio provides). Also need to rename (rucio-task-manager), deploy to new gitlab repo, make the image and push to a container registry there (instead of ska-rucio-prototype) and update the yamls accordingly.
TODO2: Create service user in IAM that can be used for these client_credential operations in Rucio.
Now passes in oidc-agent client as environment variable. This can then be decoded with a password (also a variable). Same for X509 certificates and kube config.
This oidc-agent client includes a refresh token, so if refresh token is set to infinite lifetime (which it is for ska-rucio-auth) we can get access tokens using it indefinitely.
The values.yaml now accepts the task yaml (including any secrets - but need to make these available to the cluster).
Still need to add the sync script as a task, then deploy to dev. Can use minikube to test, but must create secrets, e.g.
$ kubectl create secret generic oidc-agent-auth-client --from-file=cfg=/tmp/ska-rucio-auth --from-literal=password=<redacted>
$ kubectl create secret generic kube --from-file=cfg.dev=/tmp/kube
$ kubectl create secret generic rucio-cfg-client --from-file=certificate=/home/eng/.globus/client.crt --from-file=key=/home/eng/.globus/client.keyand build the image/push:
$ make skao
$ docker tag rucio-analysis:skao registry.gitlab.com/ska-telescope/src/ska-rucio-prototype/ska-rucio-analysis-client
$ docker push registry.gitlab.com/ska-telescope/src/ska-rucio-prototype/ska-rucio-analysis-clientcan then test by creating ad-hoc jobs from this cronjob, e.g.:
$ kubectl create job --from=cronjob/task-sync-iam-rucio --namespace rucio-analysis job1Making notes from live-logs documents. Adding some comments to stories etc.
Working on comments for reaper/poller PRs.