Bug #11857

Provide IUK to go from version n-2 to version n

Added by sajolida 2016-10-02 17:49:23 . Updated 2017-02-01 13:40:29 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails 2.10
Start date:
2016-10-02
Due date:
% Done:

100%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:

Starter:
Affected tool:
Upgrader
Deliverable for:

Description

According to Feature #10478#note-3 this would be used by ~30% of our users during the first week of a release and ~15% over the full release cycle. So, if we managed to make IUKs easier to provide (maybe Feature #6309 helped on this) we could consider this.

Maybe some interesting data to have would be to know how much this would cost (in additional working time, possible bugs, infrastructure, etc.).

Note that allowing people to skip IUKs by going directly from n-2 to n might also fill their system partition slower (Feature #11627).

Subtasks

Related issues

Related to Tails - Feature #10478: Do statistics on upgrade paths Resolved 2015-11-04
Related to Tails - Feature #11627: Consider updating the default system partition's size Resolved 2016-08-10
Related to Tails - Feature #8142: Offer different upgrade options for older Tails, depending on whether incremental upgrades are possible Resolved 2014-10-16

History

#1 Updated by sajolida 2016-10-02 17:49:43

  • related to Feature #6309: Write tests for incremental upgrades added

#2 Updated by sajolida 2016-10-02 17:50:14

#3 Updated by sajolida 2016-10-02 17:50:30

  • related to Feature #11627: Consider updating the default system partition's size added

#4 Updated by sajolida 2016-10-02 17:51:21

  • Assignee set to intrigeri

intrigier (or anonym): do you want to provide some info regarding the cost of this?

#5 Updated by intrigeri 2016-10-03 07:51:16

  • Assignee changed from intrigeri to anonym
  • Target version set to Tails_2.9.1
  • QA Check set to Info Needed

> Maybe some interesting data to have would be to know how much this would cost (in additional working time, possible bugs, infrastructure, etc.).

  • Initial working time: a few hours adapting our release process doc and helper scripts ⇒ no big deal
  • Working time for each release: less than 1 hour ⇒ no big deal
  • Time to remediation for each release: time to upload one more (possibly bigger) IUK, so depends a lot on the RM’s bandwidth (until we have reproducible IUKs that allow us to build them directly on our server); in my case, that would be about 4-6 hours ⇒ that’s not to be ignored in particular for emergency releases
  • Possible bugs: nothing I can think of
  • Infrastructure: nothing I can think of
  • Added complexity developers and doc writers have to take into account, e.g. when we go through migrations (I’m thinking of the persistent volume permissions change we did a couple years ago, or when our website changes X.509 certificates, or when we change our signing key somehow): substantial; this is the point I’m most concerned about, that makes me doubt if the whole thing is worth it

Next thing to do: build a N-2→N IUK for some release, and report about its size. I’m curious how much bigger it’ll be than the N-1→N IUK, and how much smaller it’ll be than N-2→N-1 + N-1→N. anonym, can you please do that during the 2.8 release cycle, while you’ll have the tools and doc handy? (I’d rather not bother bertagaz about it for his first RM’ing session.)

#6 Updated by anonym 2016-10-03 18:07:33

  • QA Check deleted (Info Needed)
  • Type of work changed from Discuss to Code

intrigeri wrote:
> * Working time for each release: less than 1 hour ⇒ no big deal

Just for the record, I would not call something that is potentially close to 1 hour during the release process as “no big deal”. Luckily we’re talking about maybe 1 minute of RM attention.

> Next thing to do: build a N-2→N IUK for some release, and report about its size. I’m curious how much bigger it’ll be than the N-1→N IUK, and how much smaller it’ll be than N-2→N-1 + N-1→N.

I don’t think size is the only factor. Having to reboot and deal with the same thing again is also a pain. So, even if such a 2-step IUK is barely smaller than the two 1-step ones, I think it should be considered.

> anonym, can you please do that during the 2.8 release cycle, while you’ll have the tools and doc handy? (I’d rather not bother bertagaz about it for his first RM’ing session.)

Yup, I’ll do this!

#7 Updated by sajolida 2016-10-04 00:31:23

> * Added complexity developers and doc writers have to take into account, e.g. when we go through migrations (I’m thinking of the persistent volume permissions change we did a couple years ago, or when our website changes X.509 certificates, or when we change our signing key somehow): substantial; this is the point I’m most concerned about, that makes me doubt if the whole thing is worth it

Could we skip providing N-2→N in some occasions when we think it might
complicate migrations too much?

#8 Updated by intrigeri 2016-10-04 06:59:38

> Could we skip providing N-2→N in some occasions when we think it might complicate migrations too much?

Sure, good idea! :)

#9 Updated by intrigeri 2016-10-04 07:00:14

> I don’t think size is the only factor. Having to reboot and deal with the same thing again is also a pain. So, even if such a 2-step IUK is barely smaller than the two 1-step ones, I think it should be considered.

Absolutely agreed! It’s just one factor among others.

> Yup, I’ll do this!

Thank you.

#10 Updated by anonym 2016-12-12 19:35:17

Given the 2.7.1 emergency release, and that sajolida’s data probably is based on when there was no emergency release, I generated three IUKs:

328M Tails_i386_2.6_to_2.9.iuk
198M Tails_i386_2.7_to_2.9.iuk
175M Tails_i386_2.7.1_to_2.9.iuk


Note that generating these isn’t much of a pain for the RM since it can be done in parallel with everything that follows, except that it blocks the “Incremental upgrades” manual test. Each take about 10 minutes to generate.

Hm. I just go a (perhaps only half) crazy idea to (more or less) achieve endless automatic upgrades… will comment on Feature #11131.

#11 Updated by anonym 2016-12-14 20:11:27

  • Target version changed from Tails_2.9.1 to Tails 2.10

#12 Updated by intrigeri 2017-01-02 17:58:49

  • related to deleted (Feature #6309: Write tests for incremental upgrades)

#13 Updated by anonym 2017-01-06 12:06:01

  • Status changed from Confirmed to In Progress
  • Assignee changed from anonym to sajolida
  • % Done changed from 0 to 30
  • QA Check set to Info Needed

So, what is the next step? IMHO providing IUKs for all versions since the n-2 planned releases is essentially no work. With my RM hat on, I approve.

#14 Updated by sajolida 2017-01-16 19:23:59

  • Assignee changed from sajolida to anonym
  • QA Check deleted (Info Needed)
  • Type of work changed from Code to Contributors documentation

I don’t need to change anything in the doc to adjust to that. Maybe you have to adjust the release process to remember that. Then I think we can close this ticket!

#15 Updated by anonym 2017-01-20 11:06:24

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 30 to 100

Implemented in commit:a3e950662f (currently only in the testing branch). I’ll test them when I prepare Tails 2.10.

#16 Updated by anonym 2017-01-24 20:42:51

  • Status changed from Fix committed to Resolved

#17 Updated by intrigeri 2017-02-01 13:38:22

  • related to Feature #8142: Offer different upgrade options for older Tails, depending on whether incremental upgrades are possible added

#18 Updated by intrigeri 2017-02-01 13:40:29

One problem with this approach is that in theory, some computers could have enough RAM to upgrade from n-2 to n-1 and then from n-1 to n, but not enough to apply the (larger) upgrade from n-2 to n. Not a big deal in most cases I guess, but I thought I’d mention it.