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

kea_parse_leases was deleted in https://github.com/vyos/vyos-1x/commit/c44d24eae276f77c700e961a22c0cd5582416dff
Probably the correct function is kea_get_leases

Note that the PR https://github.com/vyos/vyos-1x/pull/3035 is only for 1.5 at this point: the critical question for this task is whether or not to restore the simple support for unicode.

Simple unicode support was allowed in
https://vyos.dev/T3785
however, the constraint on description, above, restricts to ascii.

Perfect, that's what I was trying to better understand. Thanks for the clarification!

The regex should be [-_a-zA-Z0-9.\s]+ instead of [-_a-zA-Z0-9\s]+

The short answer is that it will change going forward, and the work within this task, and the ongoing work mentioned above will avoid failing viable configs that have the symptom of 'full section of the config not applied'; that's what we are addressing here. The longer answer above attempted to distinguish several unrelated situations that have that same symptom, and in the extreme case of a user providing a corrupted, partial, or nonsensical config, there is not much that can be divined without some user feedback and suggested debugging: if critical dependencies are missing, that means that the system would be non-operational. What interests me here is some immediate improvements that may be made, and in proceeding with that, it is necessary to make these distinctions.

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

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

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

For 1.5 fix works as expected

vyos@r4:~$ cat /run/opennhrp/opennhrp.conf
# Created by VyOS - manual changes will be overwritten

works with version 1.5-rolling-202403050022

Gotcha! The thing I keep struggling to understand is why is the full section of the config removed? This will 100% cause outages. If there's part of the config that is invalid, only that part should not be applied. You shouldn't remove 19 valid lines of config due to a single invalid line. Particularly with almost all of the instances I've seen of this, the invalid line is just cosmetically invalid, and doesn't cause any issues with the operation of the system.

Should be fixed in the next rolling release.
Can you recheck it after 20240304 ?

Well, nothing is deleted, rather the config section is not applied if the verification steps do not pass: if the user ignores the error and warnings and saves the subsequent working configuration, the resident config.boot file will be overwritten. So I agree that it an issue for consideration, if we distinguish those cases in which this may occur, as above. Considering those cases, we can not or would not want to (1) automatically fix migration errors, in some sense or other, to avoid non-application of config sections on migration failure; bugs in the migration system should be fixed, and improvements to the migration system itself are part of the current development plans (2) support non-verified/non-existent interfaces without clarification of when if ever that is appropriate, such as the current investigation. There is current development of the design to refine the verification stage, unrelated to this specific task. Given the preceding, I would not say either that it is a case of 'everything's fine' or of 'design flaw'; design evolution is appropriate perhaps.

@jestabro, do you guys consider the process of deleting the entire config section for a single offending line working as intended? Or do you consider it a design flaw/bug that will get fixed? I'm trying to understand if that is an intentional design choice and will permanently be part of VyOS going forward, or if it's just part of growing pains as VyOS moves from 1.3 to 1.4.

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

Config sections not applied after failed verification is not a surprise, as discussed above, though it is understandably frustrating: warnings are provided on failure and upon entering config-mode subsequent to failure, to help avoid overwriting the saved config before investigation. As we continue this discussion we should distinguish the various issues (and I will open subtasks as appropriate):
(1) missing config sections on migration need to be debugged, as with T6076, ongoing ...
(2) verification of 'late' arriving interfaces (general); configuring ZeroTier (specific): I'm looking into what may be considered for the general issue, as mentioned, and I have some initial ideas; thanks to the details provided by @L0crian I'll reproduce the specific configuration for experiment
(3) support for hotplugging interfaces: not planned at the moment, but may be discussed again for 1.5

https://vyos.dev/T6076 is also similar...

PR https://github.com/vyos/vyatta-cfg/pull/75

I wanted to add this post from the forums to this thread. It appears to be the same behavior where the failure of a single line deletes the logical section:
https://forum.vyos.io/t/upgrade-from-1-3-6-to-1-4-0-epa1-looses-complete-dhcp-configuration/13935

Duplicated: https://vyos.dev/T6061

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

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

@paigeadelethompson it is another issue, open a separate bug report

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

Do you refer to initially admin-down or oper-down?

Now trying to migrate a second router, with different config. I have corrected the mistakes I could see in the config and have removed policy route config with tcp flags.

Reviewing the logs
When the interface "xfrmi-test-...." appears, opennhrp stops

Using the same router/config I noted previously, I see an "empty" config per T6084.

admin@removed# cat /run/opennhrp/opennhrp.conf
# Created by VyOS - manual changes will be overwritten

I then modified the nhrp vyos config and saved, and the opennhrp.conf was re-populated. Upon reboot, the file reverted to "empty".

Instead of that sysrq stuff, how does it work if you try these 3 tests?

If I comment out this line then everything works.

Thanks - yes - there were in fact 3 "passive-interface" entries for old interfaces, which I should have tidied. Having deleted them, the migration completed.

Check opennhrp.conf file
Could be bug if the ispec in the config T6084