Skip to content

Nexus didn't notice second MUPdate while resolving first one #10797

Description

@davepacheco

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions