Add support for Xenial

[jugmac00]

What needs to get done

There is a user request from the desktop team for lpci to support Xenial builds.

craft-providers has Xenial support partially built-in, but the mapping to a remote image is missing.

When patching the mapping in via

craft-providers on  main [$!] via 🐍 (venv)
❯ git diff
diff --git a/craft_providers/lxd/remotes.py b/craft_providers/lxd/remotes.py
index 272722e..33e4ec2 100644
--- a/craft_providers/lxd/remotes.py
+++ b/craft_providers/lxd/remotes.py
@@ -123,6 +123,12 @@ class RemoteImage:

 # mapping from supported bases to actual lxd remote images
 _PROVIDER_BASE_TO_LXD_REMOTE_IMAGE: Dict[Enum, RemoteImage] = {
+ ubuntu.BuilddBaseAlias.XENIAL: RemoteImage(
+ image_name="xenial",
+ remote_name=BUILDD_RELEASES_REMOTE_NAME,
+ remote_address=BUILDD_RELEASES_REMOTE_ADDRESS,
+ remote_protocol=ProtocolType.SIMPLESTREAMS,
+ ),
     ubuntu.BuilddBaseAlias.BIONIC: RemoteImage(
         image_name="core18",
         remote_name=BUILDD_RELEASES_REMOTE_NAME,

I get a Xenial lpci build to kick off, but it fails as it seems to me that craft-providers uses a couple of commands and flags of snap(d) which were not present on the snap(d) default version on Xenial.

I am not sure whether that would mean that either

• the snap commands would need to get updated (for the Xenial case)
• a newer version of snap could be deployed to Xenial

Currently, after the above patch, a Xenial build fails with issues as snap uses the --hold flag, the wait command, and probably more. At one point I stopped patching.

Why it needs to get done

There is a request which was raised by the Desktop team (https://bugs.launchpad.net/lpci/+bug/2067284).

Their use case:

Ubuntu Pro is exposed to the user base through update-manager, so we need to keep it in shape from Noble until Xenial.

[mr-cal]

A bit of background:

Craft-providers never worked with xenial as the integration tests never tested it. I added a XXX/TODO for xenial in #219 here because of the similar snapd-related problems reported above and because Multipass doesn't have first-class support for launching xenial images.

Since we never got a request to support xenial, I dropped the XXX/TODO in #492.

@jugmac00 is absolutely on the right path here. The scope of work here is not trivial. One solution would be to abstract snapd behind a class to handle different snapd versions. Something like:

class Snapd:
  def hold_refreshes(self):
    if self.version > 2.62:
      subprocess.run(["snap", "refresh", "--hold"])
    else:
      subprocess.run(["snap", "set", "system", f"refresh.hold=2022-01-03T03:04:05.000006Z"])

    ...

We would have to do this for each snapd call.

This same issue will probably crop up again once other LTS releases like 18.04 or 20.04 stop receiving snapd updates too.

If I understand the request in LP#2067284 correctly, it sounds like this is not an urgent request. If that is true, perhaps this would be a good task for the next cycle.