sru-exception: add sru exception page for HWE virtualization stack

[hector-cao]

This is the initial draft for the SRU exception request for the HWE virtualization stack.

The first SRU will be done in Feb 2027 but I would like to bring that up to gather feedback so that the exception is ready
to be approved before we intend to proceed the first SRU for this requested exception.

[cpaelzer]

Good start, although I found a lot of "please have a look at this detail" comments - sorry

[cpaelzer]

Suggested change

	To mitigate the risk of breakage, we might decide to drop support for a particular
	To mitigate the risk of breakage or make it build, we might decide to drop support for a particular

[cpaelzer]

Didn't have as much time as I wanted, but a few more hints

[cpaelzer]

Suggested change

	from the last Ubuntu release (since it has the same upstream version), some specific testing is needed to ensure
	from the last Ubuntu release (since it has the same upstream version), further testing is needed to ensure

[cpaelzer]

So far you describe the intention, what this lacks is calling out how we will do so.
Would it make sense to point to the virtualization regression tests?

I'd expect that your improving rework will land in the same repo, so that pointer would even stay valid.

If you outline things in this section those tests are not yet doing you need to add them.
Until you did add/merge it with the main repo you need to point to the tests helpers you had when developing this.

Example - good: we want to test against migration issues
Example - better: we want to test against migration issues to do so we run this scrip with this config and provide the logfile

[basak]

AIUI, this isn't intended for SRU team review yet, pending Christian's comments being reviewed. Maybe we can use the PR Draft status for that? Let's see how well that works.

[matthewruffell]

How does this relate to / impact the virt stack backports for the Ubuntu Cloud Archive?

Currently UCA carries libvirt and qemu has HWE virt stack backports for each release. Should the OpenStack Team consider using this HWE virtualisation stack instead of doing their own backports?

What would UCA EOL look like compared to the rolling nature of this HWE stack if they were to change? For example, stonking will ship hibiscus, and resolute-hibiscus will have stonking's virt stack. But when TT comes out, the virt stack for resolute HWE will roll to TT, leaving a mismatch between resolute-hibiscus openstack and TT's HWE stack.

Should UCA be left as-is, meaning that users can stay on stonkings virt stack by just staying on resolute-hibiscus? Or should they accept the risk and move to TT's virt stack?

[cpaelzer]

AIUI, this isn't intended for SRU team review yet, pending Christian's comments being reviewed.

Yes,
The last few discussions that tried to settle rules/exceptions before example went back to "can we please see the real thing". At the same time prepping the real thing without any agreement might be a lot wasted effort as well.

We are trying to be good citizens by serving both needs

• On one side working a lot of this out and pre-discussing/agreeing as much as we can (this draft and discussion).
• But on the other we will "really ask to approve" once we have a real upload to go along that we can show in a PPA + tests

That still means whatever feedback, request for change you'd have would be appreciated to know.
But we'd not expect you to accept and land it until you can see the actual uploads and hold one to the other, which has a chance that we will make adjustments here before landing.

Maybe we can use the PR Draft status for that?

Yep, it is in draft

[cpaelzer]

How does this relate to / impact the virt stack backports for the Ubuntu Cloud Archive?

Hi Matthew,
It is a different solution for a different problem.

UCA does:
a) not always have such backports (rightfully so, only when they need it)
b) not always have all components (rightfully so, they pick what they need for the new openstack)
c) is an extra PPA bringing plenty of other things too which a user might want or not
d) not have a way to switch between the two (it is newer versions of the same, not alternatives to switch to)

Should the OpenStack Team consider using this HWE virtualisation stack instead of doing their own backports?

They could, but as you already identified they might run into trouble as they are less about "need the latest" which this HWE is about and more about "need that one which matches my openstack release". They might have a few months of "yep this is what we need" followed by "oh no now it rolled away and problem".

They can look at it, but I'd assume they still will "backport what and when they need it".
If they consider it actually fitting them well, they can certainly use it instead.

What would UCA EOL look like compared to the rolling nature of this HWE stack if they were to change?

The first and third interim release of an UCA would kind of match what the HWE stack does.
But using the very same might lock them together in a hard way making both sides harder without much gain.
Furthermore as you know the middle release has the extended times under Pro (https://canonical-openstack.readthedocs-hosted.com/en/latest/reference/release-cycle-and-supported-versions/) which would not fit well as by then the HWE stack would roll on.

Should UCA be left as-is, meaning that users can stay on stonkings virt stack by just staying on resolute-hibiscus? Or should they accept the risk and move to TT's virt stack?

As I said and hopefully explained "a different solution for a different problem" and "They can look at it, but I'd assume they still will backport what and when they need it".

[basak]

A couple of observations:

1. The mitigation is that users "opt in" by installing a distinctly different package. However, from experience, users do not know what they are opting into when they make such a package selection from the main archive. Typical users don't know what "hwe" means. I'm not sure that they expect a package description to include a disclaimer about properties that they expect to hold for every package in the archive. They just see the higher version available and select it while expecting that version to carry the same properties (and risk) as usual. In your draft you cover some places to note the different behaviour, but I don't think that the majority of users selecting this package will see that.

2. I don't see a downgrade path working for these packages. That's also something that effectively exists for kernel HWE, but hurts the UX in this case especially considering the previous point and the higher risk of something going wrong as you've identified.

I remain open minded as to whether this is acceptable for the main archive or not, but I wanted to add the above to the set of downsides we should be discussing

[hector-cao]

Thanks Robie for the feedback

A couple of observations:

1. The mitigation is that users "opt in" by installing a distinctly different package. However, from experience, users do not know what they are opting into when they make such a package selection from the main archive. Typical users don't know what "hwe" means. I'm not sure that they expect a package description to include a disclaimer about properties that they expect to hold for every package in the archive. They just see the higher version available and select it while expecting that version to carry the same properties (and risk) as usual. In your draft you cover some places to note the different behaviour, but I don't think that the majority of users selecting this package will see that.

Please correct if I do not get your point correctly.

When users opt-in the HWE, I expect them to be aware of what they are installing on the system. They might not be aware of all the implications of installing such packages (like it will remove the base ones since they are mutually exclusive).

Users do not see just the the higher version, they also see the package names with the suffix -hwe.

2. I don't see a downgrade path working for these packages. That's also something that effectively exists for kernel HWE, but hurts the UX in this case especially considering the previous point and the higher risk of something going wrong as you've identified.

By "downgrade", you mean going back to a previous version of the HWE stack ? IIUC, The HWE kernel can afford to do that because each HWE version is a different source package, that is not the case for virt HWE stack.
To lower the risk of regressions, we already adopted a conservative release schedule. The regressions that might not be covered by this are about the compatibility and integration within the current LTS. That should be mitigated with integration testing.

I remain open minded as to whether this is acceptable for the main archive or not, but I wanted to add the above to the set of downsides we should be discussing

Thanks. I agree.