inlets / inletsctl

Expected Behaviour

Copy and paste the command from the generated output should work

Current Behaviour

Running the command as it is output results in the following error:

$ inletsctl delete --provider gce --id "hungry-shaw4|us-central1-a|burtonr"
Using provider: gce
failed to get 'inlets-token' value.: flag accessed but not defined: inlets-token

This was the output generated by the create command:

Inlets OSS exit-node summary:
  IP: XXX.XXX.XXX.XXX
  Auth-token: someReallyLongTokenString

Command:
  export UPSTREAM=http://127.0.0.1:8000
  inlets client --remote "ws://XXX.XXX.XXX.XXX:8080" \
	--token "someReallyLongTokenString" \
	--upstream $UPSTREAM

To Delete:
  inletsctl delete --provider gce --id "hungry-shaw4|us-central1-a|burtonr"

Possible Solution

Update the generated command, or update the process to provide the proper functionality.
I did do a repo search in GitHub for the text "inlets-token" and was only able to find it referenced in the create.go file. Not sure why or how it's ending up being referenced in the delete command.

Steps to Reproduce (for bugs)

Run inletsctl create...
Copy the command under the text "To Delete:"
Paste the command into the terminal and execute

Context

Created an exit node on Google Cloud to test with. Now wanting to delete it, I cannot use the command provided, but instead need to log in to the GCP console

Your Environment

inlets version inlets --version

FYI: This should be updated to say inletsctl version

Version: 0.4.0
Git Commit: 26ec251

Docker/Kubernetes version docker version / kubectl version:
N/A
Operating System and version (e.g. Linux, Windows, MacOS):
Linux
Link to your project or a code example to reproduce issue:
N/A

I also found this with a DO exit node, downgrading to 0.3.9 release worked.

Looks like a regression

@adamjohnson01 @utsavanand2 please can you take a look into this?

I can't reproduce this, it might have been fixed in 0.4.1, please can you guys re-test? https://github.com/inlets/inletsctl/releases/tag/0.4.1

0.4.1 seems to work 👍

Updated to 0.4.1. The error in the original description is gone, but now there is a different error:

gcp is the .json file that contains the credentials

$ inletsctl delete --provider gce --id "determined-curran1|us-central1-a|burtonr"
Using provider: gce
give a value for --access-token-file or --access-token

$ inletsctl delete --provider gce --id "determined-curran1|us-central1-a|burtonr" -f gcp
Using provider: gce
Deleting host: determined-curran1|us-central1-a|burtonr from gce
could not delete the GCE instance: googleapi: got HTTP response code 404 with body: Not Found

I've personally tested Packet and DO recently and would suggest using those. You can also set up your own VMs the old fashioned way.

Let's see if @utsavanand2 can help with this issue, who wrote the code for GCE

@burtonr I'll take a look at this. I'm having issues with GCE, particularly with the firewall rules with Stackdriver logs stating that I do not have enough permissions. I would be really grateful if I can get some suggestions from you, since I guess you have a GCP account 😄

Hey @utsavanand2 Thanks for helping out. Yes, I use GCP for a lot of my personal projects.
For inletsctl, the service account, or credentials that you pass it, the account must have at least:

compute.firewalls.create
- There is no specific "compute.firewalls" permissions that I could find though, so I set it to Admin
serviceaccount user

I have an inlets service account that's set up as "compute admin" and "iam.serviceAccountUser". That worked for setting it all up, but having trouble getting the delete command to work. Compute Admin has enough permission to do everything. I'll go back and make that more specific once I get it all up and running properly

@burtonr If you see here, I am using the compute.Admin role, which has network admin rights too and the serviceaccount user role. But inlets-op seems to have trouble with creating the firewall rules for the inlets control port. Though this is a different topic but can be related, considering the merged PR was working completely fine for a couple of weeks, and suddenly broke. I'm afraid if this is another example of that issue.
I have read the godocs for the google cloud sdk and apparently it is created automatically with gRPC. I don't know if this a result of any inconsistent request formats that might have been updated in the upstream SDK but not in the vendor, but I'm not sure.
Thanks a lot for your input though.
I'll check and see if I can fix it by tomorrow

I see that the import for inlets is "google.golang.org/api/compute/v1"

Looking at the source repo, I see this section in the first paragraph of the readme:

If you're working with Google Cloud Platform APIs such as Datastore or Pub/Sub, consider using the Cloud Client Libraries for Go instead. These are the new and idiomatic Go libraries targeted specifically at Google Cloud Platform Services.

That said, it seems the imports should be updated to: "cloud.google.com/go" from the newer(?) repo here: google-cloud-go

@burtonr I saw that repo initially, but the new repo only had compute/metadata sub module. I may be wrong here though

Ah yes, I see that now. At a quick glance, it looks more complete, and official. Sadly, you are correct.

I also found this closed issue asking the same question: googleapis/google-cloud-go#1605

Basically saying: No, there is no official library for interacting with GCP Compute Engine...

In other words, it's quite possible the server side has changed, but the client library is behind 🤷‍♂

@alexellis, @burtonr and @utsavanand2 I know what the issue is and will raise a PR to fix it. The issue is here

inletsctl/pkg/provision/gce.go

Line 184 in 3f1c896

    
           _, err = p.gceProvisioner.Instances.Delete(request.ProjectID, request.Zone, instanceName).Do()

I introduced this when I added the delete by IP functionality, the problem is that the project-id from the instance name string is not being used.

Apologies, I did not test the normal delete functionality when I added the delete by ip functionality.

@alexellis , this can be closed as a dup of #39

/close

Why don't we set up Derek access for contributors to this repo? Can you help Adam?

@alexellis, sure. I can help.