PR: https://github.com/vyos/vyos-utils/pull/4
Adding the additional validator to policy.xml.in allows the smoketest (above) to pass.

One approach is linked below; to be discussed before PR.
https://github.com/vyos/vyos-utils/compare/master...jestabro:increment-decrement?expand=1

I hope it can be found. I have been banging my head against the wall with this issue :( and it's hurting.

load-balancing wan completely broken with nexthop dhcp for 1.4 (it happens after first reboot or renew)
The script gets empty values there https://github.com/vyos/vyatta-wanloadbalance/blob/a831f22d4c34bf947b0335e55573280b75c2bde0/src/lbdecision.cc#L180
So ip route replace table is never executed
Why does it get an empty value?
It parse lease file https://github.com/vyos/vyatta-wanloadbalance/blob/a831f22d4c34bf947b0335e55573280b75c2bde0/src/lbdata.cc#L335-L341
option new_routers and in 1.4 the file looks as

i've checked this issues, it seems to be solved . I think that it was solved for another task. I used the following vyos version :

I'm also trying to get this up and running. The latest 5.4 kernel fixes this issue, but other issues remain, like bridging not working.
Instead of backporting the driver, I ended up backporting the lataest 5.10 kernel to the 1.3 branch.

Ongoing activity:

1. Stabilization
-  I have seen a corner case that would crash inside the northbound callbacks.
-  I can see some validation failure logs, although the resulting output seems good for me.
-  Daniil was concerned about memory leaks associated with iteration state.
   After additional research - this is not a problem, but I can imagine cases where we would
   fail to handle a malformed XPath and leak resources on the stuck unwinding
   I need to do some testing with Valgrind.
2. Scale testing
3. Async support for multiple vtysh clients. The current demo assumes that there is only one client.
   I want to map the iteration state to the vtysh client/socket so multiple requests may be executed in parallel
4. A debugging instruction
   I have used some complicated debugging flow when merging the feature.
   This should be useful for other (non-C) devs.
5. Finishing the documentation
6. advanced XPath filtering support?

Recently, I had a conversation with the VMware team lead - Pushpasis Sarkar.
He has described the ongoing development and explained the use case they are interested in.
From the conversation:

1. The latest proposal draft: 
   Page 72-73 `Retrieve Operational Data - Retrieving Containers and Leaf members`
   Page 84-85 `Retrieve Operational Data - Retrieving Large List elements` + comments
   Page 86 `Retrieve Operational Data - Retrieving Containers and Leaf members` + comments.

I have also hit this into the latest rolling version:

PR for 1.3 https://github.com/vyos/vyos-1x/pull/1364

I think it should check this parameter per commit and it is a bug with validation as we don't have a tunnel interface yet
But after commit it will be valid value

PR https://github.com/vyos/vyos-1x/pull/1363

vyos@r14# set service webproxy url-filtering squidguard source-group fdsf-dg
[edit]
vyos@r14#

It seems issue with this validator https://github.com/vyos/vyos-1x/blob/1978946312a36f4913e1e5ea7754668b1c653d09/interface-definitions/service_webproxy.xml.in#L487

route-maps support a relative adjustment of the metric (https://github.com/vyos/vyos-1x/blob/current/interface-definitions/policy.xml.in#L1402-L1417)

@kroy Are you still having trouble with it?

PR: https://github.com/vyos/vyos-1x/pull/1362

PR: https://github.com/vyos/vyos-1x/pull/1361

PR https://github.com/vyos/vyos-1x/pull/1360

Since in previous version set protocols nhrp tunnel tun0 cisco-authentication "" was allowed, a migration script is required. Otherwise, when upgrading, configuration fails.

PR https://github.com/vyos/vyos-1x/pull/1358

set protocols failover route 203.0.113.1/32 next-hop 192.168.100.1 check target '192.168.100.1'
set protocols failover route 203.0.113.1/32 next-hop 192.168.100.1 check timeout '10'
set protocols failover route 203.0.113.1/32 next-hop 192.168.100.1 check type 'icmp'
set protocols failover route 203.0.113.1/32 next-hop 192.168.100.1 interface 'eth1'
set protocols failover route 203.0.113.1/32 next-hop 192.168.100.1 metric '2'

Working on moving groups to named set as part of a refactor in some firewall code.

Thanks for the pointer, but I think it should still be considered a "bug" that you can no longer use an empty group (I'm just going to assume that this would apply to any kind of group, but most are probably using this for host/network groups, as this is where it would be most useful). Judging from the comments in T4147, I'm clearly not the only one who was taking advantage of managing sets outside of the system. Alas, my boot times for 1.4 (what this discussion is about) are not really valid, as my configuration didn't really get migrated from 1.3.1->1.4, or better said, it doesn't actually commit, and I actually ended up with a mostly empty firewall config on boot, which is perhaps why its booting so quickly now.

Tested with VyOS 1.4-rolling-202206100921
Works as expected
Described in the documentation

Tested in VyOS 1.4-rolling-202206100921

The problem seems to be in these lines:

Extra checks are needed not only when attaching a policy route to an interface, but also when attaching firewall.
For example:

vyos@vyos# set firewall name FOO rule 10 action accept 
[edit]
vyos@vyos# set firewall name FOO rule 10 destination group address-group NOAG
[edit]
vyos@vyos# commit

PR: https://github.com/vyos/vyos-1x/pull/1357

PR: https://github.com/vyos/vyos-1x/pull/1356