Remove Fedora 22, 23, 24

[rvagg]

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?

[rvagg]

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]

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]

Same as #961 (comment),

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...

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]

See #964, on DigitalOcean we can still yum update but 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]

like they are now.

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]

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]

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]

Waiting on @rvagg for proposal, removing from agenda until that's ready. No general objection to removing unsupported versions based on discussion.

[rvagg]

TODO here: details about what we're supporting and planning on supporting and some kind of calendar for distro updates that we expect.

[Trott]

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]

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.

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.

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]

Will be fixed by #1163

[maclover7]

These machines have all been removed from the CI cluster