[Bug 1989179] Re: "Try again" mechanism for snaplist comes with no guarantee that snaps will be installed

[Dan Bungert]

We believe this issue has been resolved in Subiquity 23.04.2.

If you had tested this with a pre-final version of Ubuntu 23.04, it's
recommended to download the final install media.

For testing with Ubuntu Server 22.04.x or 20.04.x, when running
Subiquity, you should offered a new version of the installer.  Please
take that update to version 23.04.2 or later to get the fix.

If this is still a problem for you, please make a comment and set the state
back to New.  Thank you for the bug report.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to subiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1989179

Title:
  "Try again" mechanism for snaplist comes with no guarantee that snaps
  will be installed

Status in subiquity package in Ubuntu:
  Fix Released

Bug description:
  When reaching the snaps selection section, some scenarios will cause
  Subiquity to show the following message:

  ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
   Featured Server Snaps                  [ Help ]
  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
  Sorry, loading snaps from the store failed.

                   [ Try again  ]
                   [ Continue   ]

  
  If the error was caused by something temporary, the list of snaps might load successfully after hitting "Try again". And if it does, the user can then select snaps to install.

  The problem is that when subiquity shows this "Try again" window, the
  server has already marked the snaplist model configured. Therefore,
  the installation may or may not have already generated the cloud-
  config configuration by the time the user selects the snaps they want
  to get installed.

  If the cloud-config was already generated, the snaps selected by the
  user are ignored and do not get installed by cloud-init.

  Technical details:
  GET /snaplist will mark the snaplist model configured if the result is FAILED.

  subiquity/server/controllers/snaplist.py

      async def GET(self, wait: bool = False) -> SnapListResponse:
          if self.loader.failed or not self.app.base_model.network.has_network:
              await self.configured()
              return SnapListResponse(status=SnapCheckState.FAILED)
          if not self.loader.snap_list_fetched and not wait:
              return SnapListResponse(status=SnapCheckState.LOADING)
          await self.loader.get_snap_list_task().wait()
          if self.loader.failed or not self.app.base_model.network.has_network:
              await self.configured()
              return SnapListResponse(status=SnapCheckState.FAILED)
          return SnapListResponse(
              status=SnapCheckState.DONE,
              snaps=self.model.get_snap_list(),
              selections=self.model.selections)

  IMO it makes sense to allow the user/client to retry (or at least
  decide what to do) when this type of error (generally caused by the
  network) is encountered. If we want to keep a retry mechanism in
  place, we should not mark the models configured automatically -
  especially the last one.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1989179/+subscriptions