Clarify that 404 at "downloading legacy link" in dotnet-install.sh is usually expected

[dagood]

When builds fail with issues like this, there's a huge red herring:

Trying to run 'curl https://dot.net/v1/dotnet-install.sh -sSL --retry 10 --create-dirs -o /__w/1/s/.dotnet/dotnet-install.sh' for maximum of 5 attempts.
Ran 'curl https://dot.net/v1/dotnet-install.sh -sSL --retry 10 --create-dirs -o /__w/1/s/.dotnet/dotnet-install.sh' successfully.
dotnet_install: Warning: Unable to locate zlib. Probable prerequisite missing; install zlib.

dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-sdk-5.0.100-preview.3.20168.11-linux-x64.tar.gz
curl: (56) GnuTLS recv error (-9): A TLS packet with unexpected length was received.

dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-sdk-5.0.100-preview.3.20168.11-linux-x64.tar.gz

dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-dev-ubuntu.16.04-x64.5.0.100-preview.3.20168.11.tar.gz
curl: (22) The requested URL returned error: 404 Not Found

dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-dev-ubuntu.16.04-x64.5.0.100-preview.3.20168.11.tar.gz

dotnet_install: Error: Could not find/download: `.NET Core SDK` with version = 5.0.100-preview.3.20168.11
dotnet_install: Error: Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support

The error here is curl: (56) GnuTLS recv error (-9). But, people see the 404 for the legacy download and sometimes miss the main problem, think the 404 might be a related problem, or that they have a secondary problem to look into also.

The message should clarify that the legacy download link is not a backup. (This is a typical interpretation.)

Or, can we remove the legacy fallback? What versions actually use it (are they EOL)?

[dsplaisted]

@marcpopMSFT this should go to Bekir for triage, but I don't know his GitHub handle

[marcpopMSFT]

@dsplaisted it's @bozturkMSFT

[donJoseLuis]

the 2nd link is already dead, thus it results in a 404, as mentioned.

1. we should eliminate this link
2. the script logs the failure, we plan to have telemetry + dashboards which will make these cases more obvious
3. depending on the failure reason, it may make sense to retry or abort for a while

[dagood]

• we should eliminate this link

Maybe you're already aware, but I want to make sure this is considered appropriately. We'd need to be sure nobody is using (or plans to use) a version of the SDK that uses the legacy link rather than the new style of link. That's why I focused the issue on the misleading messaging rather than asking the link to be removed. (If we can stop supporting the legacy link, that would be good, but I have my doubts.)

• the script logs the failure, we plan to have telemetry + dashboards which will make these cases more obvious

How does this help the scenario I'm pointing at here? Are you expecting a user of the script to have access to the telemetry and dashboards, or is there some other scenario being looked at here?

• depending on the failure reason, it may make sense to retry or abort for a while

Lack of retries seems like a separate issue about script reliability, not related to misleading log messages.

---

/cc @dleeapho @MichaelSimons @NikolaMilosavljevic @leecow @rbhanda

[bekir-ozturk]

A similar issue: dotnet/sdk#10450

@johnbeisner wrote:

The install scripts rely on a failure to download as a normal procedure.

The 'primary' blob storage location is tried
if the download fails
The 'legacy' blob storage location is tried

This can be confusing to users as they see an 'error' in a successful process.

Proposal:

1. Maintain a hint path table with presedential ordering

2. Perform a 'lookup' first before trying a download [retry]

3. If found, then download [retry]

4. if not found, error-out with all the paths attempted.

Let's track them both here. I am closing the other.

[donJoseLuis]

The need tracked in this issue should be a requirement in the re-engineering effort. Moving to the re-engineering project.

[AR-May]

Changed the messages such that if we have 404-NotFound and some other error, the other (actual) error will be displayed at the end of the log as an error. However, the messages concerning legacy link download attempt and failure stay as info messages.