add Fedora35 Helix image

[wfurt]

contributes to dotnet/core#6446
contributes to #502

in addition it removes old unsupported Fedora32
contributes to dotnet/core#6431

now, locked the old container on release/6.0 branch of dotnet./msquic so it is suitable for 6.0 testing (msquic 1.7)
new container pulls in main and new features and produces msquic 1.8 to test with main of runtime.

contributes to dotnet/runtime#55639

the docker image is mostly clone of existing 34.
since new Fedora uses Python3 be default I removed some old craft & custom pip.

[MattGal]

Helix changes look fine to me, the DNS issues with Fedora sites are mysterious.

[ManickaP]

BTW, do we plan to put msquic on some other distros as well?

[mthalman]

Adding @omajid to help in diagnosing the build error.

[wfurt]

This looks like a problem either with the infrastructure or with the base fedora image itself.

Step 2/8 : RUN cat /etc/resolv.conf
 ---> Running in 98ec3aed678b
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 168.63.129.16
search owz4dc5o1g0evnwcscpbtikkfe.xx.internal.cloudapp.net
Removing intermediate container 98ec3aed678b
 ---> c1d5e2e5d871
Step 3/8 : RUN curl -v http://google.com/
 ---> Running in a96309a7f6ec
* getaddrinfo() thread failed to start
* Could not resolve host: google.com
* Closing connection 0
curl: (6) getaddrinfo() thread failed to start

Retry 1/5, retrying in 1 seconds...
The command '/bin/sh -c curl -v http://google.com/' returned a non-zero code: 6
Sending build context to Docker daemon  4.608kB

I'm not sure where the 168.63.129.16 comes from but the container is unable to resolve names.
cc: @tmds as well for ideas.

[omajid]

The error message seems to suggest that this is actions/runner-images#3812

[wfurt]

Looks like the 168.63. 129.16 is Azure name server so it is probably ok.

[wfurt]

The will be problematic even for helix, right @omajid e.g. it is not just problem building the image...

[mthalman]

@chrispat - Any idea when the moby fix mentioned in actions/runner-images#3812 will make its way into Azure DevOps Linux hosted agents?

[chrispat]

Azure DevOps and GitHub Actions use the same Linux images. So it should make it to both at the same time.

[wfurt]

I'm not sure what is next step here. Wait? If so, is there some trigger to know it is ready? For the QUIC changes I can go back to Fedora34 but I guess reason for the updated test matrix is to spot issues early.

[omajid]

@wfurt we can work around failures when running the container by disabling security policy as suggested at actions/runner-images#3812 (comment) but I don't know of a solution for docker build.

I can't see anything we (.NET folks) can do here short of waiting for updated moby.

[wfurt]

Thanks for update @omajid. I'll probably split the PR and proceed with the QUIC changes independently. It also feels safe to nuke the 32, right? I originally nuke it from the manifest but I'm wondering if we should delete the files as well. Any preference @mthalman ?

[mthalman]

It also feels safe to nuke the 32, right? I originally nuke it from the manifest but I'm wondering if we should delete the files as well. Any preference @mthalman?

Deleting the files seems appropriate.

[aik-jahoda]

@wfurt, is there a way I can help there? For example move helix image to another PR?

[wfurt]

I'm not sure what you suggesting @aik-jahoda. From what I understand the new Fedora (and some other distributions) will not function in current infrastructure.

[omajid]

Same issue also affects RHEL 9: #520