Earlier quoted context omitted.
OMG, you just made my day!
does this mean that you won't be killing anyone?
They might still be available for killing someone out of gratitude
Kubernetes on Oxide: How customer needs shaped our integrations
51–60 of 70 posts
Re: Kubernetes on Oxide: How customer needs shaped our integrations
#52Earlier quoted context omitted.
Every single Oxide article has comments about people wanting one at home. A great example of completely misdirected marketing and/or engineering. Oxide should have developed home microcomputers, and they would have sold like cupcakes, with their ASCII art marketing. Instead they do million dollar "mainframes" that no one (except VCs) wants to buy.
(I think you meant "like hotcakes", not "like cupcakes"?) In any event: from the beginning, we have always been targeted at the enterprise buyer who is looking at annual public cloud bills in the tens, hundreds or (in some cases) thousands of millions of dollars per year. We love the enthusiasm that Oxide engenders among the home lab set, but that's not how we have geared the business (for lots of good reasons). Also…
[dead]
Re: Kubernetes on Oxide: How customer needs shaped our integrations
#53Re: Kubernetes on Oxide: How customer needs shaped our integrations
#54I have seldom wanted anything as much as I want an Oxide rack at home. Maybe in 40 years we'll start to see the first ones show up in surplus auctions...
Every single Oxide article has comments about people wanting one at home. A great example of completely misdirected marketing and/or engineering. Oxide should have developed home microcomputers, and they would have sold like cupcakes, with their ASCII art marketing. Instead they do million dollar "mainframes" that no one (except VCs) wants to buy.
Homelab tinkerers are essentially a non-market. They barely want to pay for the cheapest commodity hardware. Tens of individuals would buy Oxide racks or theoretical microcomputers with their own money.
Re: Kubernetes on Oxide: How customer needs shaped our integrations
#55Love to see the CAPOx provider and buy in to Cluster API
Yeah me too, unfortunately I cant justify huge 100K USD servers so ill continue with cluster api provider hetzner and metal3. The whole CAPI ecosystem is quite cool.
Re: Kubernetes on Oxide: How customer needs shaped our integrations
#56I think it'd be cooler if you could just run kubernetes directly on their bare metal hardware without their hypervisor in between
Re: Kubernetes on Oxide: How customer needs shaped our integrations
#57Earlier quoted context omitted.
Why Mayastor and not (Rook-)Ceph?
Slow, buggy and resource hungry. Faster spdk-based engine rewrite has been on the way for like 7 years now
One cool feature of ceph is reed solomon erasure coding, myastor only does replication if storage efficiency is important
4+2 Erasure Coding has only half the storage overhead of 3x replication but the same fault tolerance
Also re spdk
https://muratkarslioglu.com/blog/io-uring-spdk-kernel-bypass...
Re: Kubernetes on Oxide: How customer needs shaped our integrations
#58I have seldom wanted anything as much as I want an Oxide rack at home. Maybe in 40 years we'll start to see the first ones show up in surplus auctions...
fwiw, I am very satisfied with talos and k8s at home.
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.
Re: Kubernetes on Oxide: How customer needs shaped our integrations
#59Earlier quoted context omitted.
My point was that the major cloud CCMs are rooted (at least spiritually) in in-tree implementations. With Oxide having an API first strategy (similar in principle to a major cloud provider) the direction you take on your greenfield CCM could be interesting. RE Karpenter, it always seemed like a natural fit for Oxide, even more so than some of the currently implementors. And now you have the expertise in the team, I'd…
Karpenter is definitely a natural fit for Oxide. There's some interesting boundaries that we're discussing internally, like @sudomateo mentioned. One of which is CAPI. There's a CAPI Karpenter provider that elmiko built (notably back in the very early days of Karpenter). I think there's room for both use-cases. Some may want to use CAPI for everything and others may want a platform that is based on CAPI but guest clu…
I'd assumed @sudomateo was talking about you when he said his colleague had built a prototype.
Re: Kubernetes on Oxide: How customer needs shaped our integrations
#60Earlier quoted context omitted.
Slow, buggy and resource hungry. Faster spdk-based engine rewrite has been on the way for like 7 years now
One cool feature of ceph is reed solomon erasure coding, myastor only does replication if storage efficiency is important 4+2 Erasure Coding has only half the storage overhead of 3x replication but the same fault tolerance Also re spdk https://muratkarslioglu.com/blog/io-uring-spdk-kernel-bypass...
RS and XOR EC are definitely useful features for an object store that's storing from like tens of petabytes to exabytes worth of data but for a remote block device with a typical size up to a couple dozen terabytes I'm not so sure. Thanks for the link I will check it out
Edit: skimmed it, classic AI "analysis" - totally ignores all the crap io_uring went through