sudomateo

Change "something" to "a computer" and you got it!

It's a big ass computer (technically many computers in a rack) that gives you a cloud provider style API to manage on-premises infrastructure. Plug it in, connect to the web console or API, and provision yourself some sweet sweet virtual machines, disks, and VPCs.

Username checks out.

Define "cooler" please.

I said some of this elsewhere, but the operating system is an implementation detail since we're not selling you bare-metal compute--we're selling you on-premises cloud computing. I think you were looking at this from hardware plus operating system rather than hardware plus a cloud computing control plane.

I get what you're saying though, and you're right that certain workloads like Kubernetes on the metal that can take advantage of hardware wouldn't be a good fit for Oxide today. We could decide to change that in the future, but I don't see that as a priority for Oxide given all else we have to build first.

Theoretically, yes. Practically, highly unlikely.

Switching to Linux and KVM would gain the ecosystem benefits but Oxide would lose control of the host OS which can impact our security stance. Better to tightly integrate at this layer and expose the primitives that are needed. It's not impossible, but we're already maintaining the existing Helios host OS. Adding another wouldn't be beneficial.

Thank you so much! There are certainly a plethora of options for Kubernetes cluster management. We see Cluster API as a vendor-agnostic way for us and our customers. Perhaps one day we'll more tightly integrate Kubernetes and the Oxide control plane, but gotta start somewhere.

You're completely skipping the management of the bare-metal hardware itself. Sure, you can buy a stack of whatever commodity hardware you want and run Kubernetes on bare-metal. What about updating the firmware on that hardware? What about expanding and the hardware you purchases is longer available? Now you have more disparate hardware that may not even be compatible with the software you're running. Those problems exist at scale and is what Oxide is tackling. It's more than just buying a computer and set it and forget it.

It's a rack-sale computer that uses hardware and software co-design to achieve things a stack of disparate 1U servers and network switches can't. You plug in power. You connect it to your network. You get a cloud provider like control plane API and web console to provision VMs, disks, and VPCs. That's it papa.

The host OS is an implementation detail since you, the customer, aren't running workloads directly on the host OS. The VMs running on Oxide run on our host OS, much like other cloud providers.

That rack-scale hardware and software co-design allows Oxide to provide higher CPU and memory density in the same footprint at lower power than competitors. That's super helpful for companies operating at scale where data center power matters. The co-design allows us tackle security problems by eliminating the BIOS, providing attestation from the firmware up to the guest VM, and actually updating the firmware that's on Oxide rather than letting it rot like most customers do today.

This is why when people ask which verticals Oxide targets we kinda say "all of them" because different customers benefit from different Oxide features, but all customers need the core VM, disk, VPC abstraction. Some customers come to us because they don't have an API to manage their on-premises compute and Oxide solves that. Others come to us because they need absolute confidence that there's no malicious firmware running in their compute stack. Others come to us because they are tired of paying exorbitant amounts of recurring money just to run on-premises compute.

Our job is to make Oxide an appealing on-premises computing platform for customers to run their public cloud provider workloads and on-premises workloads without it feeling like it's an entirely different platform than you're used to.

I run this on a TuringPi board at home. I wouldn't get the TuringPi again but Talos for home use has been great. The only issue for me is I have access to Oxide so I moved most of my home lab there.

Could be whichever. Customers have expressed a desired for Longhorn given they were already using it so we started our testing there. Ultimately our CSI plugin will be the official Oxide path.

Reported internally. Thank you!

I cover this a bit in the post. Today they are running something like Longhorn backed by Oxide storage. When we release our CSI plugin they can use that instead.

You can run the control plane at home. I have a video on how to do it. Until we make a smaller footprint that's the only way you'd get Oxide at home.

> So you’d be attaching a new volume to the running worker VM for each PVC?

That's what we prototyped before local disk was released and before we started disk hot-plug work.

> Could you attach a single large volume, and do path-based provisioning on that?

Possibly. We'd still want disk hot-plug first. Otherwise, customers would have to create their cluster in a certain shape before using PVCs.