Working towards a single API

[bcl]

These are my notes on discussions about moving to a single API for local use with composer-cli, and for remote like cloudapi and cockpit-composer.

Overall goal is to have a single API, probably an extended cloudapi, that all the tools can use, resulting in less code duplication.

Some of the features that the weldr api were designed around no longer make sense to support. This includes:

• blueprint storage/history/diff
• sources that apply to every build for a distro
• storage of compose results longer than what's needed to be uploaded to a final location (one of which could be a local path)

TODO

• change composer-cli and weldr to deprecate features then remove them
  • blueprint storage related commands like push and show
  • Add ability to include blueprint from local storage instead of server-side
  • Add source support to blueprints, only used for that blueprint, added to distro selected repos
• Change cloudapi to allow it to listen to a local socket (ends up this is easy, and just as secure as the weldr socket)
• Add support to cloudapi for features needed by composer-cli and cockpit-composer
  • package search
  • depsolving without composing, including 'frozen' output where exact NEVRA is used.
  • listing distros, listing arches supported by distros
  • ability to include a blueprint as part of the cloudapi compose, letting users reuse existing blueprints without change
• Update cockpit-composer to be compatible with these changes

One thing to remember is that cloudapi is stateless, everything needed to execute the command needs to be included in the request.

[supakeen]

Some (random) thoughts on this:

1. Is anyone 'else' using the weldr API that we know of?
2. @croissanne is working on the webservice blueprints, I'm not a 100% sure on how far along this is but it might make sense to have a blueprint -> webservice blueprint -> composerequest translation internally.

Will we move blueprint parsing into the API or keep it in the client(s)?

[bcl]

I know of at least one user of weldr-client, who filed a bug a while back. It exists so we have to assume it is used.
Blueprints are not parsed in the client, one of my goals for composer-cli was to keep it loosely coupled to the backend so that it doesn't end up getting out of sync. The client passes toml/json to the server, the server parses it and returns errors to the client.

[croissanne]

1. random thought but if we really wanted to we could just let the weldr api translate & forward requests to the cloudapi, probably not worth it though. We should remove it in rhel 10 maybe but keep in rhel9? That said do we support direct talking to the unix socket? I always thought we only supported weldr-client or cockpit-composer.
2. Personally I think it's fine if the client parses the blueprint/deals with it, as long as 'parsing' for the weldr-client means just converting toml to json.

[teg]

Love to see this making progress!

I have a comment on a very small point: the support for freezing blueprints might be implemented via a feature I had hoped to do ages and ages ago:

Our current "compose" end point does two things internally: "depsolve" (which is essentially the same as "freeze")and "build". If we were to expose these as two separate calls (requiring state between them), we would support freezing (roughly) and it would also allow our cloud UI to be more powerful: we could depsolve before the review screen allowing us to show more info before building the image as well as handling more errors (caused by depsolve) before the build even starts.

[bcl]

Some code to add blueprints to cloudapi compose requests - osbuild/osbuild-composer#3757