chore(k8s): use upstream agent-sandbox manifests, install extensions#1657
chore(k8s): use upstream agent-sandbox manifests, install extensions#1657rmalani-nv wants to merge 1 commit into
Conversation
rmalani-nv
requested review from
a team,
derekwaynecarr,
maxamillion and
mrunalp
as code owners
TaylorMutch
left a comment
TaylorMutch
left a comment
There was a problem hiding this comment.
I would actually like to get away from vendoring the upstream manifests in our repo, since they change quickly and trying to keep up with vendoring is just going to create noise in the repo. Instead we should just use the upstream manifests in our CI / e2e.
Additionally I don't yet see a need for us to pin to a specific version in our public facing docs or in the readme. As we don't yet have a matrix for support (as far as I am aware we aren't seeing any incompatibilities yet, but we can be on the lookout for it; see #1649 for context as well), I'd prefer we not pin in the docs.
…xtensions Drop the vendored deploy/kube/manifests/agent-sandbox.yaml. CI and e2e scripts now apply manifest.yaml + extensions.yaml directly from github.com/kubernetes-sigs/agent-sandbox releases, pinned via AGENT_SANDBOX_VERSION env (default v0.4.6, overridable) so internal runs stay reproducible. Public docs and the helm chart README continue to reference /releases/latest/download/ — no OpenShell/agent-sandbox support matrix exists yet (see NVIDIA#1649). Adds an air-gap note in docs/kubernetes/setup.mdx enumerating the manifests and images operators need to mirror to an internal registry. Signed-off-by: Roshni Malani <rmalani@nvidia.com>
rmalani-nv
force-pushed
the
rmalani-nv/bump-chart-v0.4.6-extensions
branch
from
9499bc6 to
7f246ec
Compare
| local base="https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${AGENT_SANDBOX_VERSION}" | ||
| echo "Applying agent-sandbox manifests (${AGENT_SANDBOX_VERSION})..." | ||
| kubectl --kubeconfig="${KUBECONFIG_TARGET}" apply -f "${base}/manifest.yaml" | ||
| kubectl --kubeconfig="${KUBECONFIG_TARGET}" apply -f "${base}/extensions.yaml" |
There was a problem hiding this comment.
Why are extensions needed? We aren't currently using them in OpenShell.
There was a problem hiding this comment.
Currently not used, but I'd like to use them in upcoming changes.
There was a problem hiding this comment.
If they're not currently used or needed then we should add them with the related feature that utilizes them. Otherwise it just bloats the codebase and adds complexity when not required.
|
Pivoted as requested:
|
rmalani-nv
changed the title
2 participants
Summary
Use upstream agent-sandbox manifests directly in CI/e2e instead of vendoring them, and install the extension CRDs (
SandboxClaim,SandboxTemplate,SandboxWarmPool) so future work like warm-pooling drops in without additional cluster onboarding.Related Issue
Context: #1649 (no support matrix yet — kept docs/README on
/releases/latest/download/for that reason).Changes
deploy/kube/manifests/agent-sandbox.yaml.e2e/with-kube-gateway.shandtasks/scripts/helm-k3s-local.shnow applymanifest.yaml+extensions.yamlfromgithub.com/kubernetes-sigs/agent-sandboxreleases, pinned viaAGENT_SANDBOX_VERSIONenv (defaultv0.4.6, overridable).docs/kubernetes/setup.mdx, helm chart README,README.md.gotmpl) withkubectl applyfor both manifests using/releases/latest/download/.docs/kubernetes/setup.mdxenumerating manifests + images operators need to mirror.Testing
mise run pre-commit/mise run cipass locally. Pre-existingpython:typecheckfailures inpython/openshell/sandbox.py(from feat(python-sdk): support OIDC Bearer auth on SandboxClient #1621) are unrelated to this branch.Checklist