Changes to the automation workflow

[craicoverflow]

We possibly need to revisit the automation workflow of the SDKs - the initial vision was based on the assumption that API clients would be divided into sub modules and sub packages with individual releases. This fit the current flow perfectly as we could merge changes when an OpenAPI update happened to give client side consumers the ability to use the pre-release versions.

We diverted from the original approach to have a single release per SDK for simplicity as we faced some challenges with multiple packages - plus it is easy to add sub-packages the future but not easy to remove them once embedded in clients.

Now that we are doing one single release the main problem is that we are merging changes from different clients but they all don't follow the same release cycle. KAS Fleet Manager pushes to production a few hours or a day after merging. Kafka Admin API however is when the developers are ready, so it could be any time. This is a problem because we have merged Kafka Admin API changes which may include a new endpoint which is not deployed yet, and we need to release the more recent KAS Fleet Manager changes - so we have now released the SDK with changes to the kafka admin client which will not work.

We could revert to the original approach suggested by updating the SDK whenever a release is made - the problem with that is that currently there is no consistent release procedure across all APIs and the process for automation of this has not been finalised.

An option is to require all APIs to use tags/releases on GitHub to indicate a release to production. This tag/release can be a visual thing only and does not need to hook into the deployment process but could do so in the future. It can be a manual thing for now, which could be done in a few seconds on the API side.

The production deployment process is still manual and the only other option I could see is polling api.openshift.com every few hours to see if the OAS version has changed but this would only work for control plane APIs and we would need a different method for data plane APIs.

[craicoverflow]

Tagging is an idea we discussed in DevExp but would like to hear if this makes sense from your side @machi1990.

cc @wtrocki

[machi1990]

Tagging is an idea we discussed in DevExp but would like to hear if this makes sense from your side @machi1990.

@davidffrench is working on the documentation on the kas-fleet-manager side. He may be able to jump in with more infos.