We rely heavily on Debian jessie-backports repository to build both mitaka/jessie and mitaka/stretch servers.
I learned today that jessie-backports repo will be out of Debian mirrors network sooner than expected.
12:26 <moritzm> but with jessie being in LTS backports is closed 12:26 <moritzm> and will actually be removed once a Debian FTP master finds the time to do it 12:26 <moritzm> so puppet will fail on those 12:27 <moritzm> the more robust solution would have been to create a component/mitakajessie 12:27 <moritzm> import all the needed debs in there 12:27 <moritzm> and then pin the hosts to that component
I confirmed this by talking to Debian FTP/Backports masters:
12:35 <arturo> formorer: hi! just reading this https://lists.debian.org/debian-lts/2019/02/msg00101.html do you know of a tentative date for jessie-backports archival? I'm using it a lot :-S 12:35 <jcristau> ~now 12:36 <formorer> yesterday 12:36 <formorer> expect it at every time
If the Debian jessie-backports repo disappears, puppet will fail in all current CloudVPS servers, and we won't be able to re-image servers.
There are a couple of ways to avoid the disaster:
- use the repo directly from the archive:
deb http://archive.debian.org/debian-archive/debian/ jessie-backports main deb-src http://archive.debian.org/debian-archive/debian/ jessie-backports main
- import all the mitaka packages from Debian into the WMF reprepro as described in https://wikitech.wikimedia.org/wiki/Reprepro
While the first option is straight forward, and only involves a puppet patch to update the repo, in classes:
- openstack::serverpackages::mitaka::jessie
- openstack::serverpackages::mitaka::stretch
- openstack::clientpackages::mitaka::jessie
- openstack::clientpackages::mitaka::stretch
The second option allows us to retain the chance to patch packages if we need to. Will need the same puppet patch anyway to point to the new repo in apt.wikimedia.org.
This last approach is the one @MoritzMuehlenhoff recommended.