[BUG] Legacy API endpoint `/boot/v1/bootparameters` does not allow backwards compatibility with BSS compatible clients

[davidallendj]

Issue Description

When trying to use the ochami CLI to set boot parameters with the boot-service legacy API, I get a 404 error when following this section of the OpenCHAMI tutorial.

ochami bss boot params set -f yaml -d @/opt/workdir/boot/boot-compute-debug.yaml

The command above produces the following error running with boot-service.

2025-11-05T16:22:46Z ERR bss-boot-params-set.go:154 > BSS boot parameter request yielded unsuccessful HTTP response error="PutBootParams(): failed to PUT boot parameters to BSS: unsuccessful HTTP status: HTTP/2.0 404 Not Found: {\"type\":\"about:blank\",\"title\":\"No matching boot parameters found\",\"detail\":\"\",\"status\":404}\n"
2025-11-05T16:22:46Z ERR lib.go:503 > see 'ochami bss boot params set --help' for long command help

The ochami CLI is making a request to the /boot/v1/bootparameters endpoint that is served by boot-service. However, the implementation between boot-service and BSS are different which can be compared here and here respectively. The main difference between the two implementations is that the boot-service decodes the request body, attempts to get all existing boot configurations, and then tries to filter the configs by the provided identifers (xname, nid, MAC address) before storing whereas BSS only decodes the request body, checks the MAC address format, and then stores the data.

Expected Behavior

Considering that the legacy API is meant to maintain compatibility with BSS, I would expect to be able to make the ochami bss boot params set command (or equivalent curl request) and have it work with boot-service.

An equivalent curl may look something like this from the tutorial:

curl https://demo.openchami.cluster:8443/boot/v1/bootparameters -X PUT -d '{"macs":["52:54:00:be:ef:01","52:54:00:be:ef:02","52:54:00:be:ef:03","52:54:00:be:ef:04","52:54:00:be:ef:05"],"params":"nomodeset ro root=live:http://172.16.0.254:9000/boot-images/compute/debug/rocky9.6-compute-debug-rocky9 ip=dhcp overlayroot=tmpfs overlayroot_cfgdisk=disabled apparmor=0 selinux=0 console=ttyS0,115200 ip6=off cloud-init=enabled ds=nocloud-net;s=http://172.16.0.254:8081/cloud-init","kernel":"http://172.16.0.254:9000/boot-images/efi-images/compute/debug/vmlinuz-5.14.0-570.55.1.el9_6.x86_64","initrd":"http://172.16.0.254:9000/boot-images/efi-images/compute/debug/initramfs-5.14.0-570.55.1.el9_6.x86_64.img","cloud-init":{"meta-data":null,"user-data":null,"phone-home":{"pub_key_dsa":"","pub_key_rsa":"","pub_key_ecdsa":"","instance_id":"","hostname":"","fqdn":""}}}' -H "Authorization: Bearer $DEMO_ACCESS_TOKEN"

Possible Solutions or Changes

I would expect one of the following changes to achieve the expected behavior mentioned above.

1. Change the boot-service implementation to mirror the BSS request and responses. The function definition can be adapted to work with boot-service's internal API and doesn't have to be a 1-to-1 translation of BSS behavior.

2. Change the ochami client to make calls to the API using the boot-service client library. The ochami client would use the provided API of the boot-service's generated client instead of implementing it's own.

Other Considerations

Going with solution 2 mentioned above would require any other clients to make the same change to work with boot-service whereas option would allow clients that already work with BSS to also work with boot-service. The trade-off is that 1 allows clients to ideally work with minimal changes only to the legacy API, and 2 would allow a more consistent client implementations across all tools that make request to boot-service.

Additionally, the boot-service client can replicate the intended behavior with the following command.

go run cmd/client/main.go bootconfiguration create --spec '{"macs":["52:54:00:be:ef:01","52:54:00:be:ef:02","52:54:00:be:ef:03","52:54:00:be:ef:04","52:54:00:be:ef:05"],"params":"nomodeset ro root=live:http://172.16.0.254:9000/boot-images/compute/debug/rocky9.6-compute-debug-rocky9 ip=dhcp overlayroot=tmpfs overlayroot_cfgdisk=disabled apparmor=0 selinux=0 console=ttyS0,115200 ip6=off cloud-init=enabled ds=nocloud-net;s=http://172.16.0.254:8081/cloud-init","kernel":"http://172.16.0.254:9000/boot-images/efi-images/compute/debug/vmlinuz-5.14.0-570.55.1.el9_6.x86_64","initrd":"http://172.16.0.254:9000/boot-images/efi-images/compute/debug/initramfs-5.14.0-570.55.1.el9_6.x86_64.img","cloud-init":{"meta-data":null,"user-data":null,"phone-home":{"pub_key_dsa":"","pub_key_rsa":"","pub_key_ecdsa":"","instance_id":"","hostname":"","fqdn":""}}}' --server https://demo.openchami.cluster:8443

Verify that it was created.

go run cmd/client/main.go bootconfiguration list --server https://demo.openchami.cluster:8443

This will show the boot configuration that was created.

[alexlovelltroy]

@synackd What do you think here? Can we make ochami import the boot-service client, or should we focus on making the classic bootconfiguration API work the same as old bss?

[synackd]

I would think that any client using the legacy API would expect exact legacy behavior, so I think focusing on making the legacy API mirror BSS is probably the way to go.

That said, I think the general trend of making ochami use the client libraries of the services it contacts should also be a focus. That way, changes to the API would occur in the service repo and the client only need bump the version instead of putting the burden on the client to refactor.