Ceph Steering Committee Meeting 2024-10-14
Hello, - Ceph Steering Committee (CSC) election - closed at the beginning of the meeting with 23 out of 26 votes - Patrick has sent a separate email with the results - Ceph Executive Council (CEC) topics - an extended list of responsibilities has been captured in https://pad.ceph.com/p/ceph-exec-council-responsibilities - should it be merged into the governance doc? - no, but still want to commit it as a separate doc just because it's more durable than the etherpad - should a second be needed for the CEC nomination? - no, stick to 1 to allow self-nominations - succession plan and CEC terms - none of current CEC members were in attendance, topic moved to next week - see https://pad.ceph.com/p/css-vote-2024q4 for more details - place for documentation that isn't tied to releases - came up again in https://github.com/ceph/ceph/pull/60204 - Ilya proposed to reuse what is done for doc/releases directory, where content from main is served for all other branches - Zac will follow up with Patrick to set that up for the governance doc and possibly other items - 17.2.8 release and centos 8 - options on the table: a) do nothing and release 17.2.8 with centos 8 dropped completely similar to 18.2.4 b) build centos 8 packages but don't test them, mark the packages as C (untested) on "OS recommendations" page c) resurrect everything including teuthology bits and try to do a full blown release as before - centos 8 builder machine(s) would be needed for b) and c) since mock isn't used for rpm builds like pbuilder is for deb builds - containerization (https://github.com/ceph/ceph/pull/60230 extended to centos 8?) may solve some of it, but upgrade suites are still a problem - python-scikit-learn package availability (Joao) - it's pulled from Kefu's copr repo: https://github.com/ceph/ceph-container/blob/ffa99709212d0dca3e09dd3d085a0b5a... - EPEL 8 version is no longer there, only EPEL 9 - but there is also Dan's copr repo? - https://copr.fedorainfracloud.org/coprs/dmick/python-scikit-learn - discussion will continue offline (Greg, Ken, Dan) Thanks, Ilya
Hi, On Tue, Oct 15, 2024 at 1:45 AM Ilya Dryomov <idryomov@gmail.com> wrote:
- 17.2.8 release and centos 8 - python-scikit-learn package availability (Joao) - it's pulled from Kefu's copr repo: https://github.com/ceph/ceph-container/blob/ffa99709212d0dca3e09dd3d085a0b5a... - EPEL 8 version is no longer there, only EPEL 9 - but there is also Dan's copr repo? - https://copr.fedorainfracloud.org/coprs/dmick/python-scikit-learn
Where do we need python-scikit-learn? It's coming in for mgr-diskprediction-local, right? The spec file actually requires python3-scipy in the case of actual el8 hosts. And python3-scipy is in el8 AppStream, e.g. https://linuxsoft.cern.ch/cern/alma/8.10/AppStream/x86_64/os/Packages/python... Enrico confirmed he can still install quincy 18.2.4 mgr-diskprediction-local on an Alma 8 host today. scikit-learn seems to be needed only for fedora, suse_version, and openEuler. Cheers, Dan
On Tue, Oct 15, 2024 at 12:01 PM Dan van der Ster <dan.vanderster@clyso.com> wrote:
Hi,
On Tue, Oct 15, 2024 at 1:45 AM Ilya Dryomov <idryomov@gmail.com> wrote:
- 17.2.8 release and centos 8 - python-scikit-learn package availability (Joao) - it's pulled from Kefu's copr repo:
https://github.com/ceph/ceph-container/blob/ffa99709212d0dca3e09dd3d085a0b5a...
- EPEL 8 version is no longer there, only EPEL 9 - but there is also Dan's copr repo? -
https://copr.fedorainfracloud.org/coprs/dmick/python-scikit-learn
Where do we need python-scikit-learn? It's coming in for mgr-diskprediction-local, right? The spec file actually requires python3-scipy in the case of actual el8 hosts. And python3-scipy is in el8 AppStream, e.g.
https://linuxsoft.cern.ch/cern/alma/8.10/AppStream/x86_64/os/Packages/python...
Enrico confirmed he can still install quincy 18.2.4 mgr-diskprediction-local on an Alma 8 host today.
scikit-learn seems to be needed only for fedora, suse_version, and openEuler.
Can we remove the diskprediction-local mgr module from Ceph? - Ken
On Thu, Oct 17, 2024 at 11:18 AM Ken Dreyer <kdreyer@redhat.com> wrote:
On Tue, Oct 15, 2024 at 12:01 PM Dan van der Ster <dan.vanderster@clyso.com> wrote:
Hi,
On Tue, Oct 15, 2024 at 1:45 AM Ilya Dryomov <idryomov@gmail.com> wrote:
- 17.2.8 release and centos 8 - python-scikit-learn package availability (Joao) - it's pulled from Kefu's copr repo: https://github.com/ceph/ceph-container/blob/ffa99709212d0dca3e09dd3d085a0b5a... - EPEL 8 version is no longer there, only EPEL 9 - but there is also Dan's copr repo? - https://copr.fedorainfracloud.org/coprs/dmick/python-scikit-learn
Where do we need python-scikit-learn? It's coming in for mgr-diskprediction-local, right? The spec file actually requires python3-scipy in the case of actual el8 hosts. And python3-scipy is in el8 AppStream, e.g. https://linuxsoft.cern.ch/cern/alma/8.10/AppStream/x86_64/os/Packages/python...
Enrico confirmed he can still install quincy 18.2.4 mgr-diskprediction-local on an Alma 8 host today.
scikit-learn seems to be needed only for fedora, suse_version, and openEuler.
Can we remove the diskprediction-local mgr module from Ceph?
+1 probably, yes. But the implication is that the devicehealth module will then have no implementation for predict_lift_expectancy. IMHO, we should simplify that down to something trivial based on the SMART status + a wearout indicator for flash.
- Ken
IMHO, we should simplify that down to something trivial based on the SMART status + a wearout indicator for flash.
That’d be a good place to start. Drive mfgs and smartmontools’ drivedb.h are all over the map wrt attribute IDs and labels - and in some cases even used vs remaining - so we might need to have a regexp sort of match for SAS/SATA drives. NVMe should be a bit more standardized.
Can we remove the diskprediction-local mgr module from Ceph?
+1 probably, yes. But the implication is that the devicehealth module will then have no implementation for predict_lift_expectancy. IMHO, we should simplify that down to something trivial based on the SMART status + a wearout indicator for flash.
That’d be a good place to start. Drive mfgs and smartmontools’ drivedb.h are all over the map wrt attribute IDs and labels - and in some cases even used vs remaining - so we might need to have a regexp sort of match for SAS/SATA drives. NVMe should be a bit more standardized.
participants (5)
-
Anthony D'Atri
-
Anthony D'Atri
-
Dan van der Ster
-
Ilya Dryomov
-
Ken Dreyer