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
To avoid conflicts with local docker networks, the code uses the subnets 172.33. upwards.
This IP-Ranges are public ip ranges. The networks only exist locally on each host, but there may be a issue, when a spawned container wants to contact a service/ip/Packetresource which resides in the same created subnet. even though this case may not have a high probability, it theoretically can occur.
I would recommend to use another private subnet range, as specified by https://tools.ietf.org/html/rfc1918 Chapter 3. Since the 192.168.x ranges are often used in private networks, and only have a small subnet-possibility I would use a 10.x.x.x Net-Range
The text was updated successfully, but these errors were encountered:
The problem is that 10.x.x.x is often used for Kubernetes as default CIDR for services (kubeadm --service-cidr defaults to 10.96.0.0/12, Rancher RKE also uses similar ranges for cluster cidr). Ideally, not using fixed ip and relying on kubernetes as a scheduler would solve that.
To avoid conflicts with local docker networks, the code uses the subnets 172.33. upwards.
This IP-Ranges are public ip ranges. The networks only exist locally on each host, but there may be a issue, when a spawned container wants to contact a service/ip/Packetresource which resides in the same created subnet. even though this case may not have a high probability, it theoretically can occur.
ml-hub/resources/mlhubspawner/mlhubspawner/mlhubspawner.py
Lines 27 to 31 in 7644f35
I would recommend to use another private subnet range, as specified by https://tools.ietf.org/html/rfc1918 Chapter 3. Since the 192.168.x ranges are often used in private networks, and only have a small subnet-possibility I would use a 10.x.x.x Net-Range
The text was updated successfully, but these errors were encountered: