[Bug 2121443] [NEW] [FFe] Improved API for reporting storage recoverable errors

[Olivier Gayot]

Public bug reported:

Request
-------

We want subiquity to ship an improved way to handle recoverable user
errors in the /storage API.

Typically, the type of error that we are talking about here is an error
caused by the user requesting something that can't be satisfied, or
isn't supported such as:

 * disk does not support boot partition
 * new partition too large
 * setting the partition name is not implemented.
 * ...

And more rarely, this is caused by the client not using the API
properly:

 * changing partition format requires a wipe value

Going forward, the goal is to give the client enough information to:
 
 * make the error clearly visible to the user (so they know what they should adjust before retrying)
 * let the user decide if they want to report a bug

Currently though, what happens by default when using the desktop installer is the following:
 * subiquity runs into the error
 * subiquity creates a crash report
 * subiquity returns HTTP 500 response
 * the error is not shown to the user (so they don't know what happened)
 * a "system crash detected" dialog is opened by apport

Last cycle, we introduced a feature flag (i.e., --no-report-storage-user-error) which was a step in the right direction. When used, this flag made subiquity:
 * not produce a crash report when it runs into a recoverable error
 * return HTTP 422 instead of HTTP 500

Unfortunately, this wasn't covering enough classes of errors, and not
providing sufficient information back to the user. So this feature flag
hasn't been enabled by the desktop installer.

We made a new implementation based on the problems details for HTTP APIs
RFC.

Why needed
----------
* We want the desktop installer to switch on the feature flag.
   * This should reduce the number of bug reports we get
   * This should give users an idea of what to adjust, and therefore increase the number of successful installations.

What changed
------------
In the situation described above, the response returned by subiquity now contains:

* An x-error-code field containing the class of error (i.e., storage-invalid-usage, storage-contraint-violated or storage-not-found currently)
* x-error-title field containing a translated title for the error. E.g., "Invalid use of storage endpoint"

The above is inspired from the problems details for HTTP APIs (RFC 9457)

In addition, more errors have not been converted to user recoverable
errors, e.g.:

 * edit_partition does not support changing size

** Affects: subiquity
     Importance: Undecided
         Status: New

** Affects: subiquity (Ubuntu)
     Importance: Undecided
         Status: New

** Also affects: subiquity (Ubuntu)
   Importance: Undecided
       Status: New

** No longer affects: probert

** Also affects: subiquity
   Importance: Undecided
       Status: New

-- 
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/2121443

Title:
  [FFe] Improved API for reporting storage recoverable errors

Status in subiquity:
  New
Status in subiquity package in Ubuntu:
  New

Bug description:
  Request
  -------

  We want subiquity to ship an improved way to handle recoverable user
  errors in the /storage API.

  Typically, the type of error that we are talking about here is an
  error caused by the user requesting something that can't be satisfied,
  or isn't supported such as:

   * disk does not support boot partition
   * new partition too large
   * setting the partition name is not implemented.
   * ...

  And more rarely, this is caused by the client not using the API
  properly:

   * changing partition format requires a wipe value

  Going forward, the goal is to give the client enough information to:
   
   * make the error clearly visible to the user (so they know what they should adjust before retrying)
   * let the user decide if they want to report a bug

  Currently though, what happens by default when using the desktop installer is the following:
   * subiquity runs into the error
   * subiquity creates a crash report
   * subiquity returns HTTP 500 response
   * the error is not shown to the user (so they don't know what happened)
   * a "system crash detected" dialog is opened by apport

  Last cycle, we introduced a feature flag (i.e., --no-report-storage-user-error) which was a step in the right direction. When used, this flag made subiquity:
   * not produce a crash report when it runs into a recoverable error
   * return HTTP 422 instead of HTTP 500

  Unfortunately, this wasn't covering enough classes of errors, and not
  providing sufficient information back to the user. So this feature
  flag hasn't been enabled by the desktop installer.

  We made a new implementation based on the problems details for HTTP
  APIs RFC.

  Why needed
  ----------
  * We want the desktop installer to switch on the feature flag.
     * This should reduce the number of bug reports we get
     * This should give users an idea of what to adjust, and therefore increase the number of successful installations.

  What changed
  ------------
  In the situation described above, the response returned by subiquity now contains:

  * An x-error-code field containing the class of error (i.e., storage-invalid-usage, storage-contraint-violated or storage-not-found currently)
  * x-error-title field containing a translated title for the error. E.g., "Invalid use of storage endpoint"

  The above is inspired from the problems details for HTTP APIs (RFC
  9457)

  In addition, more errors have not been converted to user recoverable
  errors, e.g.:

   * edit_partition does not support changing size

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