Feature/upgrade fabrica

[alexlovelltroy]

Description

This pull request migrates the project’s resource definitions to a new structure under apis/boot.openchami.io/v1, updates the code generation and validation pipeline, and deprecates the old pkg/resources tree. It introduces new Fabrica configuration files, updates documentation and Makefile workflows, and refactors generated handlers and client code to use the new API types. The most important changes are grouped below.

Resource API migration and deprecation:

• Introduced new resource type definitions for BMC, BootConfiguration, and Node in apis/boot.openchami.io/v1/, replacing the old pkg/resources structure. These types now use a flat Fabrica-compatible schema with explicit APIVersion, Kind, and Metadata fields, and implement custom validation logic.
• Deprecated the pkg/resources/* tree for resource definitions; all new code should use the new apis/boot.openchami.io/v1/ location.

Fabrica 0.4.0 integration and configuration:

• Added .fabrica.yaml and apis.yaml to define the project’s Fabrica code generation settings and resource groups, enabling strict validation, file-based storage, and generation of handlers, storage, client, and OpenAPI artifacts.

• Updated documentation (README.md) to describe the new Fabrica source inputs and regeneration workflow.
  Build and code quality enforcement:

• Updated the Makefile to reflect the new binary name, and added a check-no-pkg-resources-imports target to prevent new code from importing deprecated pkg/resources modules.

Generated handlers and client refactoring:

• Refactored generated handler code (e.g., cmd/server/bmc_handlers_generated.go) to use the new v1 API types, update metadata handling, and improve validation layering. Also updated comments to reflect new versioning and codegen practices.
• Updated generated client code to reference the new API types in documentation and code examples.

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
• 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

---

For more info, see Contributing Guidelines.

[alexlovelltroy]

I didn't try to incorporate the new tokensmith middleware yet.

[synackd]

Initial code review. Still need to build and run it. Unit tests pass.

[synackd]

I am running into an error with make docker-build because the binary is not found:

$ make docker-build
docker build -t boot-service:latest .
STEP 1/8: FROM gcr.io/distroless/static-debian12:nonroot
Trying to pull gcr.io/distroless/static-debian12:nonroot...
Getting image source signatures
Copying blob 7c12895b777b done   | 
Copying blob 526604835308 done   | 
Copying blob ef49c20a7b35 done   | 
Copying blob 990a9c434e5e done   | 
Copying blob 2780920e5dbf done   | 
Copying blob bf7a4185f015 done   | 
Copying blob 3214acf345c0 done   | 
Copying blob 52630fc75a18 done   | 
Copying blob dd64bf2dd177 done   | 
Copying blob b839dfae01f6 done   | 
Copying blob dcaa5a89b0cc done   | 
Copying blob 069d1e267530 done   | 
Copying config 3a59ed7ba5 done   | 
Writing manifest to image destination
STEP 2/8: WORKDIR /app
--> 26cfc71b3d2c
STEP 3/8: COPY boot-service /usr/local/bin/boot-service
Error: building at STEP "COPY boot-service /usr/local/bin/boot-service": checking on sources under "/opt/shared/boot-service": copier: stat: "/boot-service": no such file or directory
make: *** [Makefile:58: docker-build] Error 125

A couple of suggestions:

1. Generalize container build target (e.g. container-build/container-run), allowing other runtimes other than Docker (e.g. Podman) for builds, as well as specifying tags, etc. (See [1] [2] [3] [4])
2. Either combine the Dockerfiles or have the container build target use the standalone one.
   • If we want to separate the Goreleaser Dockerfile from the multi-stage build Dockerfile, we should have the container build Make target use the latter. Else if we consolidate the Dockerfiles, we should have the build Make target put the binaries in the repo root and name them (as Goreleaser does, e.g. boot-service and boot-service-client) so the single Dockerfile will find them (we'll also need to make sure the container build target lists the binaries as prerequisites)
   • CoreSMD uses a consolidated Dockerfile. See [4] [5]

[synackd]

Getting the following error trying to add a boot config:

$ ./bin/client bootconfiguration create --server https://demo.openchami.cluster:8443/boot-service --spec '{
        "hosts": ["host1"],
        "kernel": "http://s3.openchami.cluster/kernels/vmlinuz1",
        "initrd": "http://s3.openchami.cluster/initrds/initramfs1.img",
        "params": "console=tty0,115200n8 console=ttyS0,115200n8",
        "priority": 42
      }'
Error: failed to create BootConfiguration: API error (500): failed to generate UID: resource kind 'BootConfiguration' is not registered - call RegisterResourcePrefix() first
Usage:

[alexlovelltroy]

I am running into an error with make docker-build because the binary is not found:

STEP 3/8: COPY boot-service /usr/local/bin/boot-service
Error: building at STEP "COPY boot-service /usr/local/bin/boot-service": checking on sources under "/opt/shared/boot-service": copier: stat: "/boot-service": no such file or directory

I wonder if we're better off just removing this make target and Dockerfile.standalone in favor of a completely different process for making local docker containers for testing. As you mention in your comment, addressing all of the possible ways this might be used outside the release process is challenging. Let's save that for outside the context of the PR though.

I have created #8 to further discuss what to do so it doesn't get lost.

[alexlovelltroy]

Getting the following error trying to add a boot config:

$ ./bin/client bootconfiguration create --server https://demo.openchami.cluster:8443/boot-service --spec '{
        "hosts": ["host1"],
        "kernel": "http://s3.openchami.cluster/kernels/vmlinuz1",
        "initrd": "http://s3.openchami.cluster/initrds/initramfs1.img",
        "params": "console=tty0,115200n8 console=ttyS0,115200n8",
        "priority": 42
      }'
Error: failed to create BootConfiguration: API error (500): failed to generate UID: resource kind 'BootConfiguration' is not registered - call RegisterResourcePrefix() first
Usage:

I believe this will be fixed with the updated changes to the PR in main.go

[synackd]

Can we add these back too?

[synackd]

I see that the v1 prefix is deleted above, probably should delete it here as well.

[synackd]

Interestingly, it complains that the kernel field is missing despite being present:

$ ./bin/client bootconfiguration create --server https://redondo.usrc.newmexicoconsortium.org:8443/boot-service --spec '{
        "hosts": ["host1"],
        "kernel": "http://s3.openchami.cluster/kernels/vmlinuz1",
        "initrd": "http://s3.openchami.cluster/initrds/initramfs1.img",
        "params": "console=tty0,115200n8 console=ttyS0,115200n8",
        "priority": 42
      }'
Error: failed to create BootConfiguration: API error (400): validation failed: kernel field is required

[synackd]

I am running into an error with make docker-build because the binary is not found:

STEP 3/8: COPY boot-service /usr/local/bin/boot-service
Error: building at STEP "COPY boot-service /usr/local/bin/boot-service": checking on sources under "/opt/shared/boot-service": copier: stat: "/boot-service": no such file or directory

I wonder if we're better off just removing this make target and Dockerfile.standalone in favor of a completely different process for making local docker containers for testing. As you mention in your comment, addressing all of the possible ways this might be used outside the release process is challenging. Let's save that for outside the context of the PR though.

I have created #8 to further discuss what to do so it doesn't get lost.

Sounds good!

[alexlovelltroy]

I've added the features from #3 to this PR to simplify the merge train