- Discussion of the categories of users and tasks we need to support
- Staff - who also have lsst-dev logins. Supported by lsst-lspdev.
- Users of formal PDAC user evaluations - external science users who are brought in specifically for these periodically scheduled activities. Supported by PDAC (migrating its endpoints to lsst-pdac).
- Workshop/demo/Stack Club users - a category that was not previously foreseen and leads to a more or less continuous series of efforts of this nature. Previously supported by GKE pop-ups. Cannot be supported by PDAC because of the expectation of extended periods of instability/experimentation in PDAC.
Do we need a new LSP instance at NCSA to support this third category? Do we need this concept in the authorization database as well? E.g., is the concept of the "jhome-only user" group one that encompasses all types of non-staff users, or do we distinguish authorization of "demo" users from "PDAC" users? Homework for Unknown User (mbutler) and Wil to think this through further, perhaps.
- Reminder of the intent for PDAC: a "tick-tock" alternating between extended periods in which it's torn apart and used to further integration, test out deployment tooling, experiment with changes to inter-Aspect connections, etc., and periods of stability for formal internal and external testing.
- Discussion of the need for a platform for testing of OS changes, changes to underlying Kubernetes versions, changes to the Kubernetes networking overlay.
- Tentative conclusion: the latter need does not have to be satisfied by a full, separate cluster, i.e., the Integration Cluster does not have to be physically distinct from the development environment / Kubernetes Commons.
- The desire, then, is to move the PDAC hardware into the same Kubernetes control plane as the Commons, but with distinctive "node colors" for the Qserv hardware (because of the static datasets on those machines, and the special hardware on the czar) and for the Firefly servers (which have a lot of memory). How soon can this be done?
- NCSA: Not imminently. It should be queued after the completion of a currently planned redeployment of the Commons itself, motivated in large part by a lessons-learned-based reconfiguration of the physical networking backdrop for the nodes. Could possibly begin moving Qserv by late August.
(notes are not finished, will get back to them tonight)