Civo IP mismatch about inletsctl HOT 18 OPEN

I believe that Dinesh worked with @dirien and this is all resolved now.

from inletsctl.

Any thoughts @alejandrojnm / @kaihoffman?

from inletsctl.

Given it a month for people to reply, now trying another one of the team.. pinging @andyjeffries

Andy, is there any reason the public IP would report as "wrong" during the Civo cloud-init phase?

from inletsctl.

I believe it goes via a router's IP address, so that may not work. A guaranteed way of it working (at least until Kube100 Platform goes live) is to use OpenStack's metadata service:

curl http://169.254.169.254/2009-04-04/meta-data/public-ipv4

from inletsctl.

Out of interest, how do you get /etc/default/inlets-pro? Is that using the same check-up.amazonaws.com service?

from inletsctl.

It's generated here with a similar approach for both types of inlets. https://github.com/inlets/inletsctl/blob/master/pkg/provision/userdata.go

from inletsctl.

Hmmm, so either way it uses checkip.amazonaws.com? That's weird then that it changes; maybe it uses a router's IP up until the public IP is connected. The only thing I can think is to use the official meta-data service, but I'm not sure how you'd check for a failure first in order to try that, because the previous IPs seem to be valid.

from inletsctl.

I wondered if you run user-data in the traditional way, or whether it's run as part of the image/instance builder? When we spoke last year, I'd requested this feature and at the time I think it had to be implemented in a non-conventional way.

The alternative is a switch statement just for the Civo provider, that gets the IP and generates /etc/default/inlets-pro upon first boot.

from inletsctl.

Thanks again for taking a look at this.

from inletsctl.

The user-data is run during cloud-init, but we already use it to initialise the instance. So the way we handled this is to allow the users to specify a custom script (bash, etc) that is run as part of the cloud-init. The API and CLI support this. I don't know if that helps?

The switch statement could be for all OpenStack providers (although I don't know if you provide adaptors/plugins/etc for any others)?

from inletsctl.

@dirien just ran into this again.

@andyjeffries how would you recommend we obtain the instance IP for Civo?

from inletsctl.

https://opensource.com/article/18/5/how-find-ip-address-linux

from inletsctl.

curl ifconfig.me works nicely from that list I believe, returns just the IP address with no trailing newline.

from inletsctl.

The mechanism that we are using works well on all other providers, and isn't dissimilar to what you've shared. I think the issue is that the way cloud-init is run / built, means it runs on another machine than the actual host. Am I roughly right there?

During cloud-init build / phase -> the IP is wrong for the instance

During an SSH session after cloud-init -> the IP is correct

This was explained in the thread above.

from inletsctl.

Cloud-init is generated in our Operator, but run on the VM itself. The IP is known before the instance starts building. We could try to inject the public IP in to a standard file on the filesystem, however, it means if we move the IP to a different instance in the future, that file would be out of date. So I think this is the safest way to do it.

I don't know why it's not working for you...

I tried to look at https://github.com/inlets/inletsctl/blob/master/pkg/provision/userdata.go (to see how you're doing it, from the thread above) but it 404s.

OpenStack may be doing it differently though, my comments above only refer to the new CivoStack regions.

from inletsctl.

@andyjeffries -> https://github.com/inlets/inletsctl/blob/master/cmd/create.go#L540

Should show you the userdata aka cloud-init

from inletsctl.

Thank you @dirien . So if you run this on Civo, what IP address do you get at that point and could you leave the instance running (and let me know it's ID) and I'll try to debug what's happening.

from inletsctl.

I think we can close thos one.

from inletsctl.