[alexlovelltroy]

Description

This pull request updates the documentation, systemd container definitions, validation policies, and packaging to support new patch versions of several core services, including boot-service, metadata-service, TokenSmith, and CoreSMD. It also introduces a new service update and upgrade guide to help with deployments. The changes ensure that the system uses the latest tested service versions and provides clear instructions for safe rollout and rollback.

Service version updates and configuration:

• Updated container image versions for boot-service (v0.3.3), metadata-service (v0.2.2), TokenSmith (v0.4.2), and CoreSMD (v0.7.2) in their respective systemd container files to reflect the latest tested releases. (systemd/containers/boot-service.container, systemd/containers/metadata-service.container, systemd/containers/tokensmith.container, systemd/containers/coresmd-coredhcp.container, systemd/containers/coresmd-coredns.container) [1] [2] [3] [4] [5]
• Updated the release-v1.json validation policy and endpoint validation documentation to reference and check the new service versions. (validation/policies/release-v1.json, docs/endpoint-validation.md) [1] [2] [3] [4]

Documentation improvements:

• Added a new docs/service-updates.md guide detailing the upgrade process, service-specific notes, qualification steps before rollout, and rollback procedures for the 0.2.x patch line. (docs/service-updates.md)
• Updated the README.md to reference the new service update and upgrade guide, ensuring users review it before updating deployments. (README.md)

Packaging updates:

• Included docs/service-updates.md as part of the packaged documentation in the RPM spec file. (openchami.spec)

Other improvements:

• Adjusted the Exec command for the tokensmith container to match the new image entrypoint (serve --enable-local-user-mint). (systemd/containers/tokensmith.container)

Checklist

• My code follows the style guidelines of this project
• I have added/updated comments where needed
• I have added tests that prove my fix is effective or my feature works
• I have run make test (or equivalent) locally and all tests pass
• I have updated the relevant documentation (CLI examples, man pages, README, other docs, etc.)
• DCO Sign-off: All commits are signed off (git commit -s) with my real name and email
• REUSE Compliance:
  • Each new/modified source file has SPDX copyright and license headers
  • Any non-commentable files include a <filename>.license sidecar
  • All referenced licenses are present in the LICENSES/ directory

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Dependency update
• Build system/CI

---

• I agree to follow the Code of Conduct.

[davidallendj]

Here are some things I saw after testing:

1. Keep TokenSmith’s signing key when it restarts

Testing showed that TokenSmith creates a new signing key on restart, even though its storage is preserved. This can cause previously issued tokens to stop working.
I think it would be better if the packaged setup creates a key on first installation and keeps using that key after restarts and upgrades.

2. Explain the current known problems in the docs

I think it's worth explaining some the problems found during testing in the documentation, such as:

• Some boot/metadata APIs accept requests without a valid login token.
• Metadata’s WireGuard-only restriction can be bypassed using certain request headers.
• Reusing an old refresh token does not disable its replacement as documented.
• TokenSmith writes complete access tokens into its logs.

These problems don't have to be fixed in this PR, but I do think it's worth noting them with links to upstream issues where possible.

3. Show what was tested with instructions and results

It's probably worth including clear instructions or results showing that the updated services start, work together, and keep their saved data after restarting.
Also I think we should say which tests need special configuration and which workflows are not tested. I don't think that tests that pass only with a workaround should be described as passing with the packaged defaults.

[alexlovelltroy]

Testing showed that TokenSmith creates a new signing key on restart, even though its storage is preserved. This can cause previously issued tokens to stop working. I think it would be better if the packaged setup creates a key on first installation and keeps using that key after restarts and upgrades.

Confirmed. If you use --key-file, it doesn't do this. Adding issue on Tokensmith to get it addressed. OpenCHAMI/tokensmith#81

[alexlovelltroy]

* Some boot/metadata APIs accept requests without a valid login token.

* Metadata’s WireGuard-only restriction can be bypassed using certain request headers.

* Reusing an old refresh token does not disable its replacement as documented.

* TokenSmith writes complete access tokens into its logs.

I don't know how much of this is still true. Do you have reproducers for them?

[alexlovelltroy]

/deploy

[ochami-vtds-deploy]

Deployment queued for SHA: a3ee831.

[alexlovelltroy]

/deploy

[ochami-vtds-deploy]

Deployment queued for SHA: a3ee831.

[erl-hpe]

For what it is worth, the above workflow deployment of this PR successfully deployed OpenCHAMI and booted 4 managed nodes, so there do not appear to be any obvious regressions.

[alexlovelltroy]

For what it is worth, the above workflow deployment of this PR successfully deployed OpenCHAMI and booted 4 managed nodes, so there do not appear to be any obvious regressions.

Do you have a link to the successful run?

[erl-hpe]

Yes. Here is the link:

https://github.com/Cray-HPE/openchami-vtds/tree/test-run/a3ee8319adab8884e1dc26becad63c3363917f45-261112200936