You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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...
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.subnetsHowever, 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.
The text was updated successfully, but these errors were encountered: