VyOS Networks Blog

Looks like there’s quite a bit of misunderstanding regarding free subscriptions for contributors, who is eligible, and how people can contribute to the VyOS Project.

The idea was to split VyOS into long-term support and rolling releases.

The long-term support releases are meant for enterprise and service provider users who want stability and quick bug fixes. The effort required for testing it, backporting fixes, and doing other maintenance tasks to keep it stable is considerable, which is why it’s only available to people who help VyOS move forward, either by contributing to it or by funding project via subscriptions.

The LTS release is also buildable from source (or the binary package repositories we never intended to close down), and the procedure is rather simple. Just follow the instructions in

https://github.com/vyos/vyos-build (important to mention that the core team will support only official builds). You need to use the “crux” branch to build the 1.2.x releases. 

The rolling release snapshots, made once a month or so, are meant for small companies, labs, and home networks of advanced users. It will be free of charge, but its stability is not guaranteed. To put it bluntly, if you can’t or don’t want to contribute, pay, or build the LTS release from source, you become an involuntary beta tester of the latest features and fixes. We will use date-based versioning for the snapshots, for example, 2019.1.

An important point is that LTS releases are available to people who buy subscriptions and people who contribute to VyOS (or both). Such approach allows us to bring more funding to the project as well as new contributors — individuals and company-backed.

I’ll reiterate that everyone who contributed before the release model change, gets a perpetual subscription. People who joined later will get yearly subscriptions if they contributed within the last year. You can apply by filling this form: https://share.hsforms.com/1DmAR8XwnR2W2Ys8-gBbiOQ2ghzu

There are many ways to contribute. We count people as contributors if they send us patches or pull requests, report bugs, write documentation, testing functionality or promote VyOS via blogs, social media, and word-of-mouth.

Assessing one’s contributions can be a tricky and subjective, but I’ll try to give some rough guideline. You are definitely eligible for a subscription if you:

• Send us a pull request with a non-trivial feature or bug fix
• Document one big feature or multiple small features
• Report non-trivial (behavior-affecting) bugs
• Promote VyOS through posts blog or social media posts or through conference talks, forums and so on.
• Tests VyOS on previously untested hardware.

This list is neither definitive nor exhaustive. For example, a person who puts serious effort into fixing errors and typos in documentation or improving CLI help text definitely qualifies. There may also be types of contributions I have overlooked completely. Don’t hesitate to fill the form — worst that can happen is that we ask for some more contributions in your field. I promise none of the maintainers will disqualify anyone permanently

What we value most is commitment. For example, if you report a bug, it’s also important that when we make a fix, you are still there to re-test and confirm that it works for you. This is especially true for configurations that are hard to replicate in a lab.

Likewise, if you write a new feature, someone needs to maintain it and fix bugs reported by users. It’s much better for everyone if the original author either leaves enough documentation or, better, sticks around and helps us maintain it. Committed contributors are can eventually become maintainers if they want to.

Getting started

Writing documentation

Documentation is incredibly important for the project, and there’s still a lot of work to be done.

Wiki registration is now closed due to excessive spam, but we create accounts for everyone who’s interested in editing it. Just drop an email to wiki@vyos.io or contact dmbaturin on IRC or syncer on Slack. Sometimes we cannot handle requests immediately and it may take a few days (or more) for someone to take action

You can use the old Vyatta 6.5 documentation as a blueprint. Many features remain CLI-compatible, but even for those that aren’t, it’s still easier to write by example than from a blank page. Please do not copy anything verbatim though, the old docs are not under a free license and copying them without permission from original authors (which is now impossible to obtain) is illegal

Testing

First of all, register an account in https://phabricator.vyos.net

Then, you can try your configurations in the latest rolling release/nightly build and report if it’s broken. A lot of time, bugs only show up in less common configurations though, so testing features such as wireless interfaces or unusual feature combinations are especially helpful. 

Writing code

First and foremost: since VyOS consists of multiple submodules, making changelogs from the git log alone is very hard. For this reason, every change must have an associated task in Phabricator and the task must be referenced in commit messages (as in “T9999: fix config loading issue on a quantum computer”). You can also use certain keywords to mark a task closed (e.g. “fixes T9999” or “resolves T9999”) but that should be reserved for trivial issues. Generally, a task should only be closed when it’s confirmed by testing, not when code supposed to fix it is merged in.  

Then, please read these articles:

• https://wiki.vyos.net/wiki/Perl_considered_harmful
• https://wiki.vyos.net/wiki/Python_coding_guidelines

An important thing to note is that VyOS is undergoing a major rewrite. The rewrite involves a language change (Perl and shell to Python) and a new approach to command definitions.

We no longer accept new features written with the old approach.

The guidelines are not arbitrary, they are essential for writing code that will work with concurrent commits and non-disruptive rollbacks, so they must be followed to the letter.

The new command definitions are based on XML and thus malformed definitions are caught at build time when they are checked against a schema.

All new code goes to the vyos-1x package. You can use the new VRRP implementation as a template:

• Configuration command definitions: https://github.com/vyos/vyos-1x/blob/current/interface-definitions/vrrp.xml
• Configuration script: https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/vrrp.py
• Op mode command definitions: https://github.com/vyos/vyos-1x/blob/current/op-mode-definitions/vrrp.xml
• Op mode script: https://github.com/vyos/vyos-1x/blob/current/src/op_mode/vrrp.py

If you want to change any CLI, please discuss it with maintainers and other users in Phabricator and on the forum first. If you change any configuration syntax, a migration script will be required to maintain compatibility with older VyOS versions. Writing them is now much easier but you still should not do it without a good reason. You can find an example of a migration script here: https://github.com/vyos/vyos-1x/blob/current/src/migration-scripts/vrrp/1-to-2

Badges for VyOS Project contributors, maintainers and evangelists

You already may know badges from other vendors like Cisco, VMWare or maybe IBM, there are more companies at acclaim platform which we joined last year and now ready to issue first badges to our community. Badges are a great way to showcase your skills on LinkedIn or other social media, as a highlight in your CV or as an argument in your promotion negotiation.

We initially launch next community badges: 

and technical certification badge:

Badges list and types will expand over time, this just to begin with.

Now we have a list of contributors who will be receiving badges after this announcement, if you have not received the badge, but think that is an error, please write us