Dan Winship

@ruheenaansari34 #3454 is merged. Can you confirm that we are OK for Alpha?

> Executing binaries in a containerized environment is fragile (not everything can / should be statically linked) Citation required? It seems to me that the problems with dynamic linking are...

> > It would be great if CNI 2.0 required all plugins to be run from containers, even if they aren't daemons, and did not require containers to make any...

> > > To the best of my knowledge there is currently exactly one known bug ... > > > > > > Agreed, that is my understanding as well....

(And you can't just say "well don't use the 'unsafe' functions" because there's no way to know from the outside which functions are unsafe. It's entirely possible that plugins that...

> Wow, looks like @danwinship had the same idea in #628. Yeah, but I don't think that's the right answer any more. I mean, yes, CNI should have a way...

> I'm not a huge fan of using pod readiness to solely indicate plugin status: we've found it painful to have a pod readiness depend on the state of other...

> Besides, there could totally be daemonless CNI plugins My point is that I wasn't talking about CNI plugins in #628, I was talking about Kubernetes networking. At one point...

OK, there are a few pieces to this: 1. There are certain failure modes which are well-known to implementors but which CNI has no way of expressing to the runtime....

I talked about this in point 4 of https://github.com/containernetworking/cni/issues/859#issuecomment-1040426459 too. > This does not fit the existing Kubernetes model well (but that could be changed). The way SR-IOV works in...