Pull request with a fix: https://github.com/vyos/vyos-1x/pull/171

The above PR gets rid of the exception during commit.

A quick way to test (if you can manually configure networking):
curl https://raw.githubusercontent.com/varesa/vyos-1x/093e9468ded8399185dacde0a4f9b8fd4fbd9c18/src/conf_mode/interfaces-ethernet.py | sudo tee /usr/libexec/vyos/conf_mode/interfaces-ethernet.py

However we found out that even if the commit succeeds an address doesn't get set. Not sure if that's related or not

The original error for reference:

vyos@vyos# commit
[ interfaces ethernet eth0 ]
Traceback (most recent call last):
  File "/usr/libexec/vyos/conf_mode/interfaces-ethernet.py", line 447, in <module>
    c = get_config()
  File "/usr/libexec/vyos/conf_mode/interfaces-ethernet.py", line 134, in get_config
    if not conf.exists(cfg_base):
  File "/usr/lib/python3/dist-packages/vyos/config.py", line 200, in exists
    path = re.split(r'\s*', path)
  File "/usr/lib/python3.4/re.py", line 196, in split
    return _compile(pattern, flags).split(string, maxsplit)
TypeError: expected string or buffer

[[interfaces ethernet eth0]] failed
Commit failed

Regardin the interface not being configured:

# check if ethernet interface has been removed
cfg_base = 'interfaces ethernet ' + eth['intf']
if not conf.exists(cfg_base):
    assert False  # this gets hit

in config.py self._session_config.return_value(['interfaces', 'ethernet']) gets called and throws ConfigTreeError

in configtree.py the function return_value from /usr/lib/libvyosconfig.so.0 gets called with some integer and 'interfaces ethernet'. It returns 'null'

The ConfigTree gets created with config_string:

"""
address 192.168.46.189/24
address 192.168.46.188/24
description "Hello world"
hw-id 52:54:00:3f:49:25
"""

It has no mention of the path interface ethernet

I just noticed that the contents of that config look awfully lot like the config node ([edit interfaces ethernet eth0]) I was at.

The exception (which is catched and causes the interface to be deleted) is:
vyos.configtree.ConfigTreeError: Path [b'interfaces ethernet'] doesn't exist

If I go to the top level of the config, I get a different exception at my "breakpoint":
vyos.configtree.ConfigTreeError: Path [b'interfaces ethernet eth0 dhcp-options'] doesn't exist

Indeed there are no dhcp-options configured. Also now the ConfigTree(config_string=<here>) contains the whole config. It seems that the configuration is evaluated in the edit-context of the shell

Okay, it seems that the major issue here is caused by commit d9ee0b95d1020b6d5412dd011ebb1ef7f6ef3fc7 / [vyos.config] T1758: use vyos.configtree for reading values, instead of calling cli-shell-api.

And if the node exists, it'll never hit the else-clause in Config.exists() which contains the string splitting which throws the originally reported exception when passed the array

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

If your node exists, you won't see that issue, only if it doesn't. The above PR should fix that, but I have requested a review from @dmbaturin to make sure I don't introduce something into it he doesn't want there.

@hagbard That however doesn't fix the issue where the entire config session seems to be invalid if you are not at the top level. After T1758 (commit above) the ConfigTree for session_config only contains nodes under the [edit <node>] level, not the whole config.

This causes pretty much any commit to fail since the different modules expect to be able to use full paths (like interfaces ethernet ...) instead of suddenly the config root containing just 'address', 'hw-id' and 'description'.

That is caused by: session_config_text = self._run([self._cli_shell_api, '--show-working-only', '--show-show-defaults', 'showConfig'])

[edit interfaces ethernet eth0]
vyos@vyos# /bin/cli-shell-api --show-working-only --show-show-defaults showConfig
address 10.0.0.1/24
hw-id 52:54:00:3f:49:25

Opened a separate task about the incorrect behaviour with the edit-level: T1846

A version of @hagbard 's fix has been committed as eced4a49c67d2e0e3e131193afe679aee0c5c679; the incorrect behaviour with the edit level has been fixed and referenced in that task (T1846).