Add a csi volume source to VolumeV1 (Aspire.Hosting.Kubernetes)

[Tim Ritzer (timritzer)]

Description

VolumeV1 modeled every v1.Volume source except csi. The Kubernetes csi source is how inline ephemeral CSI volumes are expressed, including how the Secrets Store CSI driver projects secrets and certificates into a pod. Because VolumeV1 and PodSpecV1 are sealed and the chart serializer is inaccessible, this shape could not be expressed from outside the package.

This adds a CsiVolumeSourceV1 type (driver, readOnly, fsType, volumeAttributes, nodePublishSecretRef) and a csi property on VolumeV1, mirroring the Kubernetes API object. The public API baseline is updated and publisher tests cover the rendered csi block and its omission when unset.

Fixes #19816

API review status: This adds public API that implements the proposal in #19816. That proposal is currently open and has not yet been API-reviewed or approved (no api-approved label, no API-review sign-off). This PR should not merge until the API review is held and the proposal is approved. The checklist below reflects that honestly.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19826

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 19826"

[Copilot]

Pull request overview

Adds Kubernetes inline CSI volume modeling and serialization.

Changes:

• Adds CsiVolumeSourceV1 and VolumeV1.Csi.
• Adds publisher tests and YAML snapshots.
• Updates the public API baseline.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
CsiVolumeSourceV1.cs	Defines CSI volume fields.
VolumeV1.cs	Adds the CSI source property.
Aspire.Hosting.Kubernetes.cs	Updates the API baseline.
KubernetesPublisherTests.cs	Tests CSI serialization and omission.
PublishAsync_SupportsCsiVolumes.verified.yaml	Verifies rendered CSI YAML.
PublishAsync_OmitsCsiVolumeSourceWhenUnset.verified.yaml	Verifies omission when unset.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

src/Aspire.Hosting.Kubernetes/api/Aspire.Hosting.Kubernetes.cs:721

• This generated API baseline should not be updated in a feature PR. src/Directory.Build.targets:4-5 identifies these files as generated, AGENTS.md:34 explicitly prohibits editing them, and .github/workflows/generate-api-diffs.yml:38-47 updates them separately for release review. Remove this generated class entry; the source type remains the implementation of the new API.

This issue also appears on line 2949 of the same file.

    [YamlDotNet.Serialization.YamlSerializable]
    public sealed partial class CsiVolumeSourceV1

src/Aspire.Hosting.Kubernetes/api/Aspire.Hosting.Kubernetes.cs:2950

• This is the second manual change to the generated API baseline. API files are generated by the release-review workflow rather than updated alongside feature implementation (AGENTS.md:34; .github/workflows/generate-api-diffs.yml:38-47), so remove this entry and let the dedicated API-surface process produce it.

        [YamlDotNet.Serialization.YamlMember(Alias = "csi")]
        public CsiVolumeSourceV1? Csi { get { throw null; } set { } }

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Tim Ritzer (timritzer)]

Dogfooded this against a real Secrets Store CSI driver setup — model path produces byte-identical output to a production-proven emitter

I validated this PR end-to-end by consuming the CI-built PR package (13.6.0-pr.19826.g61233bfe) in a real Aspire consumer that projects Key Vault certificates into pods via the Secrets Store CSI driver.

That consumer previously had no way to express a csi: volume through the public model (VolumeV1/PodSpecV1 are sealed and the chart serializer isn''t reachable from another assembly), so it carried a stopgap that post-processed the generated deployment.yaml to splice the volumes in. I replaced that stopgap with the new model path:

podSpec.Volumes.Add(new VolumeV1
{
    Name = name,
    Csi = new CsiVolumeSourceV1
    {
        Driver = "secrets-store.csi.k8s.io",
        ReadOnly = true,
        VolumeAttributes = { ["secretProviderClass"] = spcName },
    },
});

Regenerating the deployment artifacts, the emitted YAML was byte-for-byte identical to the previously production-proven output:

volumes:
  - name: "secrets-store"
    csi:
      driver: "secrets-store.csi.k8s.io"
      readOnly: true
      volumeAttributes:
        secretProviderClass: "<spc-name>"

driver, readOnly, and volumeAttributes all serialize exactly as the CSI driver expects (matching its own e2e manifests). The model path is a clean drop-in for a hand-rolled emitter. 👍

[Mitch Denny (mitchdenny)]

Thanks for the contribution Tim Ritzer (@timritzer)

[github-actions]

⚠️ CI Failure Analysis: Mixed Failures

The CI build contains both transient and non-transient failures.

Failed jobs:

• Tests / Cli / Cli (windows-latest) — Only TRX failure is ProcessExecutionTests.WaitForExitAsync_WithGracefulServices_SignalerThrows_StillEscalatesToKill, a Windows-only timing/race assertion in Aspire.Cli.Tests unrelated to this PR's Kubernetes hosting changes. (flaky-test)
• Tests / Hosting.Azure / Hosting.Azure (windows-latest) — 'Build test project' step failed with generic exit code 1 and no logs available. PR only touches Aspire.Hosting.Kubernetes files; Hosting.Azure test project has no dependency on those changes. (transient-infra)
• Tests / Hosting.Azure.Kubernetes / Hosting.Azure.Kubernetes (ubuntu-latest) — 'Build test project' step failed with generic exit code 1 and no logs available, occurring simultaneously across multiple unrelated jobs, indicating shared infra failure rather than a code issue. (transient-infra)
• Tests / Hosting.Azure.Kubernetes / Hosting.Azure.Kubernetes (windows-latest) — 'Build test project' step failed with generic exit code 1 and no logs available, part of the same widespread build-project failure pattern seen across unrelated jobs in this run. (transient-infra)
• Tests / Playground / Playground (ubuntu-latest) — 'Build test project' step failed with generic exit code 1 and no logs available. Playground project build is unrelated to Aspire.Hosting.Kubernetes CSI volume changes in the PR. (transient-infra)
• Tests / Hosting.Azure / Hosting.Azure (ubuntu-latest) — 'Build test project' step failed with generic exit code 1 and no logs available, consistent with the widespread build failure across unrelated jobs. (transient-infra)

The CI will not be automatically rerun. Please review the failures above.