I have been hard at work building the back-end infrastructure to support Kata containers as I explained in this post. As I briefly described there, one of the big reasons I wanted to work on this is so that we could add a new image based on cRPD for Junos network endpoints. This has several advantages over vQFX, but the biggest one is that cRPD is actually a Juniper product, whereas vQFX is not. This has some immediate obvious benefits, mostly around overall quality, supporting the latest and greatest features and industry standards, etc.
It’s also much more lightweight. cRPD is not a full-blown operating system. So it starts extremely quickly. Running it on top of Kata containers means it still gets its own kernel, so everything is properly isolated. I believe this will make things much easier to also integrate similar stacks from other vendors and other open source projects, like FRR, that require a similar paradigm - they don’t want to be an operating system, but they still need some isolation
Unfortunately, in order to allow folks to build content with it, the preview service needs to be running on a cluster that supports kata containers, and with a version of Antidote that supports this through image flavors as well, the latter of which is not even in a release yet. As of now, there is no production cluster or antidote version that gives us this. That’s what I’ve been working towards.
So, my plan is to upgrade a few lessons in the curriculum to use cRPD as an example, and move forward with the release of the curriculum 1.3.0, Antidote 0.7.0 (which supports image flavors), and build a new cluster that supports everything we need. Shortly thereafter, I’ll swing everything over - the main NRE Labs site, and all of the services needed to build content (like the preview service) will be running on this and we’ll be ready to go.
I’m hoping to be able to pull the trigger on all of this within the next few weeks.
cRPD seems to offer a lot of improvements, but I haven’t gone through and replaced all vQFX endpoints in the curriculum with cRPD, and I’m not sure that’s necessary. Where vQFX has been deployed thus far, it works rather well. The main concerns I’ve had are lessons that have three vQFXs, and really only need one. This is not just because of resource considerations, but also because inter-networking vQFX endpoints in NRE Labs has a bunch of fragile duct tape that has been a source of pain in the past.
So, in addition to replacing the vQFX image in some lessons with cRPD, I’ve also been scaling back its use, in particular in the terraform and Stackstorm lessons, both of which really only use vqfx1, but had all three.
Longer-term I’d like to get the vQFX image updated a little bit if possible based on some of the things that have happened with it over the few years since we published it, and see if we can do away with the use of snapshots (which required manual builds, and also caused weird issues with mac addresses, thus the three separate
vqfx3-snap images). Provided the startup time on our baremetal cluster is comparable, or at least tolerable, the simplicity of just importing a base image and having it work might be worth it where a full-blown OS running Junos is needed.
So, while the role of vQFX is definitely changing, at this point I’m keeping the changes to a minimum, and where vQFX works, it can stay there. I’d much rather invest these cycles into introducing new endpoint images into the curriculum anyways.