Repository navigation
Conversation
Document what the registry admins check before they verify a service and which services use the verified entries, Funnel with OpenPBS, the storage and token support of Poiesis, and point the proTES note to the issue that tracks its configuration. Part of #81. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Reviewer's GuideDocumentationDocument Funnel's OpenPBS deployment requirements and limitations, and list OpenPBS as a supported backend.
Explain what admins check before verifying Cloud Registry entries and who uses the verified entries.
Document Poiesis's storage and token requirements, and point to the issue tracking which Nodes run it.
Point the outstanding proTES deployment details to the issue tracking its configuration.
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Documentation build overview
5 files changed ·
|
There was a problem hiding this comment.
Hey - I've found 5 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="docs/operators/using-cloud-registry.md" line_range="93-94" />
<code_context>
+- **The service is live:** it answers at its URL, and its service info is
+ public, with sync on (see above).
+- **The service isn't open to anyone:** it accepts requests only from the
+ users that the policy of the federation allows, e.g., for a TES service,
+ members of the LS Login group `ECP_CLN` (see [Enable LS Login and ECP_CLN
+ access](node-onboarding-tutorial.md#3-enable-ls-login-and-ecp_cln-access)),
+ and from the gateway.
</code_context>
<issue_to_address>
**Access checks are overstated**
When an operator evaluates a Poiesis or Funnel endpoint without an external membership gate, poiesis and Funnel accept any valid token from their configured issuer rather than checking `ECP_CLN`, while the checklist says the service accepts only federation-approved users. Operators and users can mistake verification for proof of membership enforcement.
Clarify that Poiesis and Funnel need an external membership gate to meet this check, or enforce the federation membership policy in the service.
</issue_to_address>
### Comment 2
<location path="docs/operators/services/funnel.md" line_range="23" />
<code_context>
+- The ELIXIR On-Cloud documents Funnel with Slurm and with OpenPBS (below).
+ For other backends, such as HTCondor or Grid Engine, see the Funnel docs.
+- Place the `funnel` binary on a server that can submit jobs to the
+ cluster: a login or submission node of Slurm or PBS.
+- Put the config file on the same server. For Slurm, [this
+ file][funnel-config-slurm] is a starting point.
</code_context>
<issue_to_address>
**PBS tasks cannot start**
When the compute hosts cannot access the Funnel binary or config file at the paths used by the job, `funnel worker run` executes on a compute host, where the binary or `/etc/funnel/funnel-config.yml` is unavailable, so the worker exits before running the task.
Ensure the binary and config file are available to compute hosts at the paths used in the job script, or update the script to use accessible paths.
Also at `docs/operators/services/funnel.md:53`, `docs/operators/services/funnel.md:71`.
</issue_to_address>
### Comment 3
<location path="docs/operators/services/funnel.md" line_range="51" />
<code_context>
+ #PBS -N {{.TaskId}}
+ #PBS -o {{.WorkDir}}/funnel-stdout
+ #PBS -e {{.WorkDir}}/funnel-stderr
+ #PBS -l select=1:ncpus={{if ne .Cpus 0}}{{.Cpus}}{{else}}1{{end}}{{if ne .RamGb 0.0}}{{printf ":mem=%.0fgb" .RamGb}}{{end}}
+
+ funnel worker run --config /etc/funnel/funnel-config.yml --taskID {{.TaskId}}
</code_context>
<issue_to_address>
**PBS jobs get too little memory**
When a task requests fractional `RamGb` that `printf "%.0f"` rounds down, the `.RamGb` formatting expression rounds down to a whole GB (and requests below 0.5 GB become `0gb`), so PBS allocates less memory than requested and the task is under-provisioned and subject to termination for exceeding its limit.
Round requested memory up to a whole GB or format it using a PBS-supported fractional unit so the allocation is never below `.RamGb`.
</issue_to_address>
### Comment 4
<location path="docs/operators/services/funnel.md" line_range="49-50" />
<code_context>
+ ```text
+ #!/bin/bash
+ #PBS -N {{.TaskId}}
+ #PBS -o {{.WorkDir}}/funnel-stdout
+ #PBS -e {{.WorkDir}}/funnel-stderr
+ #PBS -l select=1:ncpus={{if ne .Cpus 0}}{{.Cpus}}{{else}}1{{end}}{{if ne .RamGb 0.0}}{{printf ":mem=%.0fgb" .RamGb}}{{end}}
+
</code_context>
<issue_to_address>
**PBS workers cannot access task files**
When the Funnel server's work directory is on storage not mounted on PBS execution hosts, the PBS job uses Funnel's `WorkDir` for its output paths and worker task data. When that directory is local to the submission host rather than shared with execution hosts, the worker cannot access the task files and the job fails.
Explicitly require Funnel's work directory and PBS output paths to use storage accessible from the execution hosts.
</issue_to_address>
### Comment 5
<location path="docs/operators/services/funnel.md" line_range="51" />
<code_context>
+ #PBS -N {{.TaskId}}
+ #PBS -o {{.WorkDir}}/funnel-stdout
+ #PBS -e {{.WorkDir}}/funnel-stderr
+ #PBS -l select=1:ncpus={{if ne .Cpus 0}}{{.Cpus}}{{else}}1{{end}}{{if ne .RamGb 0.0}}{{printf ":mem=%.0fgb" .RamGb}}{{end}}
+
+ funnel worker run --config /etc/funnel/funnel-config.yml --taskID {{.TaskId}}
</code_context>
<issue_to_address>
**Tasks can run in the wrong zone**
When a TES task specifies a zone, the job template never uses `.Zone`, so PBS submits the task without that constraint and can run it in a different zone.
Apply `.Zone` in the PBS job request, or document that the backend ignores zone requests.
Also at `docs/operators/services/funnel.md:38`.
</issue_to_address>Sourcery assessment
Approval pending. 5 findings to address first.
Blocking findings: docs/operators/using-cloud-registry.md:94, docs/operators/services/funnel.md:23, docs/operators/services/funnel.md:51, docs/operators/services/funnel.md:50, docs/operators/services/funnel.md:51
Use Funnel's Args for the worker config, require a shared work directory and the binary on the execution hosts, say what the PBS template ignores or rounds, and say that a service without its own group check meets the access check only behind the gateway. Part of #81. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Linked issuesChecked at commit 367c9be #142 docs: document service checks, Poiesis and OpenPBS · 5 of 5 met
|
Summary
Fills the gaps of #81 that the repositories and decision records can answer, on the pages outside the files of the data centre tutorial PR (#138):
using-cloud-registry.mdgets "What the admins check" (the owner is known, URL, API type and organization right,https, live with public service info and sync on, not open to anyone; from generic-issues#51 and the existing policies) and "Who uses the verified entries" (proTES when it discovers TES services in a registry; Krini and the CLI don't show the label, as their pages already say; the deployment's proTES configuration is tracked in generic-issues#31).pbsbackend config, a job template adapted to the OpenPBSselectsyntax, and a "Not tested here" warning: Funnel's reconciler parses Torque's XMLqstat -x, which OpenPBS doesn't produce, so it stays off (Funnel's default). Services index lists OpenPBS for Funnel.Not in this PR
Edits to
onboarding.md,node-onboarding-tutorial.mdanddata-centre-onboarding-tutorial.mdwere held back, because they were off limits while #138 was open. #138 is merged now, so a follow-up can do them:onboarding.md: replace the verification note (lines 97-100) with a link to "What the admins check"; replace the vsftpd step "write to the service email for user name and password" (item 3) with: create an account for the tasks with access to their directories only, give its credentials to the TES service (TESK: theftpvalues of its chart), share them with other Nodes' operators only as agreed with the admins, never by email to a list, an issue or a registry entry; add "Slurm, OpenPBS" to the Funnel row and the requirements list; note that Poiesis needs S3.node-onboarding-tutorial.mdstep 6 anddata-centre-onboarding-tutorial.mdstep 5: replace the "checks are not written down" notes with a link to "What the admins check".Still open, needing the maintainers (#81 items 1 and 4, part of 5): the policies for joining (who, what a Node provides, how long verification takes), and the addresses and contents of the deployment's proTES, proWES, CWL-WES, DRS-Filer and TRS-Filer and which Nodes run Poiesis. Those notes stay.
Verification
python scripts/check_names.py: passesmkdocs build --strict: passes, no warningspytest: 25 passed, 100% coverageLight lane: docs only, no logic, CI, secrets or workflows touched; reviewed the diff myself.
Declined review findings
None (light lane, no reviewer subagents).
Open questions
None for this PR. Whether to split #81 (the maintainer-only items into their own issue) is noted for the maintainers separately.
Closes #142 (part of #81)
🤖 Generated with Claude Code
Summary by Sourcery
Complete the Node Operator documentation gaps for service verification, Poiesis, OpenPBS-backed Funnel deployments, and proTES configuration tracking.
New Features:
Enhancements:
Documentation: