Uniform approach to development

Development
#1

Hi, VyOS Team.

I want to ask you do you have a system architect of project? Why I ask you. That is because I don’t see uniform approach to development.

For example:
When we configure ISIS the commands specific for interface configures inside ISIS branch configuration (in the manner of Juniper)
set protocols isis <name> interface <interface> hello-interval <seconds>
But the same configuration for OSPF performs inside interface configuration mode (in the manner of Cisco).
set interfaces ethernet <interface> ip ospf hello-interval <seconds>
And the same for RIP. Such things don’t seem critical. But it’s all a little bit confusing.

I think if you chose the Juniper-like CLI so you should follow this way. And all routing protocols commands specific for interface must be configured in protocol config mode.

The second example: I came across maniphest T2019.
I disagree with one of the statements declared in the maniphest what did I say there. I think it is not a bug but feature. And I’ve substantiated my opinion. But I did it late and the behavior has already changed. So what will you do in this situation? Will you back the behavior or leave it as it is? And who will decide it?
Openness to suggestions is a good thing. But not all wishes should be implemented because not all of them are reasonable as in this case.

I understand that this is an open-source project. Maybe I’m too nitpick. But these little things form the attitude to the project in the end. Especially since you have a commercial component.

It may seem that I’m scolding you. But this is not the case. I say this all because I want the project to be even more successful. And I really appreciate what you’re doing.

#2

Task for rip and ospf
https://phabricator.vyos.net/T1513

But for first we should rewrite ospf from Perl to xml/python style.

Isis was implementing and appeared in vyos not so long ago.

#3

Hi @craterman!

First of, really nice that you like the vyos project and want to make us succeed!

About your first question on the architecture of the project:
The vyos project was forked forked out of the vyatta project a long time ago, and have until now been working on contributors all over the world to get to the stage it is now.

As for now we do not have a well defined written architecture document to follow, but are following the principals left by the vyatta team a long time ago, and cleaning up stuff as we go. As for this we still have A LOT of legacy code in the project and are trying to clean away a lot of this code where the most used parts get prioritised.

One of the things we are doing when we rewrite stuff is to consolidate the places where a feature store its configuration in the vyos config hierarchy, the reason for this is that then we can have one script responsible for all checks and configuration needed by a daemon and its easy to “hook” it into the old vyatta backend. This is in contradiction to how the configuration was done on vyatta, where many small bits of configuration was placed on each and configurable item in the hierarchy.
you could read up on these things here: https://docs.vyos.io/en/latest/contributing/development.html

as for your questions on isis vs rip and ospf, this is a known change. the reason for this change is what i described over. and as @Viacheslav noted, this change is also going to happen for rip and ospf. ISIS was done first because it is a new implementation and we do not need to worry about legacy code. on rip and ospf we need to do a complete rewrite of the feature before we move them into its new place, we also need to be carefull not to break anything in that part. so, it is on the plan to change this behaviour, but it takes more time than on a new from scratch feature implementation.

As for your question on LLDP, the decision on the cli is a collective decision, and many times are up to the main developer for that feature to decide on implementation. there are however possible to change this decision in the afterhand if the initial implementations is sub-optimal or have other issues. This is the rule until the version goes to full feature freeze(as 1.2 is now), at that point the cli is locked. i’ve not read trough the LLDP implementation but will try to take a look on it.