At the request of @c-po, going to mention that this may have relevance to T2653 since the order of how interfaces are handled may be effected by this and/or the proposal here may make sense to change based on their work.

I use myself a "cleanup" function, imagine:

In T2674#69525, @jack9603301 wrote:

I wish you success in advance. Porting and compiling has always been a large-scale application project, which may take a lot of time. However, in addition to rewriting and porting related code to a more portable language, we can also try to transplant and cross build the existing old code first. Of course, this is only the first step. If possible, porting the code base has made it easier for the code base to be transplanted Meaningful.

As "ip" is an invalid key in "vif" (as its no VLAN number) it should not be part of the default dict I guess - same for vif_s

There are allready someone trying to make a guide for building vyos on arm and the pi3/4, i myself have made it work on the pi4 some time ago but did not save my work so i dont have all the steps to reproduce..

I wish you success in advance. Porting and compiling has always been a large-scale application project, which may take a lot of time. However, in addition to rewriting and porting related code to a more portable language, we can also try to transplant and cross build the existing old code first. Of course, this is only the first step. If possible, porting the code base has made it easier for the code base to be transplanted Meaningful.

Yes, I'm interested in actually helping on porting it as it would make my ER-X for one, a lot more fun and useful.

porting half of an operating system to a different architecture is far from easy. Right now VyOS still has a lot of the old Vyatta codebase in it. As we are more and more in the process of migrating this to a Python based codebase it will still take some time. To be fair I stater a project some time back to port VyOS on an EdgeROuterPro (https://github.com/c-po/vy-project) and at least "it booted" but I then switched my focus to VyOS first - so by migrating th ecodebase to our own vyos-1x based Python implementation it will become easier in the future to port it to other operating systems as there is less code, less packages to port.

@c-po When this problem occurred, I might be testing bridge. I didn't expect that my test would make the bridge enter the admin down state without any warning. Later, when I restart, I found that SNMP seemed to be normal. This problem can be temporarily switched to invalid. Please refer to T2673

As always, please provide your config and probably a way to reproducs.

EDIT 1: Removing comment after speaking with cpo, I apologize for the confusion

I found that this problem may be related to T2673

Please open a new ticket or move your comment to an appropriate ticket, this ticket is not discussing your consernes.

Also on delete:

Addressed by T2667.

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

The login banner was always user configurable, see https://docs.vyos.io/en/latest/system/user-management.html?highlight=banner#login-banner

This command doing not what you are expecting. It shows virtual VRRP interfaces running in RFC3768 compatibility mode. Add the rfc3768-compatibility option to a VRRP group and a new virtual interface should be listed in the output.
If you want to change this behavior, please describe how exactly.

A banner would be a good thing. At least you would be able to have some sort of legal message on your device. I would recommend no banner by default so users can add one.

Re-reading the entry, I am now unsure what you believe should be different.

Possible by backporting https://github.com/vyos/vyos-1x/pull/452 and https://github.com/vyos/vyatta-cfg-system/pull/125 though I think some code using Config would need to be modified - add .exists calls before each .return_value(s) - 1.3's vyos.config doesn't require them, 1.2's I think does.

Ok, nice. And how about 1.2? Is it possible to fix this with the 1.2.6 release?

Yes, I should parse the tagNode and insert them into the default data.

Okay, I will revise that: ... Consequently it returns None for nonsensical input and {} for non-existent paths ...

The reason to return the data indexed by a node name: leaf nodes; the data is not a dict. If one wants consistency, then data of a node is returned indexed. This function does one specific thing: return a sub-dictionary from a dictionary, so

This is already fixed in 1.3

Thank you for this explaining what is happening. I would indeed rather tag were used as keys.

Sorry, I may have made a mistake. I've confused the order. If there's a problem, I'll reopen it.

One compelling idea is to move the implementation of the path argument in get_config_dict out of show_config, and replace it with a function to get a sub dictionary from the full get_config_dict. An example implementation is below. This would not only normalize the result, independent of idiosyncrasies of the current backend, but also future proof the form for the switch to vyconf. Secondly, it would allow us to remove the dependency on show_config itself, since that call is already made at Config initialization. Thirdly, it would allow direct use for off-line config instances, namely those for testing and offload to daemon.

But you make an excellent point, @thomas-mangin ; it may be best to normalize that within config_dict itself, now that we have the xml processing available ...

Yes, so there is no way to know at parsing time (unless you have two elements or check the XML) that this is a multi-element. Something "computer-friendly" would generate:

test {
    something [one]
}

showConfig produces the following for multi-nodes:

The value vs list is not produced by showConfig, but rather due to matching in configtree. We'll let @dmbaturin consider if this is an issue or not, but I imagine a jinja macro could address the problem where it occurs in template generation.