DevSpace support for deploying helm chart locally

[kensimon]

Description

This makes it simple to deploy ncx-infra-controller-core to a local kubernetes cluster (like with k3s) with machine-a-tron mock hosts, leveraging the existing helm chart.

• Add a bootstrap script, dev/deployment/devspace/bootstrap-prereqs.sh, which sets up prerequisites (cert-manager, postgres, and vault) into an empty kubernetes cluster
• Add a devspace.yaml that can build and deploy carbide-api and machine-a-tron
• Add Dockerfiles for the api and machine-a-tron, which devspace can use to build them from the current tree

Type of Change

• Add - New feature or capability
• Change - Changes in existing functionality
• Fix - Bug fixes
• Remove - Removed features or deprecated functionality
• Internal - Internal changes (refactoring, tests, docs, etc.)

Related Issues (Optional)

Breaking Changes

• This PR contains breaking changes

Testing

• Unit tests added/updated
• Integration tests added/updated
• Manual testing performed
• No testing required (docs, internal refactor, etc.)

Additional Notes

This was mostly done by OpenAI Codex, with 3-4 rounds of redoing it until I liked the result, plus a bunch hand-editing by me afterward. I'm fairly confident I understand everything in this PR, and it seems to work well in local testing (I can spin up carbide-api pretty quickly with machine-a-tron talking to it, and the hosts get to Ready fairly quickly.)

[Matthias247]

So this is a fully new chart? Not the same that is already offered as deployment option?

I think it would be good to just have one - where one would use special options to enable local development. Multiple charts will be confusing for OSS users (which one should I use?).

[github-actions]

🛡️ Vulnerability Scan

🚨 Found 72 vulnerability(ies)
📊 vs main: 72 (no change)

Severity Breakdown:

• 🔴 Critical/High: 72
• 🟡 Medium: 0
• 🔵 Low/Info: 0

🔗 View full details in Security tab

_{🕐 Last updated: 2026-03-18 22:31:09 UTC | Commit: 70bea03}

[github-actions]

🔐 TruffleHog Secret Scan

✅ No secrets or credentials found!

Your code has been scanned for 700+ types of secrets and credentials. All clear! 🎉

🔗 View scan details

_{🕐 Last updated: 2026-03-18 22:31:14 UTC | Commit: 70bea03}

[kensimon]

So this is a fully new chart? Not the same that is already offered as deployment option?

I think it would be good to just have one - where one would use special options to enable local development. Multiple charts will be confusing for OSS users (which one should I use?).

It's reusing the existing chart for carbide-api (that's the main point of this, at least.) There's a separate helm chart for machine-a-tron though, since I wanted to keep it separate from the main chart. I don't think the main chart should be deploying machine-a-tron, since it's only for environments where you want mock hosts. (We can discuss though... we could technically add machine-a-tron to the main chart, but disabled by default and overrideable by values.yaml, but I decided against that for now.)

The two main things this PR is doing is:

• Giving a nice friendly script for bootstrapping the prerequisites into a local k3s cluster (basically cert-manager, postgres, and vault). You only need to run this once.
• Making a devspace.yaml and some more straightforward Dockerfiles for building carbide-api and machine-a-tron, so that you can run devspace deploy any time to deploy your local code. (It takes the place of what skaffold was doing before.) The nice thing here is that devspace is simply using the helm chart to deploy, but overriding the image tags with what is produced from the local build.

[ianderson-nvidia]

Is this only for the api crate? Are we not worrying about DHCP/PXE/DNS/console services?

You will also need to bump the chart version for carbide-api in Chart.yml
As well asChart.yaml in helm root dir.

[kensimon]

Is this only for the api crate? Are we not worrying about DHCP/PXE/DNS/console services?

Not yet, no... I'm mainly just interested in getting development going with mocks right now, and none of those are really needed. I'd be interested to hear opinions on this though... When I think "local development workflow" I don't generally think of running a real DHCP/PXE/etc server (ie. not a real datacenter environment with DPU's.) I just want the simplest way to get an API server running you can test against, and the machine-a-tron bits are just there just to make the default deployment a little more interesting (rather than just being an empty environment with no hosts.)

Can we use the build containers that we have been using?

I'll try and look into re-using the build container tomorrow, but we do need a different Dockerfile for this, for devspace to do its magic. What we don't want to do is what we did with skaffold, where we had a separate step that ran the build container to spit out a binary, and then another build step that built the runtime container from a simple COPY line that grabbed the built binary (That was always IMO a hack, we could have always just done it all in one step.)

Another thing to consider is just blowing away dev/deployment/localdev, since that is all very specific to the skaffold workflow which is now basically broken.

[kensimon]

So this is a fully new chart? Not the same that is already offered as deployment option?

I think it would be good to just have one - where one would use special options to enable local development. Multiple charts will be confusing for OSS users (which one should I use?).

I reworked the PR to have devspace use plain-old kubernetes yaml and kubectl apply for the machine-a-tron portions, so there's no confusion about a "new chart". (It's simpler this way anyway.)

[ianderson-nvidia]

I'll try and look into re-using the build container tomorrow, but we do need a different Dockerfile for this, for devspace to do its magic. What we don't want to do is what we did with skaffold, where we had a separate step that ran the build container to spit out a binary, and then another build step that built the runtime container from a simple COPY line that grabbed the built binary (That was always IMO a hack, we could have always just done it all in one step.)

Another thing to consider is just blowing away dev/deployment/localdev, since that is all very specific to the skaffold workflow which is now basically broken.

I don't think Skaffold is broken. The entire personal dev environment uses the dockerfiles in localdev/ with skaffold. If we want to pivot to devspace, that's fine. But we need a plan to support the current dev environments before we start deleting things.

[wminckler]

I'll try and look into re-using the build container tomorrow, but we do need a different Dockerfile for this, for devspace to do its magic. What we don't want to do is what we did with skaffold, where we had a separate step that ran the build container to spit out a binary, and then another build step that built the runtime container from a simple COPY line that grabbed the built binary (That was always IMO a hack, we could have always just done it all in one step.)
Another thing to consider is just blowing away dev/deployment/localdev, since that is all very specific to the skaffold workflow which is now basically broken.

I don't think Skaffold is broken. The entire personal dev environment uses the dockerfiles in localdev/ with skaffold. If we want to pivot to devspace, that's fine. But we need a plan to support the current dev environments before we start deleting things.

Please don't delete the old stuff yet...