Nah, on the contrary, there is nothing for snapd to do here; it already
does what's wanted (and has from day one). I'm removing snapd from the
bug ...
of course if I got something wrong, please add it back and let us know
:-) (setting it to new will get it noticed soonest)
** No longer affects:
I've added snapd project task and set this to triaged/wishlist but based
on the current discussion I think WONTFIX or INVALID might also be
appropriate.
** Also affects: snapd
Importance: Undecided
Status: New
** Changed in: snapd
Status: New => Triaged
** Changed in: snapd
No, snapd's behaviour has not changed
--
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:
Hm so it sounds like snapd's behaviour is what Dimitri is asking for
here? Has this changed in snapd recently (note that this behaviour was
observed during the disco release sprint, so April 2019).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
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:
Here's the same log on the ubuntu pastebin (not sure why i thought the
bug was private): https://pastebin.ubuntu.com/p/dpxpPkHSbM/
--
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
On the snapd side, what we do does not "know" about fastly at all: what the
connectivity check does is
1. hit the store's "info" endpoint asking about "core",
2. HEAD the download url provided in (1)
The request done in (2) sets the cdn headers as usual (ie it looks at
whether CDN is disabled by
I only marked it as affecting subiquity, in practice yes fixes need to
happen in snapd.
I don't think that' uncommon to only our infrastructure. We have seen in
the wild people enable the endspoints that are seen and only
api.snapcraft.com is attempted (or so it would seem) without it being
Ugh.
I don't see what subiquity can do differently here, we're just making
snapd api calls, it seems to me (and I don't just want to be seen as
passing the buck) that snapd is the right place to solve this (or even
the store: it could detect the request is coming from an internal IP and
not
