Merge ~adrien/ubuntu-archive-tools:phasing-openssl into ubuntu-archive-tools:main

[Adrien Nader]

Introduce a phasing at 5% for openssl. That will take close to 5 days. Using 2% instead would take close to 2 weeks. I don't have strong opinions on the best increment to use: feel free to edit the commit and change the increment.

As far as I know I am not able to test the change myself and I haven't seen a testsuite. Still, I used flake8 to gain confidence that I wasn't introducing simple mistakes.

[Utkarsh Gupta (utkarsh)]

Whilst it looks OK to me, I'll let another core-dev/AA review and land it.

review: Approve

[Steve Langasek (vorlon)]

review: Needs Fixing

[Steve Langasek (vorlon)]

> A 1% increment would require close to 4 weeks to complete and it is very
> likely that an openssl security update would be released in that
> timeframe and would fast-forward the phasing, effectively causing the
> last increment to be large, probably around 40%.

FWIW this isn't very compelling to me. We ALWAYS fast-forward in the case of a security update, that's a known tradeoff; we don't need to be pushing the non-security update out to users faster in the meantime because of the *possibility* that there will be a security update that expedites things. If a 4-week spread would otherwise be the right cadence, then we should stick with that.

Also, the intervals between the last few security releases of openssl on jammy have been: 5 months, 1 month, 2 months, 3 months. So it's not *that* likely that an SRU will be clobbered by a security update before it finishes phasing...

[Adrien Nader (adrien)]

Thanks for the reviews.

The fact that it uses source package names makes sense. I was unsettled by the grub examples which I had assumed were binary packages: I didn't expect so many different source packages! I should have checked nonetheless. :)

About the phasing speed: it seemed to me that grub and shim are very high risk packages while openssl is lesser risk but still more than most packages. The goal was to find a balance: if there's 50% chance that the openssl phasing never goes above 60% before being fast-forwarded, then we're probably missing on some inputs we get from the phasing.

A 1% phasing takes almost a month to complete. On average with the values you've given, there has been an openssl update very 2.75 months or so (and I think it makes sense to be pessimistic here). With the last openssl security update, I had to respin my changes, test them again, get the approved and uploaded again, wait for tests to succeed, and then wait for a review. When you sum all of these, they start taking a serious chunk of these 2.75 months. The motivation for this MR is that there are plenty of constraints and they should be balanced in order to maximize their usefulness. Another constraint is that the security team would like that we refrain from uploading a couple weeks before the release of the security update to avoid conflicts.

Briand agreed on the idea of having intermediate phasing speed when we discussed that in Riga but clearly I'm fine with speed that is deemed appropriate by the people who have more experience with SRUs than I do.

PS: I was also intending to push other openssl SRUs in the future, not just the current one, but I'm more and more thinking that there might not be others considering this one is not moving forward (this isn't a criticism of anyone; instead it's an interesting data point on the topic of openssl SRUs)

review: Needs Fixing

[Steve Langasek (vorlon)]

> [Brian] agreed on the idea of having intermediate phasing speed when we discussed
> that in Riga but clearly I'm fine with speed that is deemed appropriate by the
> people who have more experience with SRUs than I do.

I'm ok with phasing at 5%, I just don't think the particular bit I cited is compelling as a rationale for it. Our phasing rate should be set on what we think is an appropriate rate for the non-security case, not based on a concern that it will be trumped by a security update.

So this is fine, once the code is fixed to use source packages instead of binary.

> PS: I was also intending to push other openssl SRUs in the future, not just the
> current one, but I'm more and more thinking that there might not be others
> considering this one is not moving forward

This SRU was uploaded during the roadmap sprint, which was followed by the engineering sprint and a good deal of PTO; I don't think you should make any sort of generalization about openssl SRUs based on an upload during this timeframe.

[Steve Langasek (vorlon)]

review: Approve

diff --git a/phased-updater b/phased-updater
index 3fc2872..a1c2aea 100755
--- a/phased-updater
+++ b/phased-updater
@@ -732,6 +732,8 @@ def main():
                 new_pup = current_pup + PUP_INCREMENT
                 if src_pkg in SLOW_PACKAGES:
                     new_pup = current_pup + PUP_SLOW_INCREMENT
+                if src_pkg in MEDIUM_PACKAGES:
+                    new_pup = current_pup + PUP_MEDIUM_INCREMENT
                 if src_pkg in FULLY_PHASED_PACKAGES:
                     new_pup = 100
                 if not options.no_act:
@@ -769,7 +771,11 @@ if __name__ == '__main__':
         'grub2', 'grub2-unsigned', 'grub2-signed',
         'shim', 'shim-signed',
     }
+    MEDIUM_PACKAGES = {
+        'openssl',
+    }
     PUP_SLOW_INCREMENT = 1
+    PUP_MEDIUM_INCREMENT = 5
     FULLY_PHASED_PACKAGES = ('livecd-rootfs')
     REPORT_FILE = 'phased-updates.html'
     parser = OptionParser(usage="usage: %prog [options]")