Add EUROfusion access onboarding docs - #62
Conversation
Document how ITPcp members obtain and verify EUROfusion DevOps/Gateway access (request route via group lead, SSH key reuse, access verification) and link it from the README Getting Started section. Closes #18
|
Review verdict: Request changes Summary: Documentation-only change, but it does not satisfy the issue’s acceptance criteria because the core access instructions still contain unresolved host placeholders. Findings:
Verdict: Request changes — the primary onboarding workflow is incomplete; no CI checks are configured for this commit. |
Replace the unresolved <gateway-host> and <eufus-gitlab-host> placeholders with the exact verified endpoints (EFGW Gateway at login.eufus.eu and the CINECA-hosted EUROfusion DevOps GitLab SSH endpoint gitlab-ssh.hpc.cineca.it) and document the authoritative UserDB account grant route, so new members can follow and verify the onboarding steps.
|
Review verdict: Request changes Summary: The documentation is clear and the Gateway details match the referenced issue and official CINECA guidance. CI was still running; no code or test changes are affected. Findings:
Verdict: Request changes — the onboarding flow is incomplete without the DevOps GitLab web destination. |
…tion New members could not follow the membership-verification step because the doc only named the SSH host gitlab-ssh.hpc.cineca.it with no web destination. Add the exact CINECA-hosted web UI (https://gitlab.hpc.cineca.it/) and the EUROfusion group URL (https://gitlab.hpc.cineca.it/groups/eurofusion) under which the ITPcp group/project membership is confirmed, in both the What-you-need bullet and the verification step 3.
|
Review verdict: Request changes Summary: Documentation-only change; the README link is appropriate, but the onboarding instructions contain an invalid UserDB hostname and omit the mandatory EFGW SSH-certificate/2FA setup. CI is still pending. Findings:
Verdict: Request changes — new users cannot reliably follow the documented access procedure. |
krystophny
left a comment
There was a problem hiding this comment.
Review verdict: Comment
Summary: Documentation-only PR; the Gateway details match current CINECA documentation, but the access-status wording is inconsistent with issue #18, and CI is still running at NEO-2.
Findings:
- [minor] docs/eurofusion-access.md:19-21 — Says Chris, Winny, Sergei, and Max are current members “with access,” while issue #18 marks only Chris complete and explicitly says the others are unknown/untested. This can falsely indicate that access is already verified; describe them only as tracked members or update the issue with evidence.
- [minor] docs/eurofusion-access.md:48-53 — Recommends reusing the blank-passphrase
id_rsakey. This inherits and reinforces insecure guidance from README; recommend a protected, dedicated key instead, or clearly document the security trade-off.
Verdict: Comment — the main documentation issues should be corrected, and CI completion is not yet available.
Problem
Issue #18 tracks adding ITPcp members (Chris, Winny, Sergei, Max) to the
EUROfusion DevOps/Gateway infrastructure. There was nothing in the
repository documenting how EUROfusion access is obtained or verified, so
new members had no idea how to request an account and the checklist was
unverifiable from the repo.
Change
docs/eurofusion-access.mddocumenting the EUROfusion DevOps /Gateway access request route (via the group lead, not self-service),
SSH key reuse, and the concrete commands each member should run to
verify their account and — more importantly — their ITPcp group/project
membership on the DevOps GitLab.
## Getting Startedsection, right after theexisting SSH-key setup paragraph.
The exact Gateway/DevOps GitLab hosts intentionally come from the
account-grant mail rather than being guessed, so the doc cannot point
members at a wrong host; it instructs them to use the granted host.
Tests
Documentation-only change; no build or pytest surface is affected.
pytest tests/is untouched.Closes #18