Following up on #10796: in https://github.com/oxidecomputer/customer-support/issues/1372, we found a sequence where:
- Due to an operational issue, TUF artifact replication was not working. This wasn't caught because nothing was using it -- the system had only been MUPdated for updates.
- The rack was MUPdated to release N.
- The release N TUF repo was uploaded.
- Nexus began trying to resolve the MUPdate and its artifacts. Requests to send new sled configs to sled agents were failing because it didn't recognize many of the artifacts.
- The rack was MUPdated to release N + 1.
- The planner generated a new blueprint that modified sled configs only to add a new measurement file. I assume this was the measurements need for release N + 1.
At this point:
- at least one sled agent is reporting a local MUPdate override in its inventory
- Nexus is not generating any new blueprints
I would have expected Nexus to notice from the sled inventory that sleds had been MUPdated a second time. It should have generated new sled configs that set "remove_mupdate_override" and set all the artifacts in the sled config to "install dataset" or equivalent. It didn't.
Following up on #10796: in https://github.com/oxidecomputer/customer-support/issues/1372, we found a sequence where:
At this point:
I would have expected Nexus to notice from the sled inventory that sleds had been MUPdated a second time. It should have generated new sled configs that set "remove_mupdate_override" and set all the artifacts in the sled config to "install dataset" or equivalent. It didn't.