Skip to content

remove artifact kind from PendingMgsUpdate #8017

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Apr 22, 2025
Merged

Conversation

davepacheco
Copy link
Collaborator

PendingMgsUpdate currently includes an ArtifactHashId, which is a combination of ArtifactKind and ArtifactHash. We need the hash, but we don't need the kind. This choice dates from the first iteration of PendingMgsUpdate, when the kind here specified which component was being updated. Now, that's specified by the details field, which has other component-specific information, too. So we don't need the kind and we can use an ArtifactHash directly rather than ArtifactHashId.

This is built on #8016 just to avoid conflicts.

Anticipating some related questions: we do still make other assumptions about some fields matching up. For example, the artifact referenced by this hash must be appropriate for the component being updated (SP vs. RoT vs. RoT bootloader), the board being updated (when it comes to the SP), the slot being updated (when it comes to RoT), the signing key (when it comes to RoT and RoT bootloader), etc. And updating to this artifact should result in version artifact_version being in the component's active slot. The executor checks / will double-check most of these. But it's the responsibility of the planner to set them correctly.

The way I think about all this is that the planner is responsible for taking the high-level, normalized data (like the policy "we should be running release 14" and the TUF repo metadata that specifies which artifact is appropriate for any given component) and creating a PendingMgsUpdate. That structure is essentially denormalized and gives the executor all the information it needs to complete the update without having to consult any other sources.

@davepacheco davepacheco self-assigned this Apr 21, 2025
@davepacheco davepacheco added this to the 15 milestone Apr 21, 2025
Base automatically changed from dap/sp-update-reconfigurator-cli to main April 22, 2025 00:18
@davepacheco davepacheco merged commit d9ba283 into main Apr 22, 2025
17 checks passed
@davepacheco davepacheco deleted the dap/sp-blueprint-simplify branch April 22, 2025 04:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants