@gadams I agree with 2, as becomes apparent in the current situation: it is misleading and should be changed so as to avoid confusion. If you want to take it up, that would be great; thanks. Regarding 1, if you are seeing boot hangs on a system with the above fix, we will need to investigate: I have not encountered it, so I can try to reproduce with the following information: rolling version; sanitized config; platform (vm or hardware). I suggest opening as a separate task, as the forum reports so far (unless I'm mistaken) have pointed to this one. Thanks again for the info.

@opswill I suggest closing this task and opening a separate task focused on the specific continuing issue.

This is resolved for rolling, and not applicable to Circinus until backport of T6326.

@opswill Yes, those debug messages report that vyos-configd is operating correctly: error_code 1 is 'success' in the enum list. Consequently, the obscuring error in vyos-configd has been resolved, and the root cause of your issue can now be investigated ...

So yes, that's the idea, and the tools are there for a simple implementation (done in May, rebased now for comparison):
https://github.com/vyos/vyos-1x/compare/current...jestabro:example-property-secret

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

The first three PRs above have been merged, and the next in sequence (https://github.com/vyos/libvyosconfig/pull/21) opened for review.

T6899 merged; when rolling available, kindly retest. Thanks !

This will be squashed with https://vyos.dev/T6326 for backport to Circinus, after confirmation.

This will need the fix in https://vyos.dev/T6899 for backport to Circinus.

Thanks @gadams , and yes that was also mentioned in the forum discussion here:
https://forum.vyos.io/t/vyos-sometimes-does-not-start-properly/15486
I believe the correction made in the PR for the parent task T6899 should help reveal/resolve the issue.

The PR for the parent task:
https://vyos.dev/T6899
will avoid obscuring underlying errors. Revisit after merge of above.

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

As covered in last comment, all matters have been addressed, but for (then) open question re firewall migration. If that recurs, or still present, we will open a specific task.

As discussed a workaround is available, and preferable to the danger over usefulness of backporting to 1.3.x.

Adding that the long standing issue in T6543 is being addressed in the work of T6718, which provides a replacement to legacy loadConfig; the legacy code will not be corrected.

The only piece remaining here is a backport for Equuleus.

The specific high priority issue here was addressed in T6131; the general question of support for ZeroTier is in T6455. Closing this task as stated.

This will have a simple solution as a corollary of the work T6718: put on hold for now, pending restatement in terms of that work.

PR:
https://github.com/vyos/vyos-build/pull/836

Clarification: this was in fact a consequence of the cleanup here:
https://github.com/vyos/vyos-build/commit/d50707bb295dbd4bc50e3d0301fc8be605448429
not the cleanup of deprecated packages, consequently, the solution is simpler: simply revert the above. As previously mentioned, although this is not used by new installs, the file is expected to exist in a new image, when doing a compatibility-mode update from a system with legacy image tools. If the legacy images are subsequently removed from the system, the new image tools will switch out of compatibility mode, at which point the file is no longer needed.

This has a simple solution, and was an artifact of the much welcomed retirement of the packages vyatta-cfg-system and vyatta-op (T6527). One missing file is needed from the retired packages: since the legacy update tools look for a small number of scripts in the mounted image of the new image, a few need to be available for legacy compatibility. PR in preparation.

@syncer I do not think this is worthwhile/advisable to backport changes for 1.3.x, given that there is an easy workaround.

Mechanism for adding kernel boot parameters in T5979/T5980

Reassigned to @natali-rs1985 ; please ask if any questions.

@syncer yes, thanks.

The only piece missing from the original design of using GraphQL to implement templated high level configurations is: migration of templates, versioned by component version; the recent addition of the convertor of set commands to config trees (T6740) makes this a simpler problem. I will revisit and implement migration of templated configurations.

Yes for Circinus; I think not advisable for Sagitta, but let us ask @dmbaturin for opinion.

PR list below; after the first two are reviewed/merged, the others can be moved out of draft, in order of dependencies.
https://github.com/vyos/vyconf/pull/11
https://github.com/vyos/vyos1x-config/pull/31
https://github.com/vyos/vyatta-cfg/pull/94
https://github.com/vyos/libvyosconfig/pull/21
https://github.com/vyos/vyos-build/pull/824
https://github.com/vyos/vyos-1x/pull/4176
https://github.com/vyos/vyatta-cfg/pull/95

Updated repos below; one minor change needed for replacements to my_set/my_delete before PR:

PR for current/Circinus/Sagitta:
https://github.com/vyos/vyos-http-api-tools/pull/19

Vyconfd running all validators in links above; integration with T6717 remaining to complete before PR.

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

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

@doctorpangloss I see from the other forum thread:
https://forum.vyos.io/t/something-keeps-adding-offloads-back-to-my-interface-breaking-my-wan/15282/7
that @n.fort has confirmed the persistence of the fix.

PR to follow tests and migration script:
https://github.com/vyos/vyos-1x/compare/current...jestabro:distinct-api

PR ready for review:
https://github.com/vyos/vyos-1x/pull/3876