I found the service is disabled .
vyconf is the future replacement of all of the legacy Vyatta code still present in VyOS. It’s still a work in progress which is likely why it’s disabled.
is it safe to enable it ? how to test it ? thanks !
It will almost certainly break something if you enable it. To my knowledge it’s not complete.
Maybe @jestabro can provide more info.
@L0crian is correct that it is not yet complete: there remains some final details of integration with CLI, before it can be considered for testing. Simply enabling the vyconfd service will have no effect, nor is recommended. However, it is expected to be in internal testing later this summer, and instructions can be provided for any one willing to help with that testing.
Good news 
what benefits will vyconf bring to us ?
VyOS 2.0 development digest #1
this blog mentioned vyconf , and would replace vbash , is it true ?
@freebsdjlu , with respect to that outline, vyconfd provides the backend replacement, with integration into the current vbash; replacement of vbash itself will be a separate matter.
Is VyOS going into a netdb like setup similar to Arista?
you mean the root cause is the current design which read/write unionfs-fuse fs ,rt ?
At least part of the issue if you look at the debugging I did in T5388.
Its not normal that boot times would explode to +5min just because you added 100 static routes - similar with firewall rules.
Specially since when you do the same manually through nftables or vtysh the change takes <1 second.
So there is something on how VyOS validates each config line until it finally ends up at its destination which is the root cause.
I have too little knowledge of python to debug this further so I hope others are able to take a look into this (hopefully the ongoing refactoring will solve this by itself).
Various caches etc only shaved off a few seconds here and there (should still be implemented IMHO but didnt solve the main issue).
From what I have seen, validation is indeed the main bottleneck as evident by the time a commit takes. And because VyOS config is mutable, validation also needs to be done at boot time, before applying the config.
Using a NetDB (alike) config store which only holds known validated data would mitgate that problem.
Sophos UTM (formerly Astaro) also uses confd ( which I think is the predecessor to NetDB? ).
The verification represents a pretty small amount of the total time (thought still should be looked at). Most checks that are run in verify() are checks that can be completed very quickly and are generally checked against hashable objects like dictionaries. The configd service and parsing of the config to a dict are primarily responsible for the long commit times. If you run the conf_mode script directly instead of through configd, it completes very quickly. This is some quick debugging from protocols_static.py with around 2048 static routes:
2048 static routes applied through the VyOS commit process:
Configuration loaded in 0.031607 seconds (173.400729 seconds total)
Configuration verified in 0.000513 seconds (173.401253 seconds total)
Jinja render in 0.003 seconds (173.405 seconds total)
FRR render in 0.058 seconds (173.463 seconds total)
Configuration generated in 0.061588 seconds (173.462846 seconds total)
Configuration applied in 2.060685 seconds (175.523538 seconds total)
Script completed in 175.523542 seconds
Commit completed in 215 seconds
The seconds total mentioned includes time it takes to load the protocols static module into configd. This time won’t be present when running the script directly. The configuration was applied (static routes present and valid) a full 30 seconds (around 175 seconds total) before the commit finished. So there is time added both before and after the actual conf_mode script is run. You can see the actual config is applied in just a few seconds. About 20 seconds of the total time are represented by the CLI level tagNode checks, so those validations are not inconsequential and there’s definitely room for improvement there. But it is still a small(er) amount of the total time.
vyos# show ip route summary
Route Source Routes FIB (vrf default)
connected 1 1
local 1 1
static 2047 2047
------
Totals 2049 2049
2048 static routes applied by running only protocols_static.py (outside of the VyOS commit process):
Configuration loaded in 0.000840 seconds (0.116620 seconds total)
Configuration verified in 0.000391 seconds (0.117024 seconds total)
Jinja render in 0.003 seconds (0.120 seconds total)
FRR render in 0.059 seconds (0.179 seconds total)
Configuration generated in 0.061605 seconds (0.178635 seconds total)
Configuration applied in 1.925608 seconds (2.104253 seconds total)
Script completed in 2.104281 seconds
Total time 3 seconds
Here you can see without any of the configd and other upstream overhead, the config takes almost no time.
As a side note, I built a proof of concept CLI to run on top of VyOS using Prompt Toolkit. All CLI level checks were in-process, the running and candidate configs were stored as dict objects and not parsed separately, and the saved config was stored as a JSON file. That PoC was able to process about 30k lines of config per second (on a 13900-H). Those 2048 lines would be applied in around 4 seconds through that commit process. So the problem is certainly solvable, and hopefully when the accrued technical debt from Vyatta is removed, tackling the problem is achievable.
So we will see this improvement in next stream release? 
So when will we see the next stream release?
In my case I hardly have any static routes, and our config isn’t that complex.
And it takes over 3 minutes to boot a router, and not a lot less to commit a configuration change.
Yeah, the long commit/boot times are not an artifact of static routes, it happens with any large config, like a decent sized firewall config, or MP-BGP implementation with many VRFs. Anybody that works in enterprise knows 50k lines of config is not uncommon for a firewall,
One thing the VyOS team could maybe do upon boot is to import conf from a JSON instead of parsing the config into a dict. This would radically improve boot times, though it wouldn’t do anything for commit times. It could be a decent stop-gap until the main issue is addressed.
Yeah my example of static routes was just a reproducable testcase.
I have as mentioned witnessed this all over the place in VyOS config such as firewall rules aswell and whatelse.
As I wrote in my previous post, if config is stored in an unmutable data store, parsing and validation is no longer needed, configuration can directly generated from it.
This is how Astaro / Sophos UTM did it (using confd).
Perhaps by adding some kind of checksum at last line to know if the config already been parsed or not?