I finished moving 'ovirtlago' from Lago into a new repository. You can
take a look at: https://github.com/lago-project/lago-ost-plugin.git.
Reviewing the patches and raising concerns(if any) would be
appreciated, as changing the cut-off point is a little complicated.
1. As far as installation from RPMs, nothing changes - both projects
deploy to the same Lago unstable repository, which we manually deploy
to 'stable' when releasing.
2. Versions - Lago's next version will be 0.39. Lago-ost-plugin will
be 0.40. Which means it will skip v0.39. This to ensure the next
release will be from the new repository.
3. lago-ost-plugin requires Lago >= 0.38(current version).
4. CI-GitHub flow is the same(ci test/merge etc).
5. I added in 'lago-ost-plugin' spec file also 'provides:
lago-ost-plugin', so theoretically(did not test) it could be installed
additionally with 'yum install lago-ost-plugin'.
6. I setup https://lago-ost-plugin.readthedocs.io, not much there for
now(references to oVirt/Lago/OST). It is auto-updated via the normal
7. lago-ost-plugin's functional tests are identical in
check-patch/merged. We could add more tests there, it is relatively
8. Only files used by ovirtlago are in the git history of the new
repository. Though this includes automation/ directory, so some
changes might appear to be unrelated. On Lago's repository the
relevant files were just 'git rm'ed.
With this cleared off the table, we can move to the next goal: pip.
task:f141b349-76b3-4fae-bd42-97d73234ace0:Run command: "reposync"
"--download_path=/var/lib/lago/reposync" "--newest-only" "--delete"
command exit with return code: 0
centos-opstools-testing-el7 | 2.9 kB 00:00
9-76b3-4fae-bd42-97d73234ace0: command stdout:
copr-sac-gdeploy-el7 | 3.0 kB 00:00
epel-el7 | 4.3 kB 00:00
ovirt-master-snapshot-static-el7 | 2.9 kB 00:00
ovirt-master-tested-el7 | 2.9 kB 00:00
Yum-utils package has been deprecated, use dnf instead.
See 'man yum2dnf' for more information.
Obviously, if I'm syncing a single repo, why is it fetching metadata from
We perhaps need to start splitting the config files to multiple conf files?
It makes sense anyway, especially if we run the reposync per each repo