The issue exists because the ifupdown package that is required for the eni renderer was removed by the https://github.com/vyos/vyatta-cfg-system/commit/3dd837f2d3518b7ddcf8e1ab68d8ab9f3eff0968
To not take back it again for all the platforms, the problem was resolved by the https://github.com/vyos/vyos-vm-images/commit/090e5367dc6df9b49c037e0b60f7adfafdf54a53 , so all the images created with the vyos-vm-images should not contain the problem with the renderer.

This task must be obsoleted by the https://phabricator.vyos.net/T2116

Just a small update on this.
PXE boot service for all 1.2 / 1.3 / 1.4 versions is up and running in private testing.

The root of the problem here is changed place for custom options and the ability to configure options that should be applied differently, depending on the place. In other words, "Additional OpenVPN options" becomes "Additional OpenVPN options. You must use the syntax of openvpn.conf in this text-field", but actually these variants are not fully equal and cannot be converted directly.

Still does not work in 1.4-rolling-202102060218

Moving tunnels between bridges works well in:
1.3-beta-202103110443
1.4-rolling-202102060218

Both UEFI and MBR boot modes are supported currently.
As a replacement for keys from Microsoft, it is possible to use our keys and ask users to install CA into a MOK database.

Most likely this should be done (after firewall rewrite) as jump statements.

Kernel related part is located here: https://github.com/vyos/vyos-build/tree/current/packages/linux-kernel
The rest is here: https://docs.vyos.io/en/latest/contributing/build-vyos.html

The idea stays actual, but unfortunately, it needs now to be rewritten according to the new config implementation.

I would like to solve this in the next way. I will:

1. Add verification to our config module to avoid impossible configurations.
2. Add IPv6 gateway processing (how could I miss this? Cannot imagine...).

I saw multiple times configs with a firewall section that contains about a thousand lines, so I do not think that DNS records are something size-critical that deserves additional config files.
I believe that keeping config parts outside the config.boot is a bad idea in general that against our main benefit - single config for everything.

Can you share details about your hypervisor and datasource? Also as the full Cloud-init log (/var/log/cloud-init.log)?
Either datasource generates a wrong config, either the format is not well described in the Cloud-init documentation - there noted that: "gateway: IPv4 address of the default gateway for this subnet". I more believe in the wrong documentation, but would be better to check.
Independently of this all, the situation is not good, because we need to verify values that put into config. So, this will be fixed in one or another way (proper adding or drop), when we figure out details.

https://github.com/vyos/vyos-cloud-init/pull/31

This was resolved via:
https://github.com/vyos/vyos-cloud-init/commit/1607eec32641ad93ea211e447336b3366c28de06
https://github.com/vyos/vyos-cloud-init/commit/3980057ce140ea6896cd3f7cd4299cfd29cf234a

I am suggesting switching to https://github.com/vyos/vyos-vm-images for everything, except ISO images. This will solve the problem automatically. It is already able to create images for QEMU, VMware, Hyper-V, GCE, AWS, OpenStack, Oracle, Packet, and more not mentioned in the https://github.com/vyos/vyos-build. The only what I have not tried yet is Azure.

Setting Ethernet interfaces addresses, routes, and name servers are supported in both versions now. Advanced features like bonding, bridges, VLANs could be added later on-demand.

This was resolved via dhclient hooks - there is a protection mechanism now, which allows deleting only routes with tag 210 that set by hooks to all DHCP routes.

Resolved in https://github.com/vyos/vyos-cloud-init/commit/92f43f79574bffb8b5731a09aea6def3ed9551dc

The config module without this problem is available in the crux, should be released in the 1.2.7 version.

The config module backported to the crux, should be available with 1.2.7 release.

Resolved in https://github.com/vyos/vyos-cloud-init/commit/12a4c9c500695e160b4543f6c93a87c333f0a8ae

Backported to the crux branch, should be released with 1.2.7.

After the testing with a standalone User-Data handler, this feature was ported to the main cloud-init package in https://github.com/vyos/vyos-cloud-init/pull/27.
Currently, supported only set and delete commands processing. They must be provided as a list in the vyos_config_commands option.

The main reason for such issues is missing a good one instructions on how to build a proper one image.

NoCloud (and actually any datasource which provide network-config) must be supported now in VyOS 1.3. Feel free to test it.

This feature now is in the Cloud-init for 1.3 and must be backported after testing.

The configuration module for 1.3 is compatible with both network-config versions now. Initial testing was successful, but let's keep this for some time to collect more cases.

@kroy how about testing this in 1.3? It must work now.

Handling of all supported by VyOS configuration SSH key types was added to the VyOS 1.3 by this commit https://github.com/vyos/vyos-cloud-init/commit/d4004ac6ea1c7c03a35d9410f7c70ab423c926bb

https://github.com/vyos/vyos-1x/pull/527

Just to make this a bit clearer. A short how-to to reproduce the bug in 1.3-rolling-202008031114 with empty config:

set firewall ipv6-name WAN6_IN6
set firewall ipv6-name WAN6_LOCAL6
set interfaces tunnel tun1 6rd-prefix '2607:FA48:6ED8::/45'
set interfaces tunnel tun1 6rd-relay-prefix '24.225.128.0/17'
set interfaces tunnel tun1 address '2607:FA48:6ED8:8A50::1/60'
set interfaces tunnel tun1 description 'Videotron 6rd Tunnel'
set interfaces tunnel tun1 encapsulation 'sit'
set interfaces tunnel tun1 firewall in ipv6-name 'WAN6_IN6'
set interfaces tunnel tun1 firewall local ipv6-name 'WAN6_LOCAL6'
set interfaces tunnel tun1 mtu '1480'
set interfaces tunnel tun1 multicast 'disable'
set interfaces tunnel tun1 parameters ip ttl '255'
set interfaces tunnel tun1 remote-ip '24.225.128.1'
set interfaces tunnel tun1 local-ip '24.225.136.165'
commit

leads to the error:

Can not set "local" for tunnel sit tun1 at tunnel creation

and the same but without the local-ip option leads to the Python traceback.