Currently the rsync control for various the tier0 download servers are
controlled by inventory/group_vars/download. These hosts are allowed
to get downloads days in advance. Control is done by adding them to a
template in the rsync file and controlled by an inventory file for the
download group. [TODO: this is obscure and needs a rethink. It also
uses host names versus ip addresses so we end up with changes like
this one where the reverse DNS name changed.]
Signed-off-by: Stephen Smoogen <ssmoogen@redhat.com>
The idea is that we will start minimal compose for every new
Koji build for package which appears in the boot.iso and therefore
can break its generation.
These composes will be built using ODCS on releng backend for now.
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
We need this because f33 rpm switches to sqlite.
So, fedora builds are fine, but epel builds install the buildroot
with f33 rpm/sqlite and then the epel rpm/yum don't know what to do.
This causes mock to make a bootstrap chroot made with the rpm/yum/dnf
of the target and use that to build everyhing after with.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Right now the koji_builder role is the thing that sets a symlink from
/mnt/koji to /mnt/fedora_koji/koji, since we have nfs clients now
mounting under there the ansible nfs/client role makes the directoes and
koji_builder can't make the symlink. So, move it before then and see if
that fixes this issue.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
The grobisplitter parts need some documentation to explain what they
are doing and for whom. This is a first attempt at getting that right
Signed-off-by: Stephen Smoogen <ssmoogen@redhat.com>
In order to make CentOS-Stream useful for people wanting to test
upcoming parts there has been a request for an EPEL-next. This is a
sync of packages which will allow for Stream to be copied to the
batcave and then used by grobisplitter and koji for such needs.
Signed-off-by: Stephen Smoogen <ssmoogen@redhat.com>
This revises the Greenwave config again, aiming to be as clear
and efficient as possible. The major practical change here is
we use fedora-* for the product_versions in the 'null' policy
(wildcards like this have been allowed since Greenwave commit
be9a5427 in 2018), and we use lists of decision_contexts instead
of a single decision_context per policy (this has been allowed
since 1.6.0), allowing us to combine two pairs of policies into
single policies. I also revised the comments, policy names and
file organization, taking advantage of these simplifications.
We could make this even more efficient if policies could apply
to multiple subject_types as well, but apparently they can't.
I've filed https://pagure.io/greenwave/issue/609 for that.
Using a wildcard for product_versions in the null policy will
have the practical consequence that whenever a new Fedora release
or dist shows up, if no policy has been prepared for it in advance,
queries for it that match the other elements of the null policy
will succeed rather than failing because no policy is found. i.e.,
practically speaking, Bodhi push queries will succeed rather than
failing. I think this is what we want (since whenever that happens
we just go ahead and add the identifier to the null policy), but
it's worth noting.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit 00405f3491. The
patch needs several changes to make it work.
1. Paths need to be relative instead of absolute
2. The glob search needs to be more specific.
The policies Kevin took out in f9e7d727 were misleadingly named.
They didn't have anything to do with taskotron any more. The
actual difference between them and the "no_requirements" policies
is that they each have a RemoteRule rule, which is the special
sauce that makes gating policies in package repos work. Without
that, those policies are ignored.
This commit restores those policies, changes all the policy names
to more accurate and information ones, and adds quite a lot of
explanatory comments.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
