Because the mash script will always need to run on the kojimaster
server, it has local access to RPMs. Rather than copying the data,
create a symlink to the data. This reduces disk usage and allows the
mash hosting location to be flexible.
Because the mash is re-generated every time kojira runs and creates a
new koji repository, by nature, the mash is an iterative process.
Existing repository metadata is always available (excpet for the first
run). Pass this existing metadata to createrepo_c so that it may more
efficiently diff and recalculate the updated metadata in order to reduce
CPU and disk usage.
By reducing disk and CPU usage, this reduces the impact of running this
process on a kojimaster which is a shared system responsible for hosting
many resources.
Signed-off-by: George T Kramer <george.t.kramer@intel.com>
The mash utility has not been ported to python3. There is also no
comparable replacement utility of a similar scope that can do a similar
job. There is pungi utility, which is the replacement for mash.
However, pungi is Fedora's build process encapsulated into a single tool
and is doing too much for simply creating repos for distribution.
To avoid this complexity, koji does have a dist-repo subcommand.
However, this takes too long to execute at around 15 minutes on powerful
hardware.
In lieu of not wanting to maintain mash any further, write a small bash
script that performs the same function using artifacts for koji on the
disk.
Signed-off-by: George T Kramer <george.t.kramer@intel.com>
Do not bother using DNF to get the NVR of packages. Call out to RPM
directly instead.
More completely parameterize script to allow for sourcing of variables
from parameters.sh sometime in the future.
Signed-off-by: George T Kramer <george.t.kramer@intel.com>
A deployment of a "koji" server consists of additional services that
support development beyond koji itself. These include
git/cgit/gitolite, a mash containing the current snapshot of the
packages in koji, and an upstreams package sources cache.
Because these are required for integration with a DevOps workflow, they
are not included by default in the ansible playbook.
George T Kramer