You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the spec states that deletion is the same as ADD, but in reverse order, and that, crucially, an error message from a plugin stops the deletion "chain".
This can lead to leaked networks / IPs, especially in the case where some chained plugin has some fatal error.
We would like to change the spec so that deletion is error-tolerant.
The text was updated successfully, but these errors were encountered:
Hi @squeed , a little confused, what's the definition of error-tolerant?
I mean if we tolerate the errors coming from the first chained plugins to avoid IP leak, then what about the error from IPAM plugin? Should it be tolerated? If do, then this error will cause IP leak too.
We thought about this for some time, and we do not want this.
Doing so could lead to, for example, chained plugins receiving a DEL for an IP address that has subsequently been reused by another container. Not good.
Right now, the spec states that deletion is the same as ADD, but in reverse order, and that, crucially, an error message from a plugin stops the deletion "chain".
This can lead to leaked networks / IPs, especially in the case where some chained plugin has some fatal error.
We would like to change the spec so that deletion is error-tolerant.
The text was updated successfully, but these errors were encountered: