VyOS Platform Blog

VyOS Project September 2020 Update

Written by Daniil Baturin | October 12, 2020 7:59:16 PM Z

The biggest announcement of September was the 1.2.6 release, and we even skipped the August update while we've been busy with it and the automated release procedure, but we worked on other things as well. Now that 1.2.6 and its security hotfix update are done, we are back to working on the strategic goal — 1.3.0 release, and further improving our processes.

VyOS 1.3 development news

Cisco AnyConnect-compatible implementation

This is August news, but since we skipped the August update... Yes, VyOS now includes a Cisco-compatible AnyConnect server implementation thanks to the OpenConnect project.

The docs are minimalist yet, but documentation pull requests are always welcome.

get_config_dict() becoming mainstream — say goodbye to hardcoded config paths in scripts

In the old Perl code, we used to painstakingly extract every value from the config with function calls like config->returnValue("system host-name"). Our early Python code was more or  less "the same, but in Python" due to the limitations of the underlying code.

Then we've made a parser capable of fully understanding the config syntax we inherited from Vyatta Core, and that opened up many possibilities. One of them is a function that automatically retrieves a config subtree as a Python dict.

It's been considered an experimental feature for some time, but now the rough edges are polished and it's more or less mature. Some components including DNS forwarding. It makes scripts considerably shorter, and will make it easier to write new features from scratch since you only need to write validation and generation logic by hand.

If you want to try your hand at adapting a component to the new approach, let us know.

Other improvements

  • The config daemon that speeds up commits by loading scripts in memory is getting mature. Its memory consumption is significant though, so it will be optional. Stay tuned for updates!
  • PPPoE server feature set is improving.
  • Wireless support has seen some improvements first time in a long while.

All in all, while a stable 1.3 release isn't exactly around the corner, we are getting there. Support for containerized third-party applications and a complete rewrite of the routing protocol configuration are still in progress. When those are done, we'll be ready for a 1.3.0-epa1.

XCP-ng/XenServer XVA images

We are striving to make VyOS easily installable on all major hypervisors. One platform that wasn't covered until recently is Citrix XenServer and the open source XCP-ng. You could install VyOS by hand from a live CD, but that's about it.

Starting from 1.2.6, we are making .xva images that can be deployed in one click, with XCP's version of xe-guest-utilities built-in. We started with a manual procedure, but automation is underway and XVA will become a build target soon.

Oracle Cloud marketplace Listing

We also want users of every cloud platform to be able to easily use VyOS to connect different clouds to one another and to their headquarters and datacenter racks. We already provide VyOS images on AWS, Microsoft Azure, and Google Cloud Platform.

Soon we'll add another marketplace to the list: Oracle Cloud Infrastructure.  The image is ready and waiting for approval, so stay tuned for updates.

Rolling release snapshots

We promised to start making rolling release snapshots a while ago. Right now we only have two options: nightly builds that may be broken, or LTS release that is known to work but doesn't have latest features. The former is perfect for contributors who work on the code and testing, the latter is made specially for production use.

However, a large share of our user base is networking geeks and lab operators, and neither option serves them especially well. There needs to be a middle ground: a way to get a system that is knowingly not broken, but offers latest additions and experimental features to play with.

Our formal promise was to start making snapshots when we hit a 700 EUR/month target on Patreon. We are nearly at that target now, which means that individual community members are willing to support the project. Thus, this month we'll make our first rolling release snapshot.

We'll make snapshots monthly. If  a snapshot turns out to have serious bugs in it, we'll re-build it after fixing the bug. Stay tuned for updates!

Different rewards for Patreon and BuyMeaCoffee supporters

When we first setup our Patreon and BMC accounts, we used LTS images as a reward for supporters. Unfortunately, there are quite a few people who apparently sign up just for the LTS image access. Many people  game the system by signing up when a new LTS image is released and withdrawing their pledge immediately after. Some of them appear to be commercial users.

Rolling release snapshots are going to fill the gap between "completely stable" LTS and "completely unstable" nightly builds and give network geeks and lab users relative stability and bug fixes. This will make LTS releases less necessary for non-production use, so we'll sunset LTS releases as a reward Patreon and BMC supporters.

Does it mean our supporters will get fewer rewards. Of course not! We want to make sure people support us because they like the project, rather than to avoid getting a subscription for their company, so the goal is to create a set of rewards more relevant for community users.

We are thinking of monthly Q&A sessions with developers and certification vouchers for the start. If you have any other ideas, let us know!

Future plans

Our plan to make a VyOS controller appliance for managing multiple VyOS installation is in force. It's still in a preliminary R&D stage, but we will present its basic architecture for a wider discussion when it's ready.

A more short-term plan is a rework of the current system of image build flavours. A rewrite has been planned for a while, but we didn't have a good idea what we want from a new system. Now it's taking a shape. One big plan is to make target platform and image format orthogonal. Another plan is to make writing flavour files easier and make them more functional.

Right now flavour file are in JSON, which has its limitations. Switching to TOML will allow many improvements, like multi-line strings, and also better human readability.