Project

General

Profile

Feature #12505

Feature #5630: Reproducible builds

Switch isobuilders to vagrant-libvirt in Puppet

Added by bertagaz 7 months ago. Updated 27 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
05/03/2017
Due date:
% Done:

70%

QA Check:
Dev Needed
Feature Branch:
puppet-tails:feature/11972-use-vagrant-in-jenkins
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

This ticket is meant to track the puppet part of the implementation of vagrant-libvirt on our Jenkins isobuilders. The tails.git part has been achieved in #11972. #11972#note-5 and following notes contain some initial review from intrigeri, that needs to be addressed. The complete switch in puppet also needs to be finished in a dedicated branch of puppet-tails.

History

#1 Updated by bertagaz 7 months ago

  • Related to Feature #11972: Switch our Jenkins ISO build system to vagrant-libvirt added

#2 Updated by bertagaz 7 months ago

  • Assignee changed from bertagaz to intrigeri
  • QA Check changed from Dev Needed to Info Needed

I think all remarks made in the initial review (#11972#note-5 to #11972#note-13) has been addressed.

All the Puppet code is also already written in the feature branch, as the plan is to re-install all Jenkins isobuilders to stretch one by one, each time setting them to tails::jenkins::slave::iso_builder::use_vagrant: true in hiera so that they switch to vagrant based builds.
Once they all have migrated, the use_vagrant condition in ::tails::jenkins::slave::iso_builder will be removed, as well as any traces of ::tails::builder.

Does this make sense?

One black hole in this is how to manage the sib isobuilder. What's your plan regarding this?

#3 Updated by intrigeri 7 months ago

Don't wait for me before you start implementing everything you want in a Puppet Git branch, otherwise everything will be delayed by possibly 1 week.

#4 Updated by intrigeri 7 months ago

  • Assignee changed from intrigeri to bertagaz
  • QA Check changed from Info Needed to Dev Needed

(As explained above, don't block on me at a time when I've announced I would be unavailable: go ahead and I'll review your stuff either in Git or once deployed.)

#5 Updated by intrigeri 7 months ago

bertagaz wrote:

Once they all have migrated, the use_vagrant condition in ::tails::jenkins::slave::iso_builder will be removed, as well as any traces of ::tails::builder.

Does this make sense?

Yes => please prepare this in a (preferably tested) branch and submit it for review.

One black hole in this is how to manage the sib isobuilder. What's your plan regarding this?

Just let me know what manual migration steps I have to do, on top of what Puppet does.

#6 Updated by bertagaz 7 months ago

  • Target version changed from Tails_3.0~rc1 to Tails_3.0

#7 Updated by intrigeri 7 months ago

  • Target version changed from Tails_3.0 to Tails_3.1

Please focus on actual breakage for now, this refactoring can wait a bit :)

#8 Updated by intrigeri 6 months ago

  • Priority changed from Elevated to Normal

#9 Updated by intrigeri 6 months ago

  • Related to deleted (Feature #11972: Switch our Jenkins ISO build system to vagrant-libvirt)

#10 Updated by intrigeri 6 months ago

  • Parent task set to #5630

#11 Updated by intrigeri 5 months ago

  • Target version changed from Tails_3.1 to Tails_3.2

intrigeri wrote:

Please focus on actual breakage for now, this refactoring can wait a bit :)

Same :)

#13 Updated by anonym 3 months ago

  • Target version changed from Tails_3.2 to Tails_3.3

#14 Updated by bertagaz about 2 months ago

  • Assignee changed from bertagaz to intrigeri
  • % Done changed from 0 to 50
  • QA Check changed from Dev Needed to Ready for QA

intrigeri wrote:

bertagaz wrote:

Once they all have migrated, the use_vagrant condition in ::tails::jenkins::slave::iso_builder will be removed, as well as any traces of ::tails::builder.

Yes => please prepare this in a (preferably tested) branch and submit it for review.

One black hole in this is how to manage the sib isobuilder. What's your plan regarding this?

Just let me know what manual migration steps I have to do, on top of what Puppet does.

Ok, pushed two commits in the puppet-tails repo branch fb72d65 and 304db9e.

The first one removes the use_vagrant condition and tails::builder call from the tails::jenkins::slaves::iso_builder manifest.

The second cleans up loeftovers from tails::builder and tails::website_builder in case some Stretch install out there is still running tails::builder.

I've taken the big hammer approach here, rather than customizing the to be deleted tails::builder manifest so that it would support $ensure = absent for all its resources. To migrate/test, one just have to merge this branch in its puppet-tails repo master.

#15 Updated by intrigeri about 2 months ago

  • Assignee changed from intrigeri to bertagaz
  • % Done changed from 50 to 70
  • QA Check changed from Ready for QA to Dev Needed

README still references tails::builder.

Wrt. "when we decide every installations had time to switch": if that's about isobuilder1.sib, forget about it (I had to fully reinstall it when we switched to Vagrant anyway, so there's nothing to clean up there); and IIRC isobuilder*.lizard have been fully reinstalled too, so perhaps this code won't be needed in the end… which may avoid having to track this "XXX" at all :) If it's really needed: the $preferences_snippets, $packages and $files variables in the if $cleanup_pre_vagrant_build_deps block have too generic names. But they seem useless anyway so please just get rid of them.

Please sort lines in $builder_packages (tails::iso_builder).

Other than this, looks good, feel free to deploy when you're in a good position to deal with the potential fallout.

Meta: I have no idea if the proposed branch has been tested, because you didn't tell and it's unclear to me what's the default/implicit in this area these days. So please either clearly tell me what's your default/implicit (and then only communicate about specific exceptions on a case by case basis), or communicate explicitly about the tests that were done every time you submit a branch. E.g. for code changes, the default is that one submits branches for QA after building & testing them, and occasionally we skip this step but make it clear when submitting for QA that it's not been tested. This seems like a reasonable approach to me and avoids reviewers wasting time wondering/commenting about stuff that cannot possibly work. YMMV.

#16 Updated by anonym 27 days ago

  • Target version changed from Tails_3.3 to Tails_3.5

Also available in: Atom PDF