Issue 1368: fix to _base_provider.py to fix install on MacOS

[tsluyter]

See issue #1368 . Related to the fact that the ping test may not work on MacOS HyperKit. Better to make it a more reliable test for connectivity.

Thank you for making MicroK8s better

Please reference the issue this PR is fixing, or provide a description of the problem addressed.

Also verify you have:

• Read the contributions page.
• Submitted the CLA form, if you are a first time contributor.

[tsluyter]

Link needed to issue #1368

[joedborg]

Hey @tsluyter

Thank you for the PR! Can you please sign the CLA? https://github.com/ubuntu/microk8s/runs/4776381390?check_suite_focus=true

I'm also just wondering if we can get away with doing this implicitly for every install? Some corporate settings might block 8.8.8.8 or 1.1.1.1 and only allow their own DNS servers. Perhaps it should be something we fall back on or recommend to do if it fails?

Many thanks.

[tsluyter]

Can you please sign the CLA? https://github.com/ubuntu/microk8s/runs/4776381390?check_suite_focus=true

I'd love to, but I reckon I need to be re-added to the right community. I was added to CanonicalContributorAgreement by @SallyCoome seemingly at random last week, but without any instructions and with a dead silent group and no clear indications of who Sally was, I assumed it was phishing.

Please provide exact instructions and re-invite me if needed. :)

I'm also just wondering if we can get away with doing this implicitly for every install? Some corporate settings might block 8.8.8.8 or 1.1.1.1 and only allow their own DNS servers. Perhaps it should be something we fall back on or recommend to do if it fails?

I agree that the DNS config itself is a naive approach; you're right that it might not work everywhere.

But, this particular PR isn't concerned with that particular topic. This PR tries to solve one simple problem where the internet-connectivity test fails in certain situations. I'll gladly come back later to also think about the DNS setup itself.

[tsluyter]

I see the linter also fails on a line of code that I didn't write.

I've changed the file in my fork, now need to figure out how I can update this running PR to use the adjusted file.

EDIT: Ah, it seems to have picked up the change by itself. Nice.

[SallyCoome]

Hello Tess, You were not added 'at random', you were added because you signed the Contributor Agreement per this screenshot. You are then added to the group on GitHub. I have resent the invitation to the GitHub group. Kind regards, Sally [image: image.png]

…

On Fri, 14 Jan 2022 at 06:54, Tess Sluijter ***@***.***> wrote: Can you please sign the CLA? https://github.com/ubuntu/microk8s/runs/4776381390?check_suite_focus=true I'd love to, but I reckon I need to be re-added to the right community. I was added to CanonicalContributorAgreement by @SallyCoome <https://github.com/SallyCoome> seemingly at random last week, but without any instructions and with a dead silent group and no clear indications of who Sally was, I assumed it was phishing. Please provide exact instructions and re-invite me if needed. :) I'm also just wondering if we can get away with doing this implicitly for every install? Some corporate settings might block 8.8.8.8 or 1.1.1.1 and only allow their own DNS servers. Perhaps it should be something we fall back on or recommend to do if it fails? I agree that the DNS config itself is a naive approach; you're right that it might not work everywhere. But, this particular PR isn't concerned with *that* particular topic. This PR tries to solve one simple problem where the internet-connectivity test fails in certain situations. I'll gladly come back later to also think about the DNS setup itself. — Reply to this email directly, view it on GitHub <#2823 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASW3UKHJJKXODH3OHRYNZBLUV7CD7ANCNFSM5LQYYZAQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Sally Coome Director of Global Workspaces Canonical Group Ltd m: +44 7809 389868 e: ***@***.*** A culture is significantly determined by the worst behaviour it will tolerate.

[tsluyter]

Hello Tess, You were not added 'at random', you were added because you signed the Contributor Agreement per this screenshot. You are then added to the group on GitHub. I have resent the invitation to the GitHub group. Kind regards, Sally [image: image.png]
…

I did say "seemingly" ;) I meant, I had no idea who you were, so I was in doubt whether it's real. That issue has now clearly been resolved. :D I appreciate your help and joined the group, thank you!

[ktsakalozos]

Hi @tsluyter, I understand the ping to snapcraft.io to check connectivity may fail in some installations. However, this PR seems to completely disable the connectivity check because it goes and asks the DNS of Google (8.8.8.8) if it knows snapcraft.io it never tries to connect to snapcraft.io. Google will always tell you "yes I know who snapcraft.io is" but later when you try to snap install the MicroK8s snap you may fail. Instead I would suggest we keep the ping as it works most of the times and when the ping fails try doing a GET request to snapcraft.io as a fallback.

[tsluyter]

I understand the ping to snapcraft.io to check connectivity may fail in some installations. However, this PR seems to completely disable the connectivity check because it goes and asks the DNS of Google (8.8.8.8) if it knows snapcraft.io it never tries to connect to snapcraft.io.

Correct. My reasoning being: if I can query an external DNS, I can assume that Internet-connectivity is also present and functional.

Instead I would suggest we keep the ping as it works most of the times and when the ping fails try doing a GET request to snapcraft.io as a fallback.

I was thinking along the same lines... but while we're at it, why not replace the ping outright with a GET request? ICMP may be blocked in some cases, while HTTPS is less likely to be. Unless you're in a corporate network ;)

[ktsakalozos]

why not replace the ping outright with a GET request?

Sure we can try that.

[mbarbero]

Added a suggestion that implement a HEAD request with curl rather than a ping or a nslookup (as per #2823 (comment))

[mbarbero]

Suggested change

	self.run("ping -c 1 snapcraft.io".split(), hide_output=True)
	self.run(
	"sed -i -e s/^#DNS=.*/DNS=8.8.8.8/ /etc/systemd/resolved.conf".split(),
	hide_output=True,
	)
	self.run(
	"systemctl restart systemd-resolved.service".split(),
	hide_output=True
	)
	self.run(
	"nslookup snapcraft.io".split(),
	hide_output=True
	)
	self.run("curl -IsSLf https://snapcraft.io".split(), hide_output=True)