How do you measure success as a developer ? Is it how good your code looks ? Is it how well covered it is by unit tests ? We think that while those are required, that's not it.

Could it be the opposite of the opened bugs then ? Someone actually bothered to open a bug / issue on it... Sorry to burst your bubble, but that's still not it; usually, projects without bugs just mean … they're not being used.

Thus, in our humble opinion, the code must matter to someone, and it must be used in production by as many people as possible - to the point they contribute, request features, and report broken “things”.

Now the thing is how do you get end users to use your stuff ? It's a non-trivial problem: unless you come up with something useful - and entirely new - odds are you're hoping people will replace one existing component of their stack (sure ... it had its problems …) by your new shiny toy. ... which only you care about !
And we all know migrations have their downsides … It usually requires a big improvement for people to be willing to pay the price.

Join us in this talk as we discuss strategies to get your pet project out there in the wild, and being used as it should / deserves.

CNI prides itself on doing just a few things right. It pretty much consists of a specification, and libraries for writing plugins to configure network interfaces in Linux containers. A lot of things are implementation specific - meaning, each plugin has a different understanding of what a configured interface should look like.

It does have some real short-comings; how do you know if the plugin is ready to actually configure an interface? How do you tear-down the interface’s allocated resources - when the container is deleted? IP Address management (IPAM) allocated resources are a good example – if you don’t do it properly you can leave an address stranded like Robinson Crusoe.

Up to now… That garbage collection would be up to the plugin. So your teeny tiny CNI plugin - which was thought of as something to run on a single binary on the host file-system - is now bloated to a daemon process to provide a reconcile cycle to teardown the resources depending on its use cases. Likewise when you need to know if the plugin is ready to do its thing.

Fear not, young grasshopper! The CNI maintainers have got your back and added two new verbs to the CNI spec (and libraries): STATUS - which signals if the plugin is ready - and GC - which helps to garbage collect the resources allocated by the plugin.

Join us in this talk where we showcase these two new verbs, providing a demo, and examples of plugin implementations of these new features.