I think this is a reasonable change. Tagging @rileyjbauer and @ojarjur to take a look as well.

I totally understand that the current behavior is not right for an instance with no external IP.

I wonder if there are other potential usability issues that we might want to check for in place of the existing firewall rule... in particular, I wonder if the default setup (if the user uses the datalab-network network), will allow internal access to the VM.

@mdhedley have you seen a good user experience when trying out the combination of this rule and the --no-external-ip flag?

If so, were you using the datalab-network network or a different one? If you were using the datalab-network network, did you have any issues getting internal traffic to be permitted to your VMs?

Where I've seen this done the user had a VPN network connection from their on premises network to their datalab vpc which was not the datalab network. In that case there does need to be firewall configuration to allow port 22 from the on premises network to the network that datalab resides in.

A 0.0.0.0 port 22 rule would have worked, but also would have broken the users specific network requirements, where they were not authorized to open up ports to the internet at large.

I think my perfect world is a flag that disables firewall rule creation for complex environments that may or may not use public ip address. The flag was proposed in #2110 but met resistance over usability.

I proposed this as a compromise. I think it avoids the usability concerns as the standard config is kept intact. My impression is that in cases where ---no-public-ip is passed the network setup is complex enough that we can't guess the correct firewall rule. Falling back to not creating one at all seems like a better user experience than creating one that could potentially violate their network policy.

2134, and 2135 resolve the need for this.