Hi, folks! I thought I'd better send out a notice so people know what's
going on here. Any errors in this explanation are my own, dgilmore will
correct me if I'm wrong on any details.
release engineering is currently working to switch the compose process
over to Pungi 4. Specifically, the old nightly compose process for
Rawhide has been disabled, and it was never enabled for Fedora 24.
The whole process of running openQA tests on new composes, generating
the "compose check reports", and creating release validation events on
the wiki was tied to the way the old compose process worked. All those
things need to be changed somewhat for the new compose process. We are
rebuilding the airplane in flight, if you could please hold on to the
engine and/or wing closest to you, that would help. ;)
# openQA
We have rewritten the openQA job scheduler to cue off Pungi 4 "compose
complete!" messages and use Pungi 4 / productmd'ish ways to identify
composes and images. I'm right in the middle of pushing those changes
out now. This *should* mean that openQA tests hand over relatively
smoothly, and there will be openQA test runs for every Pungi 4 compose,
as it lands. There may be a few teething problems with this, we'll see
as we go along. Note for anyone who follows openQA closely or does
anything with its output, the format we use for openQA 'BUILD's and
'FLAVOR's has changed.
Previously, the 'BUILD' value was based on my fedfind/wikitcms version
concept, it was simply the fedfind 'release', 'milestone' and 'compose'
joined with underscores (e.g. 23_Beta_RC2 or 24_Branched_20160225). We
now use the Pungi 4 / productmd 'compose ID' value. This looks like
'Fedora-RELEASE-DATE(.TYPE).RESPIN', where RELEASE is a release number
or 'Rawhide', DATE is the date the compose happened in YYYYMMDD format,
TYPE is the 'compose type' ('n' for "nightly" composes, 't' for "test"
composes, and nothing - this part is omitted - for "production"
composes), and RESPIN is an integer that gets incremented when you do
more than one compose which otherwise would have the same id (e.g. your
compose blows up and you have to do it again). If you need to parse
productmd "compose IDs", the python-productmd package has some bits for
doing it.
The 'FLAVOR' similarly used to be based on fedfind concepts (it was
'PAYLOAD_IMAGETYPE'), it's now based on productmd concepts - flavor is
now 'PAYLOAD-TYPE-FORMAT'. TYPE and FORMAT are productmd properties (we
replace dashes with underscores so parsing the flavor back out works).
PAYLOAD we unfortunately have to synthesize, because productmd doesn't
really provide any convenient property for, say, "the KDE live image".
productmd has a 'variant' concept, but all desktop lives are part of
the "Spins" variant, so that's no use (we can't use it to tell KDE from
LXDE). So we just have to kinda hack this up for now. I'm trying to get
it improved in productmd/pungi somehow.
# check-compose
"Compose check reports" are going to be broken for a bit, probably a
day or two. They're quite heavily tied to fedfind versioning and to an
assumption which is no longer true: there will be exactly one nightly
compose per day. When we decide what compose to compare the latest
compose against, we simply pick the compose for the same release from
the previous day. This doesn't work any more, because of how pungi4 has
'respins' and the respin identifier goes into the compose ID. When we
have 'Fedora-24-20160224.n.0' we don't know what to compare it to,
because we don't know how many respins there were on 20160223. What
we'll have to do instead is query PDC to find the previous successful
compose of the same type, and compare to that. It will also make sense
to use productmd-style image identification rather than fedfind-style.
The question of *when to run* check-compose is also an interesting one;
again it's currently cheating by making assumptions (it starts up a
couple of hours before the nightly compose is expected to complete and
waits 8 hours, on the assumption the compose will show up and openQA
testing will complete during that 8 hour span). What it ideally should
do is run when openQA sends out a message that testing of a nightly
compose has completed. This is a bit difficult at present because
openQA doesn't do that. =) So I'm hoping to add support for that into
openQA somehow or other, but in the worst case it might have to keep
running on a dumb timer for a while if that proves harder than
expected, or perhaps run as a daemon which checks in with openQA every
half hour with some clever query to figure out if a compose has
completed testing in the meantime.
# Wikitcms
The whole wiki release validation process is probably going to be the
hardest to adapt, and also won't be possible to do until we have an
idea how we're going to handle milestone releases and TCs/RCs, so I'm
kinda planning to start working on it once the Pungi 4 switchover has
shaken down and releng have some cycles to discuss and think about
that.
There will be some subjective human decisions to be made for sure, I
think, so when we get to it, there'll be some discussion threads.
Prepare yourself :)
For the present, there won't be any more nightly validation events
created automatically. If the changeover drags on too long before we
decide what to do about TCs/RCs, I'll do something about that, so we're
not stuck on an ancient validation event (with the systemd/selinux
bug).
Ideally, python-wikitcms validation event creation will also cue off
fedmsg's; for now it should probably run when any compose completes and
make some simple decisions about whether to create an event for that
compose. Perhaps in future the decision should take openQA automated
test results into account (so we don't create validation events for
completely busted composes), but that might be slightly further down
the road.
Thoughts? Comments? questions? Wanna help? Please let us know! Thanks
:)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
