Repository navigation
Remove Fedora 22, 23, 24 #962
Description
test-digitalocean-fedora22-x64-1
test-digitalocean-fedora23-x64-1
test-digitalocean-fedora24-x64-1
test-rackspace-fedora22-x64-1
test-rackspace-fedora23-x64-1
test-rackspace-fedora24-x64-1
24 was EOL in August, the other two were last year.
https://fedoraproject.org/wiki/End_of_life
Any good reason to not boot them off entirely?
Activity
rvagg commentedon Nov 1, 2017
see also #963, we might want consider ditching 25 in this round too since I believe it'll go EOL in about 5 weeks from now (EOL = "GA of next-but-one release plus one month" https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle, F27 is due on the 7th.)
refack commentedon Nov 1, 2017
There was a discussion about this subject a few months ago nodejs/node#12672
AFAIR it was decided that we'll do "best-effort" CI to test that we don't pull the rug under anyone still using a node LTS version even on an EOL platform...
So probably best to exclude from v8 and v9 matrix, keet for 4 and 6.
Also possible reduce stock to 1 of each?
gibfahn commentedon Nov 1, 2017
Same as #961 (comment),
I think the conclusion was that there's no reason to force ourselves to drop everything as soon as it goes EoL. My vote is to leave them until they're the slightest bit of effort to maintain, at which point we remove them.
Of course if removing them frees up resources we need for something else that's a good argument for removing.
rvagg commentedon Nov 1, 2017
See #964, on DigitalOcean we can still
yum updatebut it's failing elsewhere. We can no longer run our Ansible scripts on them because of this. Since Fedora moves so fast I'd be keen to boot the older ones as soon as they present any difficulty, like they are now.gibfahn commentedon Nov 2, 2017
If we're going for an "as long as they're no trouble" policy, and they're already causing trouble, then now is the time to remove them IMO.
rvagg commentedon Nov 15, 2017
We're running out of space on digitalocean and rackspace is getting pretty full too, I'd like to drop off fedora 22 when we can run 27 (released yesterday); right now 27 isn't available on our providers but I'd expect it to be soon. Any objections?
rvagg commentedon Dec 5, 2017
I've agreed to formulate a position to bring back to the group for discussion at the next meeting. For now I'm going to remove 22 when I put 27 in (sometime soon) but the proposal will be something like: no more than 8 machines allocated to Fedora at a time. We have 10 now so that would mean dropping 23 as well.
In our discussion we also noted that Fedora should probably be treated differently since it's primarly a desktop distro and doesn't have an LTS strategy so our strategy should move with it. Ubuntu, Debian and CentOS (and maybe Alpine) are more important for us since they are primary deployment targets.
mhdawson commentedon Jan 16, 2018
Waiting on @rvagg for proposal, removing from agenda until that's ready. No general objection to removing unsupported versions based on discussion.
rvagg commentedon Feb 6, 2018
TODO here: details about what we're supporting and planning on supporting and some kind of calendar for distro updates that we expect.
Trott commentedon Feb 7, 2018
Is there a projected timeline on this? There've been some Fedora 23 and 24 build issues but I won't bother surfacing them if we think they're going away from CI in the next few weeks.
maclover7 commentedon Feb 7, 2018
It looks like (unbeknownst to the build team as far as I can tell) the nodejs.org has been updated to remove several version of Fedora: nodejs/nodejs.org#1560.
My recommendation would be to mark then as offline now, and then physically the machines (from Ansible inventory and from the DigitalOcean/Rackspace/etc admin portals) later. Like @Trott said, to avoid spending time on things that are going away shortly.
maclover7 commentedon Mar 6, 2018
Will be fixed by #1163
maclover7 commentedon May 22, 2018
These machines have all been removed from the CI cluster