Add argument to bypass firewall rule creation during when creating Datalab instance

3thanZ commented 5 years ago

The --network-name and --subnet-name allows for an instance to be created in a shared VPC network from a different host project. However, the firewall rule checks and creation will fail. Therefore, an argument to skip the firewall rule check and creation would enable the datalab create command to succeed.

googlebot commented 5 years ago

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).

:memo: 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.

yebrahim commented 5 years ago

I think you need to sign the CLA.

ojarjur commented 5 years ago

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.

3thanZ commented 5 years ago

Hi @ojarjur . That is a good suggestion. I think that allowing the user to bypass firewall rule creation is still a useful option. Enterprises normally allow users to create compute instances, but reserve firewall rule creations for the network team.

I will submit a different PR for the firewall rule on host VPC.

3thanZ commented 5 years ago

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.

3thanZ commented 5 years ago

Hi @yebrahim. CLA submitted.

yebrahim commented 5 years ago

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).

3thanZ commented 5 years ago

I signed it!

yebrahim commented 5 years ago

@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.

3thanZ commented 5 years ago

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.

ojarjur commented 5 years ago

@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.

mdhedley commented 5 years ago

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.

rileyjbauer commented 5 years ago

Closing this since #2135 was merged

googledatalab / datalab