Output for a standard check with section ['nat'] and for the test case above, with debug logging on; changes are correctly mirrored on secondary node:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 23 2024
Mar 22 2024
Note that the subtask T6146 is useful in itself, as a modernization of the legacy tool priority.pl, but manual ordering of config-sync sections to address this issue is fragile, given the subtleties (== design constraints) of the legacy commit algorithm (cf. T5492). It is preferable to hand the full commit proposal of the primary node to the secondary node, and allow the underlying configsession to manage priority ordering --- this may be easy to do with a simple refactor in the post-commit hook and (if needed) adjustment in the http-api request handler.
Mar 21 2024
Comparison with legacy priority.pl can be seen with priority.py --legacy-format, below; note that priority of 0 is default for interface-definitions lacking a priority element, as is assigned in legacy commit algorithm.
PR for subtask bug merged:
https://github.com/vyos/vyos1x-config/pull/24
PR for this task will follow the update/rebuild of libvyosconfig.
Mar 20 2024
Mar 19 2024
The fix for values containing single backslashes has been merged for 1.5 in
https://github.com/vyos/vyos1x-config/pull/23
https://github.com/vyos/vyos-1x/pull/3035
As discussed, this will wait before being backported to 1.4.
Mar 18 2024
Fix to docs pending:
https://github.com/vyos/vyos-documentation/pull/1331
Well that is a fault of the docs; I will add now. Thanks !
curl -k -X POST -Fkey=baz -Fdata='{"op": "exists", "path": ["service","no","such","subpath"]}' https://192.168.122.238/retrieve|jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 340 100 47 100 293 547 3414 --:--:-- --:--:-- --:--:-- 4000 { "success": true, "data": false, "error": null }
@penetal does the operation 'exists' not suffice for your needs ?
Mar 14 2024
Mar 11 2024
Mar 9 2024
Mar 8 2024
Mar 7 2024
@penetal please confirm that this is resolved.
Resolved in my tests using above reproducer; waiting for confirmation from submitter.
Mar 6 2024
This will be resolved after merging the PR for T6104.
Mar 5 2024
Revised PR:
https://github.com/vyos/vyos-1x/pull/3089
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.
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.
Mar 4 2024
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.
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
Mar 1 2024
Feb 29 2024
The configuration checks are the 'verify' stage of the respective config mode script; general structure here:
https://docs.vyos.io/en/sagitta/contributing/development.html#configuration-script-structure-and-behaviour
What is the content of
/tmp/vyos-configd-script-stdout ?
I raised this issue for discussion last week, and am testing more 'lenient' verification in cases such as above; I'll add results and plans here, as available.
Feb 28 2024
PR for global solution extends the local solution in T5839:
https://github.com/vyos/vyos-1x/pull/2659
PR
https://github.com/vyos/vyos-1x/pull/2659
updated and extended for T5660.
Feb 27 2024
Yes, this is only used by the GraphQL API.
Feb 26 2024
Cf. the details leading to having changed this for config_op:
https://vyos.dev/T5305
Feb 20 2024
After normalization of PR (compare with examples from T5939)
Feb 18 2024
Forum user reports that this is resolved.
Feb 17 2024
Feb 16 2024
Simple fix here; PR pending following tests.
https://github.com/jestabro/vyos-1x/tree/pxe-boot
Feb 15 2024
This will follow from the solutions in subtask T6006.