Have 'netlab up' automatically install dependencies, if any

[jbemmel]

In topology-defaults, add an optional 'install' attribute for device types that require additional dependencies. In srlinux case, this would be 'grpc'

Then, upon netlab up for a topology containing such nodes, the required netlab install calls would be done automatically. Could be subject to a runtime flag (--auto-install)

[ipspace]

Nice thought, but no. Every network device has some additional dependencies. For example, you need paramiko (not bundled with Ansible) for SSH access and XML libraries for Junos.

Most of these dependencies are bundled in netlab install ansible. The only reason there's a separate installation script for Nokia products is because someone couldn't figure out how to upgrade the Nokia collection on Ansible Galaxy, and I won't add commands to install code straight from a GitHub repository into installation scripts.

Docker and Containerlab installations are bad enough, but then if you want those, I guess you're OK with "just run this Bash script downloaded from some random URL" approach.

[ipspace]

BTW, I'm guessing you need this to ship topologies to people with "underinstalled" environments. Would it help to have generic framework for external stuff that needs to run at "netlab up" and "netlab down"? For example, someone might want to start a network management daemon when starting the lab, and you could add "netlab install grpc" at the "netlab up".

[jbemmel]

I could use it here: https://github.com/jbemmel/peering-manager/tree/add-nokia-sros-support/docs/development/netlab

I'd like to be able to say "just install netlab and run 'netlab up'" - but it's more complicated than that. We could add a line to the topology, but then I'd need to remember to add that line every time

I get that we want to protect users from having to deal with auto-installed random software, but some users may appreciate the convenience of something like

netlab up --ask-to-install-dependencies

The problem with a generic framework would be that it would run every time - a 1-time flag (that can be omitted after the first run) automatically skips reinstalls.

The above flag would still request explicit permission: About to install [X], ok?

[ipspace]

I guessed the use case type ;)... but where would that end? In the ideal "let's demo a concept" case, one could say "but I want to install Ansible and Docker and Containerlab on netlab up", but how do we know that won't mess up the user environment (yeah, OK, he asked for it... but then some people also tried to take selfie with a wild elephant).

Then we get into "how do we know it's a supported environment" gotchas, not to mention "where should pip and ansible-galaxy install the dependencies"

In the end, I don't see the difference between:

• Use pip3 to install networklab
• Execute netlab install clab grpc
• Execute netlab up

and whatever it is you'd like to achieve. Also, your instructions are wrong as you're assuming they're running netlab from a local Git repository like you do.

[jbemmel]

The difference is that those dependencies are implied by the type of devices used in the topology. Taking an "Intent-Based Networking" approach to its logical conclusion, the installation of any missing dependencies should result from the user's command to deploy that specific topology. Separating them into 2 different commands breaks the correlation.

Academic? Yes. Open to discussion? Sure. But still...