# Decomposer vs Cockpit

## Current Architecture


## Potential requirements
- Needs to provide ibcrc API
- Needs to serve cockpit-image-builder
- Should serve the MCP server
- Should serve weldr-client (once it supports ibcrc API) to allow seamless migration off osbuild-composer to ibcli on RHEL-10*
- Should be easy to package and maintain in RHEL (considering its dependencies)
- Should use familiar tech stack

## Cockpit challenges
These are some of the reasons we floated the decomposer shim in the first place
- state management
- filesystem for the frontend
- redux in the frontend
- some code duplication
- the frontend store is generated from the ibcrc openapi spec
- the cockpit version is a manual file that we have to go in and add custom functions to handle the endpoints (I'll show some examples later)
- type safety
- weird mix of the image-builder-crc openapi spec and the cloudapi spec
- has to translate between the two
- this might be a non-issue because of UBP
- domain knowledge is a limiting factor
- it's a weird intersection of frontend and backend:
- typescript+react
- cockpit
- osbuild-composer/ibcli
- probably only two meaningful contributors + reviewers

Having a shim around ibcli solves most of this, except maybe the last point. It does separate the frontend and the backend though. It also introduces a packaging issue, do we create an npm for this? Do we create an rpm? Since it's typescript we could probably just bring it in as an npm package and ship it with the `cockpit-image-builder` rpm.

## Potential architecture


## Pros & Cons

### Cockpit

#### Pros

- it's not a major change to what we have
- no extra maintenance and less infra
- no extra dependencies
- no packaging headaches
- it might be easier to listen for json progress for a build
- would be easier to retry a failed build

#### Cons

- inconsistent architectures
- weird code branching
- mix of manual & generated code
- lots of code duplication
- separation of concerns
- testing is really tricky
- we have to mock most of the cockpit stuff
- really hard to test all the edge cases
- surfacing errors might be really hard
- users would have to switch out of cockpit image builder to go and inspect systemd services
- we have to mock the types for compilation and compatibility with codebase
- might be an issue for MCP
- we 100% have to keep osbuild-composer for composer-cli (but this might need to be its own discussion)
- This UX might get annoying for users:

    Last login: Thu Sep 18 09:43:10 2025 from 10.0.2.2
    [systemd]
    Failed Units: 4
      cockpit-image-builder-052e427f-4f0a-427c-b4b5-e835a78ef30c.service
      cockpit-image-builder-a978c59a-1a1d-4f34-8085-28387a12981b.service
      cockpit-image-builder-e9f6191c-f69a-4532-b524-adedc4338f0d.service
      cockpit-image-builder-fd9ba52b-b9c2-4065-a922-47b0c903d1e4.service

### Decomposer

This is not to say we go with the POC shim that we have in `osbuild/decomposer`. We may still need to make
other choices on languages/technologies.

#### Pros

- uses the ibcrc openapi spec as a contract so the two frontends could share the same code
- remove the weird code forking:
- see this commit: https://github.com/osbuild/image-builder-frontend/pull/3670/commits/387027f680e7b35ffcff079e0c8f331b33100073
- isolate the frontend & "backend"
- testing is easier and we can test things in parts
- we would have a rest api for MCP
- easier error handling
- this would obsolete the need of the getting started stuff
- we could provide an option for this to be used as the backend

#### Cons

- more maintenance
- separate repository
- packaging concerns
- more node_modules shenanigans
- we might still have to keep osbuild-composer if replacing weldr api is too much work