Public bug reported:

As part of our offerings to bring Ubuntu Pro to wider audiences we need
to backport this service to Ubuntu 22.04 LTS, so users can benefit of
the upcoming GA of Ubuntu Pro for WSL, as Windows system that allows
more easily secure and manage WSL instances, by automatically pro-
attaching Ubuntu on WSL instances and even register with and manage them
via Lansdcape.

wsl-pro-service is our bridge to the Windows application that performs
key  post-provisioning actions on an instance, such as updating a Pro
token and Landscape configuration data if that changes on the Windows
side.

As this service is only applicable for Ubuntu on WSL, its systemd unit is 
contained to not even start
if the condition `ConditionVirtualization=wsl` is unmet. systemd confinement 
options were validated to work on Jammy as of wsl-pro-service version 0.1.18 
(the one being proposed via this SRU).

[Impact]

* wsl-pro-service is a new package for Jammy
* It depends on golang-1.23-go at build time, which is available on 
jammy-updates.
* Ubuntu Pro for WSL relies on this service being seeded on the Ubuntu 
instances.
* That system is not yet generally available, but planned for later this year.
* At minimum Jammy and Noble must be supported, but Focal is planned (provided 
the toolchain is also backported, see and LP: #2103997 and LP: #2085834).
* Beta customers were already provided with custom images of 22.04 and 24.04 
from the get-go.
* As a new daemon, more often inert if the Windows side is not present, this 
should not affect users experience on Jammy.
* Boot time measurements reveals negligible impact.
* The systemd unit is carefully and purposefully confined to allow only minimum 
requirements of our application while remaining compatible with systemd v245 
(thus, compatible with Jammy).

[ Test plan ]

== 1. Less loging:

* Make sure the Ubuntu Pro for WSL Windows agent is not running:
  - On Windows run `taskkill /f /im ubuntu-pro-agent.exe`
  - Depending on the OS settings elevated permissions might be required.
* Install wsl-pro-service version 0.1.18 on Ubuntu 22.04 on WSL.
* Follow it's journal with `journalctl -f -u wsl-pro.service`
* Notice that it starts logging connection attempts too often, backing off 
exponentially up to 1min interval.
  Approximately 10 minutes after attempting to connect without success, it 
silents.
* systemd should take approximately 20 min to attempt to restart the unit.

== 2. Pro attachment works under systemd restrictions and without
livepatch being installed.

(Most of this test case would be testing ubuntu-pro-client v35 indeed, but we 
must verify that our integration
is not harmed with the changes in wsl-pro-service systemd confinement)

* Create a fresh instance of Ubuntu on WSL:
  - On Windows run `wsl.exe --install -d Ubuntu-22.04`
* Install ubuntu-pro-agent v35 (currently available via the `-proposed` 
repository)
* Make sure livepatch is not installed: `sudo snap remove canonical-livepatch`
* Make sure the Ubuntu on WSL instance is not pro attached: `pro status` (`pro 
detach` if needed).
* Install wsl-pro-service version 0.1.18 on Ubuntu on WSL (Noble, Oracular and 
Plucky should behave exactly
the same)
* Install Ubuntu Pro for WSL (download the latest production build from 
https://github.com/canonical/ubuntu-pro-for-wsl/actions/runs/14386282882/artifacts/2921576467)
* Follow this guide to attach your Pro token: 
https://documentation.ubuntu.com/wsl/en/stable/tutorials/getting-started-with-up4w/#set-up-ubuntu-pro-for-wsl
* Follow it's journal with `journalctl -f -u wsl-pro.service`:
  - If pro-attaching fails because of systemd restrictions we should see some 
"permission denied" or "bad system
  call" errors in the journal.
  - If the livepatch fix was not correct, we should see mentions to 
`canonical-livepatch` in the journal.
  - Both conditions should be considered a failure. Otherwise, proceed.
* Confirm pro attachment `pro status` inside the Ubuntu instance.
* Finally assert that canonical-livepatch remains not installed on this machine.

== 3. (Optional) wsl-pro-service outside of WSL

(Ensures the unit does nothing outside of WSL)

* Install wsl-pro-service on an instance of Ubuntu 22.04 on any platform other 
than WSL (Desktop,
Server bare-metal or VM, OCI containers).
* Verify that the unit is disabled due unmet condition: `systemctl status 
wsl-pro.service`


== 4. (Optional) Boot time

(Ensures the unit does not significantly impact the boot time duration)
* Install wsl-pro-service on an Ubuntu 22.04 instance on WSL.
* Modify the default user's .bashrc to just exit (by appending `exit` as the 
last line of that script)
* On Windows PowerShell run `wsl --terminate Ubuntu-22.04; Measure-Command {wsl 
-d Ubuntu-22.04}` a few times and take notes of the duration that command takes 
to finish
* Start the WSL instance as root `wsl -d Ubuntu-22.04 -u root`
* Remove wsl-pro-service
* Repeat the measurement step
* Compare the results. 

Spot differences are expected, because of the many layers involved, but
there should not be more than 2% difference in **median** between boot
times with and without that service enabled, per recent measurements
taken by our team.


[ Where problems could occur ]

The few beta customers we have might have noticed that up until now, 
wsl-pro-service remains running all the time the unit is alive, thus anytime a 
user installs the
Ubuntu Pro for WSL application on Windows they could expect the communication 
with the Windows agents to start
briefly. That's also the case for the custom 22.04 images they've been playing 
with, which come with wsl-pro-service 0.1.5.

With the behaviour changes in v0.1.18, that won't be the case always, as the 
service could just had quit seconds before
and systemd will take about 20min to restart it. Users can always `sudo 
systemctl restart wsl-pro.service`.

Since the entire system is not yet generally available the number of users 
affected by this behaviour change
is very minimal, comprising of a handful of beta testers and internal 
collaborators (such as the
Landscape team).

If the changes in wsl-pro-service landed before ubuntu-pro-client v35, we'd 
have issues with livepatch already
described. I judge that as almost impossible since the SRU bug LP: #2083973 is 
older and is very likely to
handle any regressions in time.

[ Other Info ]

I intentionally skipped testing the changes related to Landscape because it's 
too complex to set up a server
just for this purpose.

** Affects: wsl-pro-service (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: wsl-pro-service (Ubuntu Jammy)
     Importance: Undecided
         Status: New

** Also affects: wsl-pro-service (Ubuntu Jammy)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to wsl-pro-service in Ubuntu.
https://bugs.launchpad.net/bugs/2107145

Title:
  [SRU] Backport wsl-pro-service to Jammy

Status in wsl-pro-service package in Ubuntu:
  New
Status in wsl-pro-service source package in Jammy:
  New

Bug description:
  As part of our offerings to bring Ubuntu Pro to wider audiences we
  need to backport this service to Ubuntu 22.04 LTS, so users can
  benefit of the upcoming GA of Ubuntu Pro for WSL, as Windows system
  that allows more easily secure and manage WSL instances, by
  automatically pro-attaching Ubuntu on WSL instances and even register
  with and manage them via Lansdcape.

  wsl-pro-service is our bridge to the Windows application that performs
  key  post-provisioning actions on an instance, such as updating a Pro
  token and Landscape configuration data if that changes on the Windows
  side.

  As this service is only applicable for Ubuntu on WSL, its systemd unit is 
contained to not even start
  if the condition `ConditionVirtualization=wsl` is unmet. systemd confinement 
options were validated to work on Jammy as of wsl-pro-service version 0.1.18 
(the one being proposed via this SRU).

  [Impact]

  * wsl-pro-service is a new package for Jammy
  * It depends on golang-1.23-go at build time, which is available on 
jammy-updates.
  * Ubuntu Pro for WSL relies on this service being seeded on the Ubuntu 
instances.
  * That system is not yet generally available, but planned for later this year.
  * At minimum Jammy and Noble must be supported, but Focal is planned 
(provided the toolchain is also backported, see and LP: #2103997 and LP: 
#2085834).
  * Beta customers were already provided with custom images of 22.04 and 24.04 
from the get-go.
  * As a new daemon, more often inert if the Windows side is not present, this 
should not affect users experience on Jammy.
  * Boot time measurements reveals negligible impact.
  * The systemd unit is carefully and purposefully confined to allow only 
minimum requirements of our application while remaining compatible with systemd 
v245 (thus, compatible with Jammy).

  [ Test plan ]

  == 1. Less loging:

  * Make sure the Ubuntu Pro for WSL Windows agent is not running:
    - On Windows run `taskkill /f /im ubuntu-pro-agent.exe`
    - Depending on the OS settings elevated permissions might be required.
  * Install wsl-pro-service version 0.1.18 on Ubuntu 22.04 on WSL.
  * Follow it's journal with `journalctl -f -u wsl-pro.service`
  * Notice that it starts logging connection attempts too often, backing off 
exponentially up to 1min interval.
    Approximately 10 minutes after attempting to connect without success, it 
silents.
  * systemd should take approximately 20 min to attempt to restart the unit.

  == 2. Pro attachment works under systemd restrictions and without
  livepatch being installed.

  (Most of this test case would be testing ubuntu-pro-client v35 indeed, but we 
must verify that our integration
  is not harmed with the changes in wsl-pro-service systemd confinement)

  * Create a fresh instance of Ubuntu on WSL:
    - On Windows run `wsl.exe --install -d Ubuntu-22.04`
  * Install ubuntu-pro-agent v35 (currently available via the `-proposed` 
repository)
  * Make sure livepatch is not installed: `sudo snap remove canonical-livepatch`
  * Make sure the Ubuntu on WSL instance is not pro attached: `pro status` 
(`pro detach` if needed).
  * Install wsl-pro-service version 0.1.18 on Ubuntu on WSL (Noble, Oracular 
and Plucky should behave exactly
  the same)
  * Install Ubuntu Pro for WSL (download the latest production build from 
https://github.com/canonical/ubuntu-pro-for-wsl/actions/runs/14386282882/artifacts/2921576467)
  * Follow this guide to attach your Pro token: 
https://documentation.ubuntu.com/wsl/en/stable/tutorials/getting-started-with-up4w/#set-up-ubuntu-pro-for-wsl
  * Follow it's journal with `journalctl -f -u wsl-pro.service`:
    - If pro-attaching fails because of systemd restrictions we should see some 
"permission denied" or "bad system
    call" errors in the journal.
    - If the livepatch fix was not correct, we should see mentions to 
`canonical-livepatch` in the journal.
    - Both conditions should be considered a failure. Otherwise, proceed.
  * Confirm pro attachment `pro status` inside the Ubuntu instance.
  * Finally assert that canonical-livepatch remains not installed on this 
machine.

  == 3. (Optional) wsl-pro-service outside of WSL

  (Ensures the unit does nothing outside of WSL)

  * Install wsl-pro-service on an instance of Ubuntu 22.04 on any platform 
other than WSL (Desktop,
  Server bare-metal or VM, OCI containers).
  * Verify that the unit is disabled due unmet condition: `systemctl status 
wsl-pro.service`

  
  == 4. (Optional) Boot time

  (Ensures the unit does not significantly impact the boot time duration)
  * Install wsl-pro-service on an Ubuntu 22.04 instance on WSL.
  * Modify the default user's .bashrc to just exit (by appending `exit` as the 
last line of that script)
  * On Windows PowerShell run `wsl --terminate Ubuntu-22.04; Measure-Command 
{wsl -d Ubuntu-22.04}` a few times and take notes of the duration that command 
takes to finish
  * Start the WSL instance as root `wsl -d Ubuntu-22.04 -u root`
  * Remove wsl-pro-service
  * Repeat the measurement step
  * Compare the results. 

  Spot differences are expected, because of the many layers involved,
  but there should not be more than 2% difference in **median** between
  boot times with and without that service enabled, per recent
  measurements taken by our team.


  [ Where problems could occur ]

  The few beta customers we have might have noticed that up until now, 
wsl-pro-service remains running all the time the unit is alive, thus anytime a 
user installs the
  Ubuntu Pro for WSL application on Windows they could expect the communication 
with the Windows agents to start
  briefly. That's also the case for the custom 22.04 images they've been 
playing with, which come with wsl-pro-service 0.1.5.

  With the behaviour changes in v0.1.18, that won't be the case always, as the 
service could just had quit seconds before
  and systemd will take about 20min to restart it. Users can always `sudo 
systemctl restart wsl-pro.service`.

  Since the entire system is not yet generally available the number of users 
affected by this behaviour change
  is very minimal, comprising of a handful of beta testers and internal 
collaborators (such as the
  Landscape team).

  If the changes in wsl-pro-service landed before ubuntu-pro-client v35, we'd 
have issues with livepatch already
  described. I judge that as almost impossible since the SRU bug LP: #2083973 
is older and is very likely to
  handle any regressions in time.

  [ Other Info ]

  I intentionally skipped testing the changes related to Landscape because it's 
too complex to set up a server
  just for this purpose.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wsl-pro-service/+bug/2107145/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to