-
-
Notifications
You must be signed in to change notification settings - Fork 273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OSX 10.15 images deprecated in azure, to be removed end of August #1798
Comments
cc @conda-forge/core |
Is this for azure or GitHub actions or both? |
The brownouts mentioned in actions/runner-images#5583 and the OP are for GHAs, and doesn't give a target date for azure, but the warning that caused me to open this issue was on azure |
It's the same for azure. Some builds will get this warnings, e.g. this one,
|
I just checked, the oldest SDK that macos-11 comes with is 10.15, plus xcode 11.7. As far as I can tell, that version still supports deployment target 10.9 (actually 10.6-10.15), so it doesn't sound like the image change forces us to change anything substantial about MacOS support 1 Footnotes |
Thank you! @chrisburr had some nice stats about where we go next on osx pulled from pypi usage. I forget but moving to somewhere around 10.12 would be pretty non-destructive IIRC. |
Would suggest we separate discussing the CI image change from updating the SDK used to build (if possible). Given CI is the primary driver of discussion here, let's focus on that. If we would like to discuss SDK changes, let's open a new issue (unless these are somehow intertwined). In terms of CI image used (the primary concern here), moving macOS 11 is the next oldest thing we can use (as 10.15 is the last in the 10.x line). |
AFAIU, the SDK is not really the issue, the So with that misunderstanding out of the way - fine by me to leave the SDK untouched (assuming the current SDK injection mechanism works in the macos-11 image). |
All good. Just trying to help dial things in a bit so we can make decisions 🙂 |
So we have roughly a month to:
Does that sound correct? |
We have not historically worried about rerendering in these cases. People should rerender almost always when making new PRs. |
So we only need a PR to smithy. |
And we don't have a reason to suspect that the current way we are installing SDKs on the image would happen to fail on MacOS 11, right? I guess we can only try... I'll open a PR on conda-smithy to see what happens. |
Let's see: conda-forge/dav1d-feedstock#2 |
Don't think so, but agree a test is a better way to check |
Everything looks ok:
|
Great! Thanks Jaime 😄 Sounds like we are ready for a conda-smithy PR & release. If we get it out today, we will have ~1 week to try things and catch/fix any issues 🙂 |
We have til August 30th, don't we? Not that I have anything against doing it soon, but it's not as rushed as a week :) |
Well the five 24h-long brown outs from July 27th until end of August sound pretty painful. During that time no OSX pipeline in conda-forge would run through. |
Ah, hadn't considered the brown-outs. I'll add the PR to conda-smithy, then. |
Ah sorry. Was thinking beginning of August for some reason 🤦♂️ Yeah brownouts are an issue too though Thanks Jaime! 🙏 |
Just realized we also need to do this for staged-recipes. Submitted PR here: conda-forge/staged-recipes#19800 After that, I think we can consider this solved and closed. |
No, as you figured (we also have used variations of macos-11 and macos-12 in different feedstocks, one could set this in conda-forge.yml, e.g. see this PR from a while back: #1638 and it works fines). However, it may be worth considering trying to better understand the SDKs situation. The website/repo we get stuff from is no longer maintained, and it doesn't have many of the newer SDKs. Fortunately, for now, most of these newer SDKs come with the images anyway so it's not a big deal. However, it would likely be best to think this through again and decide how best to proceed (i.e. use another repo as shown here: conda-forge/conda-forge-ci-setup-feedstock#201 or rely entirely on what the vmImages offer for example this is what macos-11 has: https://github.com/actions/virtual-environments/blob/main/images/macos/macos-11-Readme.md#installed-sdks) |
They're somewhat intertwined because the images come preconfigured with certain SDKs and that's exactly what we relied on in the pytorch feedstock to support MPS (metal). But yes, this should be more thoroughly discussed elsewhere. Just wanted to point out this was on the radar before and highlight how the SDKs and vmImages relate to a degree.
Yes, from my previous testing, this is solved and closed after the two PRs |
Thanks @ngam! |
Thank YOU for the PRs 😃 |
FYI @beckermr the change may take a bit to come online with conda-smithy (hence rerendering may not effect changes yet) because the CDN cloning has a "major outage"... https://conda-forge.org/status/ |
Also, before this is closed, we need to push a release of conda-smithy, I believe. Otherwise, the changes won't take place. |
We're now in the first brownout on azure (dates of which have been added to the upstream issue, as well as the OP). Could we have a new smithy release? |
@conda-forge/core @conda-forge/conda-smithy |
Felipe commented in conda-forge/conda-smithy#1645
To take the heat off a bit - it's not a crisis. The brownout is only two hours this time. But since that smithy PR has been merged (and I assume the repo is in a releasable state) it would still be good to get a new smithy release soon (i.e. before the next brownout in a week). It'll take a while anyway until feedstocks have been rerendered in large numbers. |
release is done - should be live in an hour or so |
With smithy & staged-recipes now done, I think we can close this. Thanks all! :) |
JFYI we recently saw an (admittedly somewhat niche) issue with Python 3.7 on macOS 11 ( conda-forge/python-feedstock#575 ). Mentioning here merely for awareness. |
Message started appearing in OSX jobs:
Quoting from the upstream issue:
Those brownouts get pretty extensive - 24h for all but the first on GHA, and the same a bit later on Azure - so it sounds we need to move until end of July with this.
The text was updated successfully, but these errors were encountered: