Change Details

There is an amusing but undesirable circle of interactions between several of our standard tools, in their respective approaches to minimizing the remaining legacy data structures. The details will emerge below, but the analysis and actionable items are the following: (1) this was revealed by a recent analysis of the bug coincidentally reported in T6638; it had been triggered in debugging the PR for T6633 (for which the PR was pulled back to draft). --- this is //not// the root cause of T6638, but its behavior under T6633 revealed this collection of issues, and provides some information useful for T6638, namely, --- //recommendation:// (at the discretion of the developer working on T6638) the function `verify_interface_exists` should take a `config` argument, analogous to the other functions in `configverify.py`; in practice, this arg refers to the config_dict of the working. Using `ConfigTreeQuery` will not return the working config under configd currently, and invites a problem when `utils/configfs` is involved: (2) injecting the environment vars needed for the `configfs` utils into the `configd` context has the following side effect: a check of whether we are in a config session will now return True. This contradicts the separation of concerns that is the basis for configd. --- the problem is mooted if never acted upon: the recommendation above to drop `ConfigTreeQuery` in the verify function will resolve that immediate problem; no explicit use of `configsession.py` is in `configd` (by design). --- //subtask:// any wrapper to the `cli-shell-api`check `inSession` should return False if running under `configd`. (3) `ConfigTreeQuery` should not be included explicitly in config mode scripts, nor is it currently. However, any implicit inclusions (beyond the one mentioned above) need to be checked: `vyos/ifconfig/vrrp.py`, for example. --- //subtask:// check necessity of class for `ifconfig/vrrp.py`; most likely this is not the correct approach for reading the configuration in that case.

There is an amusing but undesirable circle of interactions between several of our standard tools, in their respective approaches to minimizing the remaining legacy data structures. The details will emerge below, but the analysis and actionable items are the following: (1) this was revealed by a recent analysis of the bug coincidentally reported in T6638; it had been triggered in debugging the PR for T6633 (for which the PR was pulled back to draft). --- this is //not// the root cause of T6638, but its behavior under T6633 revealed this collection of issues, and provides some information useful for T6638, namely, --- //recommendation:// (at the discretion of the developer working on T6638) the function `verify_interface_exists` should take a `config` argument, analogous to the other functions in `configverify.py`; in practice, this arg refers to the config_dict of the working config. Using `ConfigTreeQuery` will not return the working config under configd currently, and invites a problem when `utils/configfs` is involved: (2) injecting the environment vars needed for the `configfs` utils into the `configd` context has the following side effect: a check of whether we are in a config session will now return True. This contradicts the separation of concerns that is the basis for configd. --- the problem is mooted if never acted upon: the recommendation above to drop `ConfigTreeQuery` in the verify function will resolve that immediate problem; no explicit use of `configsession.py` is in `configd` (by design). --- //subtask:// any wrapper to the `cli-shell-api`check `inSession` should return False if running under `configd`. (3) `ConfigTreeQuery` should not be included explicitly in config mode scripts, nor is it currently. However, any implicit inclusions (beyond the one mentioned above) need to be checked: `vyos/ifconfig/vrrp.py`, for example. --- //subtask:// check necessity of class for `ifconfig/vrrp.py`; most likely this is not the correct approach for reading the configuration in that case.

There is an amusing but undesirable circle of interactions between several of our standard tools, in their respective approaches to minimizing the remaining legacy data structures. The details will emerge below, but the analysis and actionable items are the following: (1) this was revealed by a recent analysis of the bug coincidentally reported in T6638; it had been triggered in debugging the PR for T6633 (for which the PR was pulled back to draft). --- this is //not// the root cause of T6638, but its behavior under T6633 revealed this collection of issues, and provides some information useful for T6638, namely, --- //recommendation:// (at the discretion of the developer working on T6638) the function `verify_interface_exists` should take a `config` argument, analogous to the other functions in `configverify.py`; in practice, this arg refers to the config_dict of the working config. Using `ConfigTreeQuery` will not return the working config under configd currently, and invites a problem when `utils/configfs` is involved: (2) injecting the environment vars needed for the `configfs` utils into the `configd` context has the following side effect: a check of whether we are in a config session will now return True. This contradicts the separation of concerns that is the basis for configd. --- the problem is mooted if never acted upon: the recommendation above to drop `ConfigTreeQuery` in the verify function will resolve that immediate problem; no explicit use of `configsession.py` is in `configd` (by design). --- //subtask:// any wrapper to the `cli-shell-api`check `inSession` should return False if running under `configd`. (3) `ConfigTreeQuery` should not be included explicitly in config mode scripts, nor is it currently. However, any implicit inclusions (beyond the one mentioned above) need to be checked: `vyos/ifconfig/vrrp.py`, for example. --- //subtask:// check necessity of class for `ifconfig/vrrp.py`; most likely this is not the correct approach for reading the configuration in that case.