Feature: interactive exec

[pimvanpelt]

On a machine with many containerlab instances (for example, as used in trainings or workshops), the container names can become quite long, in order to be globally unique in Docker. When multiple vendors are used, lab users constantly have to remember which containers can be SSH'd to and with which username:password, and which do not offer SSH and need to be connected via TTY.

I propose a simple tool called dc (which stands for docker-connect) which lists available containers, optionally filtered by --topo and --name flags, and allows the user to shorthand with a container-name sub-string, to invoke docker exec with the most appropriate shell given a container name.

Example:

pim@summer:~/src/zanog26-containerlab-workshop/afternoon/server$ clab tools dc
12:21:31 INFO Parsing & checking topology file=srv.clab.yml
available containers:
  zanog-srv-vpp1 (git.ipng.ch/ipng/vpp-containerlab:latest-amd64)
  zanog-srv-vpp2 (git.ipng.ch/ipng/vpp-containerlab:latest-amd64)
  zanog-srv-web (git.ipng.ch/ipng/clab-webserver:latest)

pim@summer:~/src/zanog26-containerlab-workshop/afternoon/server$ clab tools dc vpp
12:24:17 INFO Parsing & checking topology file=srv.clab.yml
ambiguous argument, matched more than one container:
  zanog-srv-vpp2 (git.ipng.ch/ipng/vpp-containerlab:latest-amd64)
  zanog-srv-vpp1 (git.ipng.ch/ipng/vpp-containerlab:latest-amd64)
          
   ERROR  
          
  Ambiguous container name "vpp".                                                                                     

pim@summer:~/src/zanog26-containerlab-workshop/afternoon/server$ clab tools dc vpp1
12:24:19 INFO Parsing & checking topology file=srv.clab.yml
root@vpp1:/# 

The 'most appropriate shell' is configured by matching the container's image-name. It can be overridden by the --shell flag.

Compare:

pim@summer:~/src/zanog26-containerlab-workshop/afternoon/server$ clab tools dc vpp1
12:24:19 INFO Parsing & checking topology file=srv.clab.yml
root@vpp1:/# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
loop0            UP             10.0.0.1/32 2001:db8::1/128 fe80::dcad:ff:fe00:0/64 
eth1             UNKNOWN        192.0.2.254/24 2001:db8:8298::fe/64 fe80::a8c1:abff:fe60:ec0d/64 
eth2             UNKNOWN        10.0.0.16/31 2001:db8:0:1::1/64 fe80::a8c1:abff:fe5e:2bb8/64 

With:

pim@summer:~/src/zanog26-containerlab-workshop/afternoon/server$ clab tools dc vpp1 --shell /bin/bash
12:25:59 INFO Parsing & checking topology file=srv.clab.yml
root@vpp1:/# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
eth0@if4352      UP             172.20.0.4/22 3ff1:172:20::4/64 fe80::b0ad:43ff:fea2:cef1/64 
eth1@if4349      UP             fe80::a8c1:abff:fe60:ec0d/64 
eth2@if4356      UP             fe80::a8c1:abff:fe5e:2bb8/64 

The first one executes the 'default' shell which is nsenter --net=/run/netns/dataplane /bin/bash while the second one executes a custom shell which drops into the default network namespace.

[sacckth]

why not using the existing exec or enhancing the functionality of. IMO the word "dc" can cause some ambiguity.

[pimvanpelt]

Can absolutely extend exec with some form of flag other than --cmd, perhaps -i/--interactive to show the difference between single-shot execution (current behavior) and interactive execution, paired with a-s/--shell that might default to the map in shellDefaults. I think I can do that without any functional changes to the base case (-i not given).

[sacckth]

yeah, something resembling docker exec -it or kubectl exec (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...]

[pimvanpelt]

Take a look at 0dbe1bb which extends exec with an -i/--interactive flag, mutually exclusive with --cmd

New offer:

pim@summer:~$ clab exec --interactive 
ambiguous match; narrow with a more specific name, --label, or --topo:
  zanog-srv-vpp2 (git.ipng.ch/ipng/vpp-containerlab:stable)
  zanog-srv-vpp1 (git.ipng.ch/ipng/vpp-containerlab:stable)
  zanog-srv-web (git.ipng.ch/ipng/clab-webserver:latest)
          
   ERROR  
          
  Interactive exec requires exactly one container, got 3.                                                             

pim@summer:~$ clab exec --interactive vpp1
root@vpp1:/# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
loop0            UP             10.0.0.1/32 2001:db8::1/128 fe80::dcad:ff:fe00:0/64 
eth1             UNKNOWN        192.0.2.254/24 2001:db8:8298::fe/64 fe80::a8c1:abff:fee4:b990/64 
eth2             UNKNOWN        10.0.0.16/31 2001:db8:0:1::1/64 fe80::a8c1:abff:fec7:bff6/64 

[sacckth]

Thoughts @hellt ?

[pimvanpelt]

Looking at comment in PR #3156 I am asked to consider moving this into the Node interface and configuring it in nodes/*/*.go rather than centrally. Take a look at 2b5bb90

This is obviousely kind dependent... so make it a field in the kind implementation (and default kind) and expose it via a getter function... don't start all over again with polluting the code in every corner with kind specifics.

@steiler I do not agree it is kind-dependent, the shell to run is an attribute of the image. For example linux as kind can and will take any number of images, eg alpine (/bin/sh) or multitool (/bin/bash) or ubuntu. But on the other hand, users will not be editing the Golang code to add image:shell mapping as a matter of course, so I think putting it where you suggest makes sense. And you are right to point out that keeping the config centrally will create clutter in exec.go

One other drawback of the original (image-dependent) solution: if the image gets refreshed while the lab is running, :latest or :stable will point to another hash, the original running container will revert from its symbolic name to a sha256 hash, and the shell resolution will break.

One other drawback of the proposed alternate (kind-dependent) solution: a topo file is now required, as just listing containers from docker/podman will not reveal the kind, while it will reveal the imagename.

I can go either way on this

[steiler]

I do agree that for e.g. the linux kind it is not clear which shell to use, but also there you can try bash first and if it fails use sh.
which would probably anyways already be defined in the default_node. But nodes like srl would overwrite their default cli as sr_cli.
Users might even pull vrnetlab images from different (maybe internally hosted) container registries, so the pattern matching of image names would fail.
If you ask me, generally thats a kind based attribute with some degree of blurryness, that can be accounted for.

[pimvanpelt]

It occured to me that if we take the kind-dependent approach, that we can also add an attribute to the YAML to specify the alternate shell, along the lines of:

  nodes:
    web:
      kind: linux
      image: git.ipng.ch/ipng/clab-webserver:latest
      shell: /bin/bash -l

So linux kind's default may be /bin/sh but users would not have to jump through hoops to override it for their custom images either. How does that sound? It would look like this: 93e7fa9

[steiler]

being able to specifically define the shell in the topo is a good idea... but could also be missleading ... this is the interactive shell command... correct?!

[hellt]

Hi all,
A couple of thoughts

1. this is a minor "nice to have" feature, something that core clab shouldn't be concerned with much.
2. with 1) in mind I would propose to use either an env var or node.extras field to encode the desired shell if a user wants to provide one
3. indeed I would imagine the interactive mode is the one that users would probably want to have out-of-the-box, but then I'd up it a notch and use a TUI selector from charm.land. I.e. the list of nodes is presented with the search bar on top to filter the nodes interactively