Installation
Saptiva AI performs the installation together with the Client's operator. It is declarative: the platform configuration lives in a deployment repository, and an agent in the cluster applies it and keeps it in place; nothing is installed by hand or fixed by hand afterward.
Phases
- Preflight check. The requirements are verified. It ends with a report of what is missing.
- Image mirroring. All images of the agreed version are copied to the Client's registry.
- Base layers. Certificates, service network, storage, GPU queues, and monitoring.
- Platform. Identity, Frida, Studio, InferNode, the agent and workflow runtime, and the lab platform.
- Smoke tests. Sign-in, creation of a Client and a lab, a notebook with GPU, a pipeline, a queued job, and a call to InferNode.
- Handover. Credentials for the first administrator, the Studio URL, and the test report.
What Saptiva AI needs from the operator in each phase
| Phase | From the operator |
|---|---|
| Preflight check | Read access to the cluster (a kubeconfig with read permissions) and to the user network to test DNS. |
| Image mirroring | Write credentials for the internal registry, or the loaded image package if there is no internet. |
| Base layers | Certificates or issuer, and the default storage class. |
| Platform | Base domain, identity provider details if there will be SSO, email of the first administrator. |
| Smoke tests | A person from the Client who validates sign-in and a notebook with GPU. |
| Handover | Acknowledgment of the test report and the backup procedure. |
What the operator receives
- Read access to the deployment repository of their installation.
- A platform status dashboard and the alerts described in Observability.
- The backup procedure and the recovery drill (Upgrade and backup).
Versions
Each component is installed at a pinned version. The installation's versions appear in the deployment repository and in the release notes of this documentation.