Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace multiple netX_ipv{4,6} params with single net_ipv{4,6} #394

Open
enhaut opened this issue Jan 27, 2025 · 1 comment
Open

Replace multiple netX_ipv{4,6} params with single net_ipv{4,6} #394

enhaut opened this issue Jan 27, 2025 · 1 comment

Comments

@enhaut
Copy link
Member

enhaut commented Jan 27, 2025

Is there any particular reason for how multiple networks are passed to recipe by separated netX_ipv{4,6} parameters instead of letting LNST to split a larger network into multiple smaller ones based on recipe requirements? I think providing a single larger network to LNST and let it do the subnetting instead of user is a better approach.

Python's ipaddress library implements subnetting - https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv4Network.subnets

However, since LNST doesn't use python's ipaddress module, this would require either to refactor LNST's ip addresses machinery to use python's ipaddress or to reimplement .subnets() in LNST.

With that, I think recipes could simply have a count of required networks defined, LNST will split it into networks and provides it to recipe.

@olichtne
Copy link
Collaborator

This is only the case for a couple recipes AFAIK, e.g. vlan recipes: https://github.com/LNST-project/lnst/blob/master/lnst/Recipes/ENRT/VlansRecipe.py

From what I can remember the reason for this is that this allows you to be EXPLICIT in how you want your network to look like instead of relying on an algorithm to do this for you. This is a bit more flexible in case you don't have a large enough network available that the algorithm would be able to split (e.g. you have 3 smaller networks that can't be joined into a single larger continuous network, e.g. 192.168.1.0/24 and 10.10.1.0/24... for some reason).

Having an automated subnetting would probably make the configuration parameters a bit shorter sure, but at the same time we don't set these manually and we expect these to be generated by some job generator anyway so i'm not sure that this would save much work...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants