On 5/16/19 10:33 AM, Dean Troyer wrote:
On Wed, May 15, 2019 at 3:19 PM Bailey, Henry Albert (Al) <Al.Bailey@windriver.com> wrote:
If we update the build tool (and remove those variables from the spec files), then all python components in a particular repo will have the same version. We have some repos where there are multiple python components in the same repo.
As you note PBR and other OpenStack tooling has the assumption that everything in a git repo is related and is a single "thing". This could be changed, thus far it really has been easier to break out common components. We have to work around this in other areas too, such as maintaining multiple tox job definitions rather than using a single top-level tox.ini.
So, there have been a couple of replies to this thread, I would like to bring it back to the top of the queue for something to address in STX-3.0 release. It seems we will need to add tagging back into our process for proper PBR support to ensure the flock get the correct version. If items need independent versioning then we may have to manually handle the versioning or possibly split them out as their own repo depending on the requirements.
I think we need to break out more parts from the existing repos but within the same sub-project teams. I would start with either major pieces (inventory) or the small dependencies (tsconfig, fm-common/fm-core) and clients (cgts-client). I have done an experiment with cgts-client that took a couple of hours and is even mostly automated and maintains the git history.
As we work on the openSUSE specfiles, it seems part of the way tsconfig works is to copy one directory into the Source RPM in Centos so everything is in the correct location (tsconfig/scripts is copied into tsconfig/tsconfig). Using the generic tarball [0] from stx-update, the scripts directory is not in the same place relative to the tsconfig setup.py. [0] https://opendev.org/starlingx/update/archive/master.tar.gz I hope this makes sense, I got into the weeds a little. Sau!
dt