We have this OpenStack upversion planned as a feature for next StarlingX release (9.0), but during the development of it we found that the most difficult part is to properly build it without affecting the platform, since several components are shared.
First, the OpenStack client packages that we currently build, we build along with platform packages as part of the starlingx/upstream repository (see discussion: https://lists.starlingx.io/pipermail/starlingx-discuss/2023-June/014222.html).

We started relocating the clients packages to starlingx/openstack-armada-app, but also realized that there are several package dependencies that would conflict versions against what is currently used by other platform packages. This is also true for our docker images and the necessary packages/wheels that we install when building it. Mainly, there would be two repositories with points of conflict: starlingx/root and starlingx/tools.
Therefore, the splitting is not straightforward and would require extra investigation (along with the Build team) to be done.

So, the Build team helped us providing a "feature branch" (i.e., f/antelope) in which we can move and change all that we need in order to have a buildable application that will use OpenStack clients and services on the Antelope (2023.1) release. That unblocked us, but did not solve all of the problems, since when the time comes for us to make the official StarlingX 9.0 releasee, code-freeze and branching, we will do it from master and not from the feature branch.
We would have to bring what we changed in "f/antelope" to "master" prior to our release, but that would require not only the manifest split but also a solution for the shared/conflicting dependencies on starlingx/root and starlingx/tools.

Scott already told us what are the only two options we have for this merge:

1. We find a way to separate the packages dependencies by repository, something like moving this list of dependencies and versions from starlingx/root and starlingx/tools to the specific repo. This option would be ideal, since it is less error prone (i.e., do not affect other starlingx repositories/packages) but is also the option the required more work/investigation. Scott thinks it would be an entirely new feature for the build team.
2. We decide that the dependencies (i.e., packages) versions will now be matching the Antelope needed versions for all packages. This would affect not only the build but also the runtime of so many parts of the platform, that would require a careful testing procedure and it is unpredictable on how many side-effects and extra-fixes would be needed.
   

Tried to keep this summary short enough to bring everyone the context of this problem before our next TSC meeting.

Best regards,