Containerlab Linux node: ssh access

[sdktr]

Does anyone have a working config for specifying SSH as the mgmt interface for a Linux node (docker image) with clab provider?

If I understand the logic correctly, the access method is derived by the ansible_connection or netlab_console_connection, but both these settings don't seem allowed node or group attributes.

[ipspace]

You can use custom group Ansible variables -- it seems the order of groups in inventory.yml ensures the custom group variables overwrite device-specific groups. For example:

provider: clab

groups:
  linux_ssh:
    members: [ h ]
    vars:
      ansible_connection: ssh

nodes:
  h:
    device: linux

FWIW, make sure you're using containers that include a preconfigured SSH server.

[sdktr]

I'm assuming the netlab connect command should follow the connection method specified here? In that case it didn't work out for me using:

plugin: [multilab]

defaults:
  multilab.id: 7
  device: linux


groups:
  linux_ssh:
    members: [ x1 ]
    vars:
      ansible_connection: ssh

nodes:
  - name: x1

<snip>
~/netlab/lab7-linux$ netlab connect x1 -v
Executing: ['docker', 'exec', '-it', 'clab-ml_7-x1', 'sh', '-il']
x1:~# 

[sdktr]

So, in the source for netlab connect cli here it can be found that the CLI tool does a lookup to the inventory data using the snapshot

This snapshot is the only place that contains the wrong data:

    linux:
      clab:
        group_vars:
          ansible_connection: docker

In the Ansible host and group vars the value is overwritten. So my assumption is that if ansible were to interact with this node, it will use SSH.

Edit: validated ansible view of the inventory:

~/netlab/lab7-linux$ ansible-inventory --list | jq ._meta.hostvars.x1.ansible_connection
"ssh"

vs the netlab.snapshot.yaml view of the inventory:

cat netlab.snapshot.yml | yq .defaults.devices.linux.clab.group_vars.ansible_connection
"docker"

[ipspace]

However, if you use clab as a secondary provider, your life becomes more interesting. In that case, you can make the change for all Linux containers in a lab (change defaults.devices.linux.clab.group_vars.ansible_connection to ssh), but not for a single Linux container.

We have to put provider/device-specific group variables (like ansible_connection for Linux containers) directly into hosts to avoid the provider/device cartesian product mess we'd have to deal with otherwise (the same lab could have Linux containers and VMs), and that makes it impossible to overwrite them with any group variable. See https://github.com/ipspace/netlab/blob/dev/netsim/outputs/ansible.py#L45 for details.

[ipspace]

OK, I give up ;) I see no other way but to fully evaluate the group_vars and store them in the snapshot file. Additionally, we should allow ansible_ and netlab_ parameters in node data with no further checks (admittedly giving people all the rope they need to hand themselves, but that's par for the course for nerd knobs ;)

[ipspace]

Opened #1009 and #1010.

[ipspace]

Fixed the easy part that now allows you to specify ansible_connection in node data, which should be good enough to get you going.

[sdktr]

Hi @ipspace thanks a lot for a quick fix. Can you elaborate what the intended behavior is for the different output methods? We now eject a snapshot 'in parallel' with an ansible inventory. But ansible interprets this inventory in it's own way.
Will we try to mimic the reading behavior? Shouldn't there be one interface for reading host vars (maybe use some form of ansible API if that's possible) for all things involved with runtime netlab state?

just brain-flushing here..

[ipspace]

The only time (that I can see) where there's a disconnect between what Ansible sees and what netlab sees is when netlab tries to reconstruct what Ansible would do with the group variables -- netlab connect and netlab inspect --node commands. I will fix that in #1010. I should also document that vars parameter in groups should not be used unless absolutely necessary.

The only reason netlab supports Ansible group variables in custom groups is because someone might want to add parameters (used in custom templates) without defining them as netlab attributes (leftover from the days when defining new attributes wasn't as easy as it is now).