Addressed in T2568.

This was an early experiment which contributed some ideas towards T2582; closed as superseded by that task.

Discussion updated in PR 513.
https://github.com/vyos/vyos-1x/pull/513

What is here:

This fix remains an open discussion with @zsdc and @Dmitry

This does not currently affect crux (perhaps it did at some point). The crux script logic precludes this bug; confirmed in testing.

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

Final tests before PR.

Current version linked below, as an example for further discussion. As these ideas have been circulating for a while, it is important to have examples to debunk/revise/reject. My guess is that one likely wants much less than this, and that @dmbaturin is quite right in his recent comment "we should not rely on diffs unless there's absolutely no other way to do it --- not just about computational expense, but also readability".

@thomas-mangin I'm convinced: for get_child_nodes and get_node, we'll return a dict of respective dicts:

Okay, I like that video already ...

@thomas-mangin Firstly, I needed to write this version before reasonably debating the pros/cons of various approaches --- the important idea developed is that the use of get_sub_dict, and ability to return the sub_dict under the diff'ed nodes will allow a fluid use in writing conf_mode scripts --- beyond that, I am not particularly attached to any details of implementation, yet.

@thomas-mangin and @runar I do like the enum idea, however, this would add boilerplate to the conf_mode scripts, which would quickly become annoying in practice ... rather, common workflow just wants the actionable data (added, deleted) _and_ the ability to then access values under the node in question. Consequently, I'm following @runar 's suggestion of returning a tuple, combined with the return_as_dict arg to allow access to sub-data.

One forgotten point: get_config_diff obtains the config_dicts at root level, so any movement within/between sub-sections are available, with set_level.

It is true that get_config_dict is slow, so it should only be called once (twice for diff) per session. Consequently, the work flow will be:

So, as far as useful helper functions, one certainly wants:
get_child_nodes_changed(... path)
get_value_changed(... path)

@runar in fact, that's all one wants in current use case: has the list of elements, directly _under_ the specified node, changed? For example, (1) change of values (2) added or removed tag node entries.

Yes, I'm expanding all paths under the specified path

Yes, I definitely prefer a return type of tuple ...

Regarding is_value_changed, I was thinking the other way around: get_value_changed returns None if no change, so is_value_changed would be redundant --- put good point: one may/will want both old and new values

I am entirely open to suggestions here; the underlying functions support any such forms. Note however, that we want to distinguish between new/deleted paths and changed values --- one could treat these all as a difference in path, but it will be more convenient for use if we make the distinction ...

Addressed by T2667.

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

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

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 ...

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.

Changing the api settings (for example: keys, port) will cause a disruptive reload of the http-api service; it will of course succeed, but the response for that set command will reflect the reloading. This is known, if misleading behaviour. I will lower this to normal priority, and consider if we can improve the error/success message.

@jjakob that is in fact what we are doing: for stability, some of the changes are necessarily incremental --- these are not new abstractions, but rather, refinements of the existing ones, which allow the separation of new code from legacy. We are avoiding any patching of the old backend, simply replacing with the structures which will allow a switch to vyconf, while improving performance and extension of the new code.

I agree @jjakob that we are still converging on the best way to structure the salient information, namely the difference between effective and session configs, however this will be internalized: a simple example of use for testing and daemon (and other) is:

I'm not sure that we have to go that far, but let me take a closer look, and we can discuss; the model is to be able to call, in batch, the functions of an arbitrary conf_mode script, without variation in structure or behaviour.

Only that it inherits from Config, hence the form of the Config instance can not be changed, say, to 'off-line' Config, or 'testing' Config, which would have different init functions; if it took Config as an argument instead, or a named argument with default the 'live' Config, then it would not be an issue for generalization. But we should discuss the details further, and collect results and suggestions.

1. commit restrictions/permissions have not changed; all handled in the backend.
2. The daemon can not load the configs, as it does not have/need access to the config session; that's the point.
3. ?
4. the conf_mode script needs to reference the global config; re-setting level is basic hygiene --- the script should ask itself 'what if I am called again?'
5. we want to eat the args in the node.def; so you already have it.