I tweaked the playbook to not patch the templates for non-infra
deployments, but then forgot to make test loading work using
non-patched templates for non-infra...
necessary updates for openqa roles have gone stable for now, so
disable updates-testing usage (keep the plays around commented,
though, since we'll likely need them again in future). Also, a
bit more attempted support for non-infra use: make the monkey
patching of the repo URLs in the test templates only happen if
deployment_type is defined, actually respect the openqa_consumer
var (don't enable the job scheduling consumer unless it's truey)
and only enable any wiki reporting consumer if deployment_type
is defined.
rwmjones says the guestfs / rpm bug has been fixed (a new base
fedora-23 image has been uploaded which should avoid it, anyway)
so let's try turning disk image generation back on and see how
it flies.
I'm still kinda trying to make the openqa roles usable outside
of infra, so now I have a minute, let's do this: it makes the
static UID/GID for geekotest optional and configurable, instead
of hard coding it. For infra we set the value to 601, as we
are already using, in the openqa and openqa-stg group config.
this is a database value and there's no openQA API function to
set it, so we have to do it directly in the database...this
*should* work. I think. I should add equivalent functionality
for sqlite use as well, really...
there seems to be a bug in python2-guestfs which causes the
disk image with an updates.img file to be broken (the updates
image is only 4096 bytes long and incomplete). When built with
Python 3 the image seems to be fine. So, run the script with
python3 (as its hashbang says) and ensure necessary packages
are installed.
seems like we need the internal inbound relay but the public
outbound relay? I don't even know...but we definitely can't
connect to busgateway01.phx2.fedoraproject.org:3999
i think the relay 'fix' is only needed for stg, because there
was a firewall rule added for prod but not stg. It's not really
a 'fix' either (it'll stop messages getting out) but it at
least prevents fedmsg-relay failing, so keep it for now.
Ralph *mostly* fixed it, but the config we get from fedmsg/base
still doesn't quite work, so this just hacks it up after that
role's done. This will go away with a couple more fixes to the
fedmsg/base role.
with openQA jobs being scheduled and wiki results reported
(well, when we get that working again) by fedmsg-hub consumers,
we have to let the fedmsg user read these files.
