should not be able to set target release to itself (unless MUPdate happened)?

[davepacheco]

Right now, we let you set the target release to itself, meaning that you get sequential rows in target_release like this:

root@[fd00:1122:3344:102::3]:32221/omicron> select * from target_release;
  generation |        time_requested         | release_source |             tuf_repo_id
-------------+-------------------------------+----------------+---------------------------------------
           1 | 2025-09-28 16:19:22.979405+00 | unspecified    | NULL
           2 | 2025-09-28 20:42:05.109875+00 | system_version | b7ea8d3d-0859-44c4-bc85-e4316c0d7b4d
           3 | 2025-09-28 20:54:14.246325+00 | system_version | 1e34627d-5676-4f6b-9910-a440a058981c
           4 | 2025-09-28 21:29:15.411675+00 | system_version | 6b0eba98-9e5e-4914-a152-04e0f9eef5d7
           5 | 2025-09-28 23:36:42.313402+00 | system_version | 6b0eba98-9e5e-4914-a152-04e0f9eef5d7
           6 | 2025-09-29 03:23:28.556873+00 | system_version | a69572a0-52c3-43a4-b8c0-77709b2fb77e
(6 rows) 

We expect this in the case of a MUPdate -- the operator has to re-establish their intent, even if it's the same release. But I'm not sure we want to allow this all the time. We could check the target blueprint to see if its min_generation is at least as new as the current one. If not, there's no reason to allow this.

[jgallagher]

(This is mostly summarizing a discussion from yesterday's update team sync about the details of addressing #8056.)

We could (should?) consider splitting the target_release_update external API into two different endpoints. Today, there are two different reasons to set a new target release:

1. You want to start an update to a new system version.
2. Support has performed a mupdate of one or more sleds, and recovering from that mupdate requires the operator to set a new target release to a system version that matches the version used in the mupdate.-

These are very different reasons, and also have somewhat different restrictions in the #8056 sense. Today with a single endpoint to handle both of these operations, our check has to be pretty loose:

• We must allow a new target release if we have evidence a mupdate has happened (e.g., zones running out of the install dataset), because we have to assume we're in case 2, and setting a new target release is the only way out.
• We want to reject new system versions to update to if any components are still running from the "current - 1" system version, because that's exactly Restrict changes to target_release during an update #8056: we can't update to version N+1 if we're still in the process of updating from N-1 to N.

If we split this into two endpoints, I think those checks become simpler and clearer:

• For the "start an update" endpoint, we could reject the request if there's any component that isn't running on the current target release. We get to ignore install dataset / mupdate issues entirely; those count as "not running on the current target release", so you can't start an update; instead, you need to recover from the mupdate first using the other endpoint.
• For the "recover from a mupdate" endpoint, we could reject the request if there's no evidence a mupdate has happened, because there's no reason to recover from a thing that hasn't happened.

[karencfv]

I was thinking of grabbing this issue next as it's the last one for R17, but it seems very intertwined with the work in #8056 from the above comment. Does it make sense for me to get started on this or not?

[jgallagher]

I don't think so; I'll have a PR up for #8056 soon and that should go into R17, but I think this issue can be deferred for afterwards.