Migrate from weldr-api to cloud-api.

[supakeen]

weldr-client currently speaks to the weldr-api as provided by osbuild-composer. In the longer term I'd like to move this over to the cloud-api, also provided by osbuild-composer.

Most important is how we deal with blueprints. These are currently being parsed on the weldr-api side of things and with this change they would need to be parsed and converted into a cloud-api type request on the client side.

We would likely split out the parsing and validation of blueprints to a separate library as the service has also indicated interest in copy/pasting in a blueprint.

[bcl]

I don't think that's the right way to go. It would be better to teach cloudapi to handle blueprints (they are converted json after all). It is better to keep the validation all on the server and the client light weight, this prevents problems with changes needing to be synchronized between multiple applications.

[bcl]

I have a draft PR for a client in #134, and here are a list of things that need to be fixed, written, etc. :)

Right now it can build a local images, which is stored in the artifacts directory. But unless you know where to look you can't get it (ie. /var/lib/osbuild-composer/artifacts/UUID/disk.qcow2). And the server needs to have local storage enabled. This was originally supposed to be a debugging feature only, but I think it needs to be enabled for on-premises use. Of course that then opens up the question of how to deal with old images to keep them from filling up the filesystem. I think that, after adding support for composer-cli compose image to download/copy it, it is reasonable to delete it from the artifact store.

Some things that need to be implemented in cloudapi

• Download locally stored images (composer-cli compose image UUID)
• Deleting locally stored imaged explicitly, either via UUID or some other criteria like date or blueprint or type
• Uploading to a user's account instead of sharing with the user's account
• Implement waiting for a cloudapi compose (cloudapi does have a status that can be queried)
• Status of cloudapi compose (composer-cli compose status and info and list
• Cancel a running compose

Questions to answer

• cloudapi uses a different list of image types than weldr API, how to reconcile this when the goal is seamlessish transition to the new api.
• cloudapi uploads are a subset of the weldr API upload capabilities. Right now it is hooked up to compose start but won't work unless the worker has been setup like the service.

In order to hide the fact that there are now two apis from the user the composer-cli commands will need to query both APIs to figure out which one has the selected UUID.

I think the cloudapi upload options should should be expanded to support all of the Target fields, like the weldr API uploads are, so that users can upload to their own accounts using local upload.toml files for credentials. As with blueprints I have written the upload support to just pass thru the upload.toml so that all the heavy lifting of supporting this is done in the server code.

[supakeen]

I'll do a slightly longer reply later but for the first issue of keeping disk images around maybe we can grow a prune subcommand to image much like what container command lines do, we can mark images as prunable after they've been 'downloaded' at least once?

[bcl]

Yeah, I was thinking that a successful download would just delete it. I'm mostly worried about the forgotten images. Deleting them on startup may be ok, but if it never restarts there should be something that eventually removes old ones without needing an explicit command and without becoming too complicated :)