Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

I think you need to sign the CLA.

I don't think skipping the firewall checking is the best solution to the described issue. In particular, the firewall rule is still required, so if it is missing the attempts to connect to the created instance will fail.

Instead, I would suggest making the existing check work when the network is in another project.

That could be done by getting the project name for the expected firewall from the self link of the network, and then using that in the nested gcloud calls to ensure the firewall rule exists.

I think you need to sign the CLA.

Hi @yebrahim
I'm submitting this on behalf of the company I work for. The person in charge to review and submit the CLA is currently still away. Will let you know when CLA is submitted. Thanks.

Hi @yebrahim. CLA submitted.

Hi @3thanZ, I think you might need to reply here saying "I signed it." just like the bot suggests above (not sure what the bot looks for in your comment exactly).

I signed it!

@3thanZ I think it's safer to follow @ojarjur's suggestion. Skipping the check and relying on the user to make sure it's been created correctly can easily lead to obscure bugs. I'd rather we generalize the check and creation code path.

Hi @yebrahim
How would the firewall rule check be helpful in organisations where those who are creating Datalab instances have no permissions to list or create firewall rules? Users in these organisations will be blocked from creating Datalab instances.

@3thanZ Here's my take on the overall user experience:

Even if a user does not have permission to create firewall rules, the check is still valuable as it will prevent them from accidentally creating an instance which is unusable, and it will present an error message to them saying what they need to do to fix the issue (i.e. have a network administrator add the firewall rule).

If the user does not have permission to even list firewall rules, then I think that would be a setup that we should not support, and instead the organization needs to give the firewall-listing permission out to anyone who needs to create Datalab instances. Otherwise, we would have the situation where the user creating a Datalab instance has no way of knowing whether or not the instance is actually usable, and if it is not usable, they would have no way of debugging the issue.

If giving permission to list firewall rules to a Datalab user is an issue, that organization can still proceed by having an administrator create the Datalab instance on the user's behalf by passing in the --for-user flag.

Just added Issue #2126 related to this. I think there is value in this flag. It doesn't make sense to create a firewall rule when there isn't any intention for external access.

Closing this since #2135 was merged