more amount of generalisation as we would not only want to use it for DHCp but all kind of services

Well the commit you outlined alters file ins src/conf_mode - that directory is reserved for CLI configuration scripts.

I can confirm that this works fine on the latest 1.3 nightly.

I cannot replicate this in 1.2.8 or 1.3.0-rc5. No matter how long vyos-router.service (even absurdly high times) stalls, ssh.service happily starts. This was probably resolved a long time ago, making this a ghost bug.

Thanks, that makes sense. Do you think the current outstanding change could be merged in? It's not resulting in any incompatibilities (that I'm aware of), and while it doesn't fix the problem entirely on its own (doesn't include infrastructure work), it improves the code under test.

That is a noble idea. There are some build time tests available here: https://github.com/vyos/vyos-1x/tree/current/src/tests - maybe this helps

As far as I can tell (from README), smoke tests are meant more to be integration than unit tests:

that feels like you wan't to achieve the same goal as https://github.com/vyos/vyos-1x/blob/current/smoketest/scripts/cli/test_service_dhcp-server.py
I think the easiest way would be to just extend the smoketest with your tests that you find missing.

I managed to make the DHCP configuration testable, although the code has some hardcoded paths which I didn't want to mess with too much, so my addition may be suboptimal.

Merging this PR can fix this problem. Due to the complexity of the JSON parsing of NFT by the operation mode script, this task still needs to be tested, and the local test passes

@c-po It makes sense
Need to try.

Well test it tomorrow once it becomes available :)

They are all intermixed ;) - maybe I also missinterpreted the issue. Maybe you can retest the latest rolling which will be available by tomorrow? Image is currently build: https://ci.vyos.net/job/vyos-build/job/current/2195

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

Nvm I just noticed that the task number was mentioned in a commit, I have a feeling this won't solve the issue as this is related to the router bgp 123 vrf something rather than vrf something statements.

Very cool this has apparently been fixed already, I was reading through the vyos-1x commints and didn't see anything that looked related. What was the implemented change for this?

https://github.com/vyos/vyos-1x/blob/595ab70a5d50ef1f9e166959affd96ea1ee8c8c8/data/templates/openvpn/server.conf.tmpl#L228

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

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

No, I am assuming it will be created when they have implemented a fix. In the meantime, I guess VyOS 1.4 could pin the package back to the previous 4.3.7-1pdns.buster version which is what we are doing locally for the moment. The developer on the pdns thread said that he hopes to have a fix out in a few days.

I don't see the repo for "bullseye"
http://repo.powerdns.com/

PR for current https://github.com/vyos/vyos-1x/pull/967

Fixed, thanks.

@Viacheslav we have other "objects" in VyOS which also require deletion first under certain circumstances.

It seems impossible to delete network and container and add a new one in one commit

Fixed by PR966

Duplicate of T3499

It appears things are in such a state where that network doesn't actually exist:

To add to this, it looks like I'm not going to be able to get rid of that without rebooting: