Importantly, the decision to go to e.g. fastly, vs nothing, is done _store side_. snapd knows nothing about fastly, and the store could (and has in the past) swapped CDNs and snapd is none the wiser. Here's the log of a connectivity check, done from home:
https://pastebin.canonical.com/p/p7BNX2z85Q/ (that's the regular debug log output run through delog.py¹) note that it only hits fastly because of a 302 from the store. snapd does exactly what it does to fetch a snap by name. In that sense, snapd is already doing what this bug asks it to do. If the connectivity check passes, the download from snapd should pass just as well. If it doesn't, something else might be broken. 1. https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c6537 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1829510 Title: snapd connectivity check did not change fastly cdn To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1829510/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
