Replies: 3 comments 2 replies
-
Some (random) thoughts on this:
Will we move blueprint parsing into the API or keep it in the client(s)? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Some code to add blueprints to cloudapi compose requests - osbuild/osbuild-composer#3757 |
Beta Was this translation helpful? Give feedback.
-
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:
TODO
One thing to remember is that cloudapi is stateless, everything needed to execute the command needs to be included in the request.
Beta Was this translation helpful? Give feedback.
All reactions