Remove Ubuntu Fan support about incus HOT 4 CLOSED

While CNI could be adopted in principle, and it's really interesting to imagine re-using all that code in the Incus runtime, it's kind of a big spec (as you are probably aware).

The CNI spec summary states

The CNI specification defines:

1. A format for administrators to define network configuration.
2. A protocol for container runtimes to make requests to network plugins.
3. A procedure for executing plugins based on a supplied configuration.
4. A procedure for plugins to delegate functionality to other plugins.
5. Data types for plugins to return their results to the runtime.

At a high level, the networking "objects" defined in the CNI spec map reasonably well to networks and zones as they have existed in classic LXD, but only at a high level. In practice, I'd wager that very little actually existing CNI code would work without changes.

It all feels very K8s to me. There was a "land rush" of vendors new and old into the space a few years ago, and a very strong pressure to converge on something. And a lot of very smart people did heroic and amazing work, but I don't think that a lot of those configuration interfaces should proliferate.

As an aside, I am somewhat surprised that Podman is deprecating CNI.

OVN on the other hand, is a more full-featured target for integration that actually does stuff. But I wonder if it could be made easier.

from incus.

Incus has proper overlay networking support through standard OVS/OVN

Exactly. IMHO, considering the already good support for OVS/OVN, I don't see any reason to add another standard, like CNI. When considering adding another one, it should be at least as lean and simple as OVS/OVN, or better (leaner and simpler).

from incus.

never tried to upstream

ubuntu fan violates RFC specifications of using reserved IP ranges thus is not acceptable upstream - or in general should not be operated on public internet.

Some canonical products still use ubuntu fan on GCE cloud and AWS cloud.

However, a more native approach would be better, standards compliant and even potentially more performant. For example on AWS cloud k8s typically uses Amazon VPC CNI plugin for Kubernetes https://github.com/aws/amazon-vpc-cni-k8s Which as far as I can understand can achieve the desired effect (automatically allocate interfaces for a container, and for the host, as of when needed). See design details on https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md

Potentially when deploying non-k8s container solutions, using amazon-vpc-ci-k8s may still make sense to achieve coherent networking strategy.

from incus.

Sure CNI doesn't look like a good fit. And OVN is much better. But native networking in a given public cloud might be best for small/medium deployments, no? the point of amazon-vpc-cni-k8s is that native amazon cloud networking is used to dynamically create interfaces & ip addresses, attach them to instances and plumb them to the container - which one can also control and firewall using regular amazon tooling & reporting.

from incus.