Integrating external tools

[ipspace]

I always wanted to use netlab to test external tools like SuzieQ. Graphite (currently implemented as an output module) would be in the same category.

In the ideal world, we'd have a framework that would generate tool configuration files from transformed lab topology, start the tool(s) at netlab up, and stop them at netlab down.

I documented a potential approach to that challenge in docs/roadmap/tools.md (also @ https://netsim-tools.readthedocs.io/en/dev/roadmap/tools.html). Comments would be highly appreciated (before I start coding the whole thing ;)

CC: @ddutt @ssasso @petercrocker @jbemmel

[ddutt]

Hi Ivan, First of all, thanks for doing this. One concern with non-docker instances would be the conflict in dependencies. If tool A wants version X of a library but netlab wants version Y of thst dsmr lib, then this would be very problematic. So, either simply support docker instances only OR provide support for generating the appropriate configs and its upto the user to use these separately, for example to startup the tool in a separate virtualenv. Thoughts? Dinesh

…

On Sun, Apr 9, 2023 at 2:38 AM Ivan Pepelnjak ***@***.***> wrote: I always wanted to use *netlab* to test external tools like SuzieQ. Graphite (currently implemented as an output module) would be in the same category. In the ideal world, we'd have a framework that would generate tool configuration files from transformed lab topology, start the tool(s) at *netlab up*, and stop them at *netlab down*. I documented a potential approach to that challenge in docs/roadmap/tools.md (also @ https://netsim-tools.readthedocs.io/en/dev/roadmap/tools.html). Comments would be highly appreciated (before I start coding the whole thing ;) CC: @ddutt <https://github.com/ddutt> @ssasso <https://github.com/ssasso> @petercrocker <https://github.com/petercrocker> @jbemmel <https://github.com/jbemmel> — Reply to this email directly, view it on GitHub <#770>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGIXE33DF2PW3YJDLN6F3TXAJ7RXANCNFSM6AAAAAAWYAEWMI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ipspace]

Good one, thank you!

• We could support virtual environments in tool configurations (it looks like a virtual environment is nothing more than setting PATH and VIRTUAL_ENV environment variables)
• We should have a manual runtime method that creates the configuration files but skips the tool startup/shutdown.

[ddutt]

Both sound like valid options to me, thank you. I presume that the env vars will be set to run only within the tool startup script context and not outside to ensure that erroneous runs don't result in a confused state for the user where netlab commands start to fail due to missed up PATH and VIRTUAL_ENV vars Dinesh

…

On Sun, Apr 9, 2023 at 11:31 PM Ivan Pepelnjak ***@***.***> wrote: Good one, thank you! - We could support virtual environments in tool configurations (it looks like a virtual environment is nothing more than setting PATH and VIRTUAL_ENV environment variables) - We should have a manual runtime method that creates the configuration files but skips the tool startup/shutdown. — Reply to this email directly, view it on GitHub <#770 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGIXE4MAMDGWDIENVHMFYDXAOSKJANCNFSM6AAAAAAWYAEWMI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ipspace]

presume that the env vars will be set to run only within the tool startup script context

Absolutely.