Message ID | 1463987442-6159-1-git-send-email-ynezz@true.cz |
---|---|
State | Changes Requested |
Headers | show |
Petr Štetiar <ynezz@true.cz> writes: > More info at https://www.kernel.org/introducing-fastly-cdn.html > > Signed-off-by: Petr Štetiar <ynezz@true.cz> > --- > scripts/download.pl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/download.pl b/scripts/download.pl > index 548eb7a..ec7067b 100755 > --- a/scripts/download.pl > +++ b/scripts/download.pl > @@ -207,7 +207,7 @@ foreach my $mirror (@ARGV) { > push @extra, "$extra[0]/longterm/v$1"; > } > foreach my $dir (@extra) { > - push @mirrors, "https://kernel.org/pub/$dir"; > + push @mirrors, "https://cdn.kernel.org/pub/$dir"; > push @mirrors, "ftp://kernel.org/pub/$dir"; > } > } elsif ($mirror =~ /^\@GNOME\/(.+)$/) { Not sure that is a good idea at this point. At least here, kernel.org has IPv6 AAAA records while cdn.kernel.org does not: bjorn@canardo:~$ host kernel.org kernel.org has address 198.145.20.140 kernel.org has address 199.204.44.194 kernel.org has address 149.20.4.69 kernel.org has IPv6 address 2620:3:c000:a:0:1991:8:25 kernel.org has IPv6 address 2001:4f8:1:10:0:1991:8:25 kernel.org mail is handled by 30 ns2.kernel.org. kernel.org mail is handled by 30 ns4.kernel.org. kernel.org mail is handled by 10 mail.kernel.org. kernel.org mail is handled by 999 bl-ckh-le.kernel.org. bjorn@canardo:~$ host cdn.kernel.org cdn.kernel.org is an alias for k.global-ssl.fastly.net. k.global-ssl.fastly.net has address 185.31.17.69 Bjørn
Bjørn Mork <bjorn@mork.no> wrote: > Not sure that is a good idea at this point. At least here, > kernel.org has IPv6 AAAA records while cdn.kernel.org does not: So you're taking that up with kernel.org right? Sincerely, Karl P
On 2016-05-23 10:29, Bjørn Mork wrote: > Petr Štetiar <ynezz@true.cz> writes: > >> More info at https://www.kernel.org/introducing-fastly-cdn.html >> >> Signed-off-by: Petr Štetiar <ynezz@true.cz> >> --- >> scripts/download.pl | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/scripts/download.pl b/scripts/download.pl >> index 548eb7a..ec7067b 100755 >> --- a/scripts/download.pl >> +++ b/scripts/download.pl >> @@ -207,7 +207,7 @@ foreach my $mirror (@ARGV) { >> push @extra, "$extra[0]/longterm/v$1"; >> } >> foreach my $dir (@extra) { >> - push @mirrors, "https://kernel.org/pub/$dir"; >> + push @mirrors, "https://cdn.kernel.org/pub/$dir"; >> push @mirrors, "ftp://kernel.org/pub/$dir"; >> } >> } elsif ($mirror =~ /^\@GNOME\/(.+)$/) { > > Not sure that is a good idea at this point. At least here, kernel.org > has IPv6 AAAA records while cdn.kernel.org does not: So why not add both? :) - Felix
Citeren Felix Fietkau <nbd@nbd.name>: > On 2016-05-23 10:29, Bjørn Mork wrote: >> Petr Štetiar <ynezz@true.cz> writes: >> >>> More info at https://www.kernel.org/introducing-fastly-cdn.html >>> >>> Signed-off-by: Petr Štetiar <ynezz@true.cz> >>> --- >>> scripts/download.pl | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/scripts/download.pl b/scripts/download.pl >>> index 548eb7a..ec7067b 100755 >>> --- a/scripts/download.pl >>> +++ b/scripts/download.pl >>> @@ -207,7 +207,7 @@ foreach my $mirror (@ARGV) { >>> push @extra, "$extra[0]/longterm/v$1"; >>> } >>> foreach my $dir (@extra) { >>> - push @mirrors, "https://kernel.org/pub/$dir"; >>> + push @mirrors, "https://cdn.kernel.org/pub/$dir"; >>> push @mirrors, "ftp://kernel.org/pub/$dir"; >>> } >>> } elsif ($mirror =~ /^\@GNOME\/(.+)$/) { >> >> Not sure that is a good idea at this point. At least here, kernel.org >> has IPv6 AAAA records while cdn.kernel.org does not: > So why not add both? :) +1 I'd prefer a geographically close IPv4 only server over one that is also reachable over IPv6. And while add it, maybe change 'kernel.org' to 'www.kernel.org'. Although they seem to resolve to the same IPv4/IPv6 addresses, the latter is whats mentioned in the Fastly introduction message if one specifically does NOT want to use the CDN.
Felix Fietkau <nbd@nbd.name> [2016-05-23 11:11:50]: > On 2016-05-23 10:29, Bjørn Mork wrote: > > Petr Štetiar <ynezz@true.cz> writes: > > > >> - push @mirrors, "https://kernel.org/pub/$dir"; > >> + push @mirrors, "https://cdn.kernel.org/pub/$dir"; > >> push @mirrors, "ftp://kernel.org/pub/$dir"; > > > > Not sure that is a good idea at this point. At least here, kernel.org > > has IPv6 AAAA records while cdn.kernel.org does not: > > So why not add both? :) If I understand it correctly, the code is going to use another mirror only if the current mirror fails. In my case the download was awfully slow, but didn't failed. -- ynezz
Citeren Petr Štetiar <ynezz@true.cz>: > Felix Fietkau <nbd@nbd.name> [2016-05-23 11:11:50]: > >> On 2016-05-23 10:29, Bjørn Mork wrote: >> > Petr Štetiar <ynezz@true.cz> writes: >> > >> >> - push @mirrors, "https://kernel.org/pub/$dir"; >> >> + push @mirrors, "https://cdn.kernel.org/pub/$dir"; >> >> push @mirrors, "ftp://kernel.org/pub/$dir"; >> > >> > Not sure that is a good idea at this point. At least here, kernel.org >> > has IPv6 AAAA records while cdn.kernel.org does not: >> >> So why not add both? :) > > If I understand it correctly, the code is going to use another mirror only if > the current mirror fails. In my case the download was awfully slow, > but didn't > failed. If you're on a IPv6 only network, the connection to cdn.kernel.org *will* fail (as it doesn't have an AAAA record in DNS). At least from my location, cdn.kernel.org is a lot faster than (www.)kernel.org, so I'd too like to see it tried first.
On 2016-05-23 12:29, Petr Štetiar wrote: > Felix Fietkau <nbd@nbd.name> [2016-05-23 11:11:50]: > >> On 2016-05-23 10:29, Bjørn Mork wrote: >> > Petr Štetiar <ynezz@true.cz> writes: >> > >> >> - push @mirrors, "https://kernel.org/pub/$dir"; >> >> + push @mirrors, "https://cdn.kernel.org/pub/$dir"; >> >> push @mirrors, "ftp://kernel.org/pub/$dir"; >> > >> > Not sure that is a good idea at this point. At least here, kernel.org >> > has IPv6 AAAA records while cdn.kernel.org does not: >> >> So why not add both? :) > > If I understand it correctly, the code is going to use another mirror only if > the current mirror fails. In my case the download was awfully slow, but didn't > failed. You could put the CDN first, and the regular kernel.org afterwards. Also, I think you could probably get rid of ftp://kernel.org while we're at it. FTP is a horrible protocol and if HTTP fails, FTP is even more likely to fail. - Felix
Felix Fietkau <nbd@nbd.name> writes: > On 2016-05-23 12:29, Petr Štetiar wrote: >> Felix Fietkau <nbd@nbd.name> [2016-05-23 11:11:50]: >> >>> On 2016-05-23 10:29, Bjørn Mork wrote: >>> > Petr Štetiar <ynezz@true.cz> writes: >>> > >>> >> - push @mirrors, "https://kernel.org/pub/$dir"; >>> >> + push @mirrors, "https://cdn.kernel.org/pub/$dir"; >>> >> push @mirrors, "ftp://kernel.org/pub/$dir"; >>> > >>> > Not sure that is a good idea at this point. At least here, kernel.org >>> > has IPv6 AAAA records while cdn.kernel.org does not: >>> >>> So why not add both? :) >> >> If I understand it correctly, the code is going to use another mirror only if >> the current mirror fails. In my case the download was awfully slow, but didn't >> failed. > You could put the CDN first, and the regular kernel.org afterwards. Sounds like a good solution. As for reporting this problem to the kernel.org admins: I'm pretty sure they are aware of the issue, and they do provide both URLs so it's not a showstopper. I just wanted to point out the regression *replacing* the dual stack URL would represent in OpenWrt. Using both, with the CDN being tried first, gets the best of both worlds Until the CDN is dual stack, which is bound to happen sooner or later. > Also, I think you could probably get rid of ftp://kernel.org while we're > at it. FTP is a horrible protocol and if HTTP fails, FTP is even more > likely to fail. Maybe someone is preferring ftp because of the cacheability? Or maybe not... Bjørn
Citeren Bjørn Mork <bjorn@mork.no>: > Felix Fietkau <nbd@nbd.name> writes: >> On 2016-05-23 12:29, Petr Štetiar wrote: >>> Felix Fietkau <nbd@nbd.name> [2016-05-23 11:11:50]: >>> >>>> On 2016-05-23 10:29, Bjørn Mork wrote: >>>> > Petr Štetiar <ynezz@true.cz> writes: >>>> > >>>> >> - push @mirrors, "https://kernel.org/pub/$dir"; >>>> >> + push @mirrors, "https://cdn.kernel.org/pub/$dir"; >>>> >> push @mirrors, "ftp://kernel.org/pub/$dir"; >>>> > >>>> > Not sure that is a good idea at this point. At least here, kernel.org >>>> > has IPv6 AAAA records while cdn.kernel.org does not: >>>> >>>> So why not add both? :) >>> >>> If I understand it correctly, the code is going to use another >>> mirror only if >>> the current mirror fails. In my case the download was awfully >>> slow, but didn't >>> failed. >> You could put the CDN first, and the regular kernel.org afterwards. > > Sounds like a good solution. > > As for reporting this problem to the kernel.org admins: I'm pretty sure > they are aware of the issue, and they do provide both URLs so it's not a > showstopper. I just wanted to point out the regression *replacing* the > dual stack URL would represent in OpenWrt. Using both, with the CDN > being tried first, gets the best of both worlds Since GitHub apparently also uses Fastly as CDN provider, building on a machine with IPv6 only connectivity is going to be difficult anyway. Using both won't hurt, but if you're not able to connect to an IPv4 server for the kernel sources, you'll likely run into similar problems for pretty much everything else too. > Until the CDN is dual stack, which is bound to happen sooner or later. > >> Also, I think you could probably get rid of ftp://kernel.org while we're >> at it. FTP is a horrible protocol and if HTTP fails, FTP is even more >> likely to fail. > > Maybe someone is preferring ftp because of the cacheability? Or maybe > not... > > > Bjørn > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev
Arjen de Korte <arjen+lede@de-korte.org> writes: > Since GitHub apparently also uses Fastly as CDN provider, building on > a machine with IPv6 only connectivity is going to be difficult anyway. > Using both won't hurt, but if you're not able to connect to an IPv4 > server for the kernel sources, you'll likely run into similar problems > for pretty much everything else too. Yes, github seems to have a few issues to sort out. They also have SSHFP records but no DNSKEY. That's weird. Bjørn
On Mon, May 23, 2016 at 01:02:06PM +0200, Bjørn Mork wrote: > Felix Fietkau <nbd@nbd.name> writes: > > You could put the CDN first, and the regular kernel.org afterwards. > > Sounds like a good solution. > > As for reporting this problem to the kernel.org admins: I'm pretty sure > they are aware of the issue, and they do provide both URLs so it's not a > showstopper. I just wanted to point out the regression *replacing* the > dual stack URL would represent in OpenWrt. Using both, with the CDN > being tried first, gets the best of both worlds > > Until the CDN is dual stack, which is bound to happen sooner or later. The lack of IPv6 support from fastly has been a problem for the Python ecosystem for several years: https://bitbucket.org/pypa/pypi/issues/90/missing-ipv6-connectivity https://mail.python.org/pipermail/distutils-sig/2014-June/024465.html http://bugs.python.org/issue26021 Even in 2013, it was supposedly on fastly's roadmap. Nothing has changed since then, so there's room to be pessimistic about when they will be dual-stacked. So, putting both mirrors (CDN first, www.kernel.org second) sounds like a good idea for now. Baptiste
diff --git a/scripts/download.pl b/scripts/download.pl index 548eb7a..ec7067b 100755 --- a/scripts/download.pl +++ b/scripts/download.pl @@ -207,7 +207,7 @@ foreach my $mirror (@ARGV) { push @extra, "$extra[0]/longterm/v$1"; } foreach my $dir (@extra) { - push @mirrors, "https://kernel.org/pub/$dir"; + push @mirrors, "https://cdn.kernel.org/pub/$dir"; push @mirrors, "ftp://kernel.org/pub/$dir"; } } elsif ($mirror =~ /^\@GNOME\/(.+)$/) {
More info at https://www.kernel.org/introducing-fastly-cdn.html Signed-off-by: Petr Štetiar <ynezz@true.cz> --- scripts/download.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)