Page MenuHomePhabricator

wmcs: evaluate impact of stretch-backports being archived
Open, HighPublic

Description

When the official jessie-backports repository was archived we had an intense fight to get things in shape again (see T216497)

Most openstack packages are now directly installed from our in-house mirror in https://mirrors.wikimedia.org/ but it is not clear if some VM (or hardware server) is using packages outside the mirror.

Event Timeline

aborrero created this task.Jul 1 2020, 2:44 PM
Restricted Application edited projects, added cloud-services-team (Kanban); removed cloud-services-team. · View Herald TranscriptJul 1 2020, 2:44 PM
Bstorm triaged this task as High priority.Jul 1 2020, 2:53 PM
Legoktm added a subscriber: Legoktm.Jul 1 2020, 3:05 PM

The golang-sssd docker image installs golang-go from stretch-backports.

A quick codesearch through puppet finds:

modules/profile/manifests/toolforge/grid/exec_environ.pp
377
378        apt::pin { $nodejs_packages:
379            pin      => 'release a=stretch-backports',
380            priority => '2000',
381            before   => Package['nodejs'],
...
391            ]:
392            ensure          => latest,
393            install_options => ['-t', 'stretch-backports'],
394        }
395
396        # T67354, T215693 - Tesseract OCR from stretch-backports
397        $tesseract_packages = [
398            'tesseract-ocr-all',
...
406        }
407
408        # T248376 - {python,python3}-requests from stretch-backports
409        $requests_packages = [
410            'python-requests',
412        ]
413        apt::pin { $requests_packages:
414            pin      => 'release a=stretch-backports',
415            priority => '2000',
416            before   => Package[$requests_packages],
418        package { $requests_packages:
419            ensure          => latest,
420            install_options => ['-t', 'stretch-backports'],
421        }
422

Didn't we replace tesseract with a newly packaged and compiled version, @aborrero? If we did, maybe that comment or something else needs to be removed?

Didn't we replace tesseract with a newly packaged and compiled version, @aborrero? If we did, maybe that comment or something else needs to be removed?

Yes, it's coming from the component/tesseract-410-bpo component. I'll submit a patch to update the comment.

Change 608966 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[operations/puppet@production] toolforge: Update comment reflecting source of tesseract packages

https://gerrit.wikimedia.org/r/c/operations/puppet/ /608966

@MoritzMuehlenhoff and I just discovered we need systemd >= 239 (from stretch-bpo) for Toolforge bastions for the resource limiting thing.

Didn't we replace tesseract with a newly packaged and compiled version, @aborrero? If we did, maybe that comment or something else needs to be removed?

This is true!

Yes, it's coming from the component/tesseract-410-bpo component. I'll submit a patch to update the comment.

Thanks for the patch! :-)

Bstorm added a comment.Jul 2 2020, 2:57 PM

@MoritzMuehlenhoff and I just discovered we need systemd >= 239 (from stretch-bpo) for Toolforge bastions for the resource limiting thing.

Ugh, I'd forgotten that. The version of SGE in buster is the same as in stretch, so upgrading would work if that wouldn't also suddenly upgrade the bastion's exec environment as well.

Change 608966 merged by Bstorm:
[operations/puppet@production] toolforge: Update comment reflecting source of tesseract packages

https://gerrit.wikimedia.org/r/c/operations/puppet/ /608966

@MoritzMuehlenhoff and I just discovered we need systemd >= 239 (from stretch-bpo) for Toolforge bastions for the resource limiting thing.

Ugh, I'd forgotten that. The version of SGE in buster is the same as in stretch, so upgrading would work if that wouldn't also suddenly upgrade the bastion's exec environment as well.

I've imported the current systemd version from stretch-backports (except the udebs, but those are irrelevant and only used for the Debian installer) into the component/systemd241. Could anyone check that these are fine with an existing Toolforge instance?

There are two classes (openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch which are pulling 'librados2', 'librgw2', 'librbd1', 'python-rados', 'python-rbd', 'ceph-common', 'python-cephfs', 'libradosstriper1' from stretch-backports. These will need to be mirrored to a local component.

There are two classes (openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch which are pulling 'librados2', 'librgw2', 'librbd1', 'python-rados', 'python-rbd', 'ceph-common', 'python-cephfs', 'libradosstriper1' from stretch-backports. These will need to be mirrored to a local component.

I will investigate a bit more about these. They are dependencies of the openstack suite, so it would make sense to have them in the osbpo repository.

===== NODE GROUP =====                                                                                   
(22) cloudvirt[1001-1003,1005,1007-1009,1012-1014,1017-1021,1023,1025-1030].eqiad.wmnet                  
----- OUTPUT of 'aptitude why librados2' -----                                                           
i   nova-common  Depends python3-nova (= 2:18.1.0-6+deb10u1~bpo9+1)                                      
i A python3-nova Depends python3-ceph                                                                    
i A python3-ceph Depends python3-rgw                               
i A python3-rgw  Depends librados2 (>= 0.72.2)

Change 610121 had a related patch set uploaded (by Muehlenhoff; owner: Muehlenhoff):
[operations/puppet@production] Remove stretch-backports from bootstrapvz config

https://gerrit.wikimedia.org/r/610121

Change 612612 had a related patch set uploaded (by Muehlenhoff; owner: Muehlenhoff):
[operations/puppet@production] Stop including backports on Stretch production hosts

https://gerrit.wikimedia.org/r/612612

Change 613611 had a related patch set uploaded (by Muehlenhoff; owner: Muehlenhoff):
[operations/puppet@production] Disable backports on stretch

https://gerrit.wikimedia.org/r/613611

Change 612612 abandoned by Muehlenhoff:
[operations/puppet@production] Stop including backports on Stretch production hosts

Reason:
Not going to bother with the spec mess

https://gerrit.wikimedia.org/r/612612

There are two classes (openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch which are pulling 'librados2', 'librgw2', 'librbd1', 'python-rados', 'python-rbd', 'ceph-common', 'python-cephfs', 'libradosstriper1' from stretch-backports. These will need to be mirrored to a local component.

I will investigate a bit more about these. They are dependencies of the openstack suite, so it would make sense to have them in the osbpo repository.

Did you hear back from the osbpo people? Otherwise let's copy these to something like component/ceph and include it in the openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch classes? These are the last remaining packages, otherwise https://gerrit.wikimedia.org/r/c/operations/puppet/+/613611 would be good to merge

There are two classes (openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch which are pulling 'librados2', 'librgw2', 'librbd1', 'python-rados', 'python-rbd', 'ceph-common', 'python-cephfs', 'libradosstriper1' from stretch-backports. These will need to be mirrored to a local component.

I will investigate a bit more about these. They are dependencies of the openstack suite, so it would make sense to have them in the osbpo repository.

Did you hear back from the osbpo people? Otherwise let's copy these to something like component/ceph and include it in the openstack::serverpackages::queens::stretch and openstack::serverpackages::rocky::stretch classes? These are the last remaining packages, otherwise https://gerrit.wikimedia.org/r/c/operations/puppet/+/613611 would be good to merge

Their suggestion was to mirror the stretch-backports repo and therefore workaround the archival :-P

This is all a bit annoying. I was very happy about no longer using components in our internal repo and not having to babysit packages.