Is there any way I can help test this? I was trying to setup the same, but lack of link-local support prevents me from adding a v6 BGP peer without allocating IP addresses to the link.

Sorry, the task name was wrong, "save" resets it, "commit" doesn't. Personally I prefer if it'd stay the same, but I don't care if it resets it either.

Personally this is behavior I agree with.

Tested successfully in Crux.

@alien Can you please share your config, I can't reproduce it. The op function will be moved into the the ops script out of the ifconfig class, which caused the issue due to restructuring out internal class architecture.

Following script more appreciated

/run/atop/atop.acct {
	rotate 0
	nomissingok
	size 100M
	postrotate
		PIDFILE=/run/atop.pid
		if [ -e $PIDFILE ] && \
			ps -p `cat $PIDFILE` | grep 'atop$' > /dev/null
		then
			kill -15 `cat $PIDFILE`
			rm $PIDFILE
		fi
		sleep 1
		/etc/init.d/atop restart
	endscript
}

Sometimes we use this for detecting memleak and some clients issues with high CPU load. When we get users /var/log/atop* then we can reproduce locally and find wrong process, memleaking etc.

Nice. What is atop actually used for?

Thanks @syncer and @c-po . As I understand logrotate run once per day. I hope this will be enough

vyos@vyos:~# ls /etc/cron.daily/ | grep logro
logrotate
vyos@vyos:~# cat /etc/crontab | grep daily
25 6	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

So, now I have logrotate script for atop on my test router

cat /etc/logrotate.d/atop 
/run/atop/atop.acct {
	rotate 0
	nomissingok
	size 50M
	postrotate
		/etc/init.d/atop restart
	endscript
}

With manually run, seems all works

logrotate /etc/logrotate.d/atop --verbose
reading config file /etc/logrotate.d/atop

As the mtu on an ip network could exceed 1500b it is not so strange to allow larger than 1500b frames on the tunnel. But this could be adjusted to follow the max mtu values on ethernet interfaces. As taken from my head max mtu on ethernet is about 9000b

https://github.com/vyos/vyos-build/pull/95

I'm looking forward to this feature, especially that I want to dynamically update the NPT policy through the DHCPv6 PD feature, rather than manually reset the nptv6 address translation policy every time I dial

It's a good idea to use OVS as Linux bridge, which means that vyos can use OVS to provide better management and more support features in bridge management, or even use vyos as an excellent switch to run and manage its complex functions, or provide a docking interface with SDN to transform the network!

Yes, @jjakob, I run docker as indicated in the vyos-build README, which includes --privileged. I am not that concerned with the docker issue here; rather I want the script to work, and am adding in the necessary ingredients to the script itself. Compare the older prescription:
https://wiki.vyos.net/wiki/Building_images_using_vyos-build_Docker_container#Building_Google_Cloud.2FGCE_image

just note. our fw is using own dns forwarder for resolv, because the internal ip reverse addresses are redirected to local dns server.
so plase handle this situation too.

We hope to provide better support for DHCPv6 PD in the future version of vyos

The discussion says the container should be started with --privileged, as is documented in the vyos-build readme. Did you test it with --privileged?

Duplicate of T421

Still present in 1.3-20200319

The above commit fixes value help on tab (it displays correct quoted values, the script doesn't error any more) but the completion itself is still broken.

@hagbard
Another bug:

@alien Can you please test the issue with the latest rolling release?

This should be made consistent with other usage: paths should be lists, not strings. I will make the change, and any other details needed for consistency with model.

I ran into this today after upgrading to latest 1.3 rolling image. All interfaces were added and appeared to have the correct macs (the output of ip link matched what was in the config), but the physical interfaces to which they corresponded weren't right. I found this by looking at the link state of each interface and saw that two if them were swapped. The interface that should be eth2 was physically eth4 and vice versa, but the macs it was showing in ip link was wrong for that physical card, as if it were set to the other interface's mac erroneously.
I got the cards to detect properly after 2 reboots.

I installed 1.3-rolling-202003190217 today and verified that it contains the following lines now:

Some tests results

vyos@R8:~$ show configuration commands | match mpls
set protocols mpls ldp discovery transport-ipv4-address '2.2.2.2'
set protocols mpls ldp interface 'eth1'
set protocols mpls ldp interface 'eth2'
set protocols mpls ldp router-id '2.2.2.2'
vyos@R8:~$ show mpls ldp neighbor 
AF   ID              State       Remote Address    Uptime
ipv4 10.0.0.1        OPERATIONAL 10.0.0.1        00:00:22
ipv4 3.3.3.3         OPERATIONAL 10.0.255.2      00:00:33
vyos@R8:~$ show mpls ldp interface 
AF   Interface   State  Uptime   Hello Timers  ac
ipv4 eth1        ACTIVE 00:00:51 5/15           1
ipv4 eth2        ACTIVE 00:00:52 5/15           1

2 PR for basic MPLS implementation
https://github.com/vyos/vyos-build/pull/90
https://github.com/vyos/vyos-1x/pull/247

Could you describe your "dream syntax" for it?
The op mode node.def's simply don't have a concept of value help in vyatta-cfg, only comp_help (<completionHelp> in XML terms).