Update references to helix queues that are going to be removed at the end of March

[radical]

Opening this to track the work.

• Windows.10.Amd64.Server19H1.ES.Open
• Windows.10.Amd64.Server19H1.ES
• Windows.Server.Amd64.VS2019.Pre.Open
• Windows.Server.Amd64.VS2019.Pre
• Windows.10.Amd64.Server19H1.ES.Open.Rt
• Windows.10.Amd64.Server19H1.ES.svc
• Windows.Server.Amd64.VS2019.Pre.Open.svc
• Windows.Server.Amd64.VS2019.Pre.svc

cc @akoeplinger @steveisok @safern @agocke

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Opening this to track the work.

• Windows.10.Amd64.Server19H1.ES.Open
• Windows.10.Amd64.Server19H1.ES
• Windows.Server.Amd64.VS2019.Pre.Open
• Windows.Server.Amd64.VS2019.Pre
• Windows.10.Amd64.Server19H1.ES.Open.Rt
• Windows.10.Amd64.Server19H1.ES.svc
• Windows.Server.Amd64.VS2019.Pre.Open.svc
• Windows.Server.Amd64.VS2019.Pre.svc

cc @akoeplinger @steveisok @safern

Author:	radical
Assignees:	-
Labels:	area-Infrastructure, untriaged
Milestone:	-

[steveisok]

@agocke We should make this a recurring item in the infra stand up or CI council.

[elinor-fung]

For Windows.10.Amd64.Server19H1.ES.Open, should we be moving to Server2022 or something else?

Asking because we're chasing a tail of issues after the move from Windows.10.Amd64.Server19H1.Open to Windows.Amd64.Server2022 in runtime-extra-platforms.

[agocke]

@elinor-fung would you have enough bandwidth to start this work as well? I think you might have the most context at the moment.

[elinor-fung]

From the list of queues being removed, Windows.10.Amd64.Server19H1.ES.Open is the only one I'm finding in our yml - used in PR builds. I think we are good on the others?

I don't know what the ES means here. I'm not finding newer images with that suffix on helix.dot.net.

Is Windows.10.Amd64.Server19H1.ES.Open -> Windows.Amd64.Server2022 the right move? And if so, I guess remove Server2022 from runtime-extra-platforms.

[safern]

I don't know what the ES means here. I'm not finding newer images with that suffix on helix.dot.net.

ES means spanish locale, so that machine is in spanish. We should ask dnceng to provide us with a spanish locale queue for Server 2022 and use that (we added testing on a different local because some years ago we found out we had a test hole there). Once that queue is added, we can remove the server 2022 from extra platforms and then use that in the main pipeline.

@MattGal is it possible to add an ES Server 2022 queue?

[elinor-fung]

Once that queue is added, we can remove the server 2022 from extra platforms and then use that in the main pipeline.

Would we want to keep the non-ES (I'm assuming english) queue in extra platforms? It looks like that was what we were doing for Server19H1 (spanish in main pipeline, english in extra platforms), but I don't know how much value that was actually providing.

[safern]

Would we want to keep the non-ES (I'm assuming english) queue in extra platforms? It looks like that was what we were doing for Server19H1 (spanish in main pipeline, english in extra platforms), but I don't know how much value that was actually providing.

I think we could keep doing that, it provides some value, I guess to test on an english locale and a non english.

[elinor-fung]

@MattGal is it possible to add an ES Server 2022 queue?

@MattGal do you want us to file a separate issue for this request?

@elinor-fung would you have enough bandwidth to start this work as well? I think you might have the most context at the moment.

I can start taking a look once we have a non-english queue to move to. Meanwhile, we're continuing to chase down issues we're hitting in extra platforms for Server 2022 (so hopefully the move of the main pipeline won't be as bad).

[MattGal]

@MattGal is it possible to add an ES Server 2022 queue?

Yes, can you please either file a new dotnet/core-eng issue or add this to https://github.com/dotnet/core-eng/issues/15341 ?

I want to point out two things about the Arcade Helix SDK's warnings:

• They're warnings, and they need to be because just logging a message is definitely ignored. This means some teams will need to have one build command that doesn't set TreatWarningsAsErrors to true so they can see warnings.
• The warnings start three weeks before hand and there will be times when we have no good story for you to migrate to, such as when an OS is truly decommissioned (Windows 8, for instance, will eventually have no successor). The warnings are only there for your benefit, they don't become errors until the queue doesn't exist, which is never before that date and almost always some days after.
• If you let us know you need something we lack a suitable replacement for, we can always extend the date for a removal, just in a world where we're trying to end dead OSes we have to have some system we can agree upon.

[elinor-fung]

Filed https://github.com/dotnet/core-eng/issues/15548

[elinor-fung]

ES queue expiration dates have been extended by a month (to 31-MAR) - https://github.com/dotnet/core-eng/issues/15341#issuecomment-1044718728

[radical]

Can this be closed now?

[MattGal]

Can this be closed now?

I think so; the warnings as errors is long resolved and we have a Server 2022 ES-ES queue which will last a relatively long time.

[elinor-fung]

Yeah. We switched to Server 2022 ES-ES in :

• Move to Windows.10.Amd64.Server2022.ES.Open #66404
• [release/6.0] Move to Windows.10.Amd64.Server2022.ES.Open #67054