swarmkit VS spec

It's supported, though the development pace is rather slow. The are new features (the latest release brought support for the Container Storage Interface) and bugs and issues are worked on by the few maintainers the project has. You can check the repo here: https://github.com/moby/swarmkit

So the thing is support for Swarm was delegated to Mirantis, https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-develop-docker-swarm/ since it was delegated very little was done to move forward swarm _> https://github.com/moby/swarmkit/commits/master , docker swarm itself (docker the company) is deprecated https://github.com/docker-archive/classicswarm . I think because there's no way to monetize swarm there's no real push for new features hence my assumption of deprecation.

Feature request: Enable "--device" in "stack deploy" for Confidential Computing

This doesn't look that abandoned? https://github.com/moby/swarmkit

Or are you talking about swarm the product (versus docker swarm mode)

I don’t feel a momentum in Docker Swarm development, seeing pull requests like #3072 sitting idle for half a year, originally from 2016.

privileged not being supported is problematic, but there are PRs for it on swarmkit, see https://github.com/moby/swarmkit/pull/3072 - let's see if that gets in.

swarm ha placement

It is already in a different repo: moby/swarmkit

Docker Swarm is dead. It should not be used for new projects because the competitive products are much better and more optimal. Check their repo bro - last commit 3months ago. https://github.com/docker/swarmkit https://www.reddit.com/r/docker/comments/ituysl/why_people_are_saying_docker_swarm_is_in_life/ Why would you start a project with a tool which got no future? Let's then use Silverlight or any shit like that.

Mostly it just needs resource defaults merged and some abstract type support so load balancer config doesn't have to be entirely by labels and I would never shift from it.

I had a really (what I thought at the time) cool idea for a new Kubernetes storage driver, so I implemented the basic version in an evening. That's the first "rave-worthy" event - the architecture of these drivers is fairly complex and there are many ways to do it (see https://github.com/container-storage-interface/spec/blob/master/spec.md) so getting something working as I imagined it, knowing nothing beforehand, was the first moment of joy. The next day (after sharing in a few slacks) I got a DM from a tech lead at and he was really excited about the idea! That second affirmation that someone was excited about the project and wanted to brainstorm with me was my second moment of joy. And then for the third, last night and (some of today, still going to do more after dinner soon!) I've been doing detail work, and learning a ton, debugging, learning, making it slowly better... that flow state (often with music) is probably the closest thing to the idea of a rave. Anyway, that's my story! I love learning Kubernetes stuff, I'm so grateful I've been able to in my current role.

But if all of these are not an issue, then Containers and an orchestration system like Kubernetes can always take care of workload portability especially with OCI now in place for containers and CSI, CNI, CRI, SMI for storage, networking, runtime and service mesh respectively creating a healthy standards based ecosystem for all thereby enabling workload portability without lock-in since for a workload to be truly portable, all the underlying resources should be portable without any/very limited changes.

CSI (Container Storage Interface) is a standard which helps establish interoperability between multiple storage providers avoiding the need to have in-tree plugins within the core. So, any storage provider who supports CSI can work with Kubernetes without any issues. You can find a complete list of providers supporting CSI here