where the containerlab can running? dind(docker in docker) or kubernetes pod?

[BurlyLuo]

When use the bridge to link the different nodes, we can see that we need care the interface which lying down at the ROOT namespace. we must keep the different interface name in the ROOT namespace. it will make much time and can't avoid conflicts. Due to this i think use a isolated environments to use the clab.

1. Docker in Docker(dind)
   we can run the topo into a docker container rather than the local host. ubuntu-dind

2. A dind pod at the kubernetes cluster
   At the kubernetes cluster, we can create many pods to init a environments. It's going to be a very nice experience

what's your ideas? I'd love to hear from you!

[hellt]

I think if the only issue is with the manual interface naming, then it might be an overkill to put clab in its own container.

When you define links that connect to a bridge you can simply prepend them with a bridge name, for example

    # note, that the bridge br-clab must be created manually
    br-one:
      kind: bridge
    br-two:
      kind: bridge

  links:
    - endpoints: ["srl1:e1-1", "br-clab:br1-eth1"]
    - endpoints: ["srl2:e1-1", "br-clab:br1-eth2"]
    - endpoints: ["srl3:e1-1", "br-clab:br1-eth3"]

    - endpoints: ["srl1:e1-2", "br-clab:br2-eth1"]
    - endpoints: ["srl2:e1-2", "br-clab:br2-eth2"]
    - endpoints: ["srl3:e1-2", "br-clab:br2-eth3"]

since you anyhow need to define the endpoint name that connects to the bridge why prefixing links name with some bridge-related value is a problem?

Maybe what will be a nice to have is a special flag that will prefix bridge-attached interfaces automatically, so that users won't have to

[BurlyLuo]

Maybe what will be a nice to have is a special flag that will prefix bridge-attached interfaces automatically, so that users won't have to>

yes, that's a good idea to deal the conflict.! Like: project_name-ethX
And the docs should tell the user format of the interface name.