Hello James,
thanks for your comments, replies are in the text below.
----- Original Message -----
From: "James Laska" <jlaska(a)redhat.com>
To: "AutoQA development" <autoqa-devel(a)lists.fedorahosted.org>
Sent: Monday, January 10, 2011 10:18:59 PM
Subject: Re: New Koji Watcher (watching -pending tags & batch possibility)
On Fri, 2011-01-07 at 08:59 -0500, Josef Skladanka wrote:
> Hello gang,
>
> After today's testing, I believe that the new koji watcher is ready
> to be
> reviewed and poked by the rest of you :)
>
> The code is located in the new_koji_watcher branch in git, latest
> version
> should be here:
>
>
http://git.fedorahosted.org/git/?p=autoqa.git;a=commit;h=634133dc452abde0...
>
> Comments and critique are appreciated as always
Nice work Josef! I've checkout out your new_koji_watcher branch
locally
and re-merged with master to incorporate the latest'n'greatest from
master.
> class KojiWatcher(object):
> kojiserver = 'http://koji.fedoraproject.org/kojihub'
> kojiopts = {} # Possible items: user, password, debug_xmlrpc,
> debug..
> cachedir = '/var/cache/autoqa/watch-koji-builds/'
> cachefile = os.path.join(cachedir,
> 'koji_history_prevtimes.cache')
I guess we can use the koji_url value defined in autoqa.conf? While we
don't have cachedir defined in autoqa.conf now, the same probably
holds
for its value?
Of course, moving koji_url to autoqa.conf is great idea! On the other hand
I would not move the cachedir there, since it's quite watcher-specific
and should not change after the watchers first run (since we need to load
the stored data from the respective cachefile), hence the hardcoded way.
You've taken an interesting/new approach by re-using the
existing
post-koji-build watcher. A few related comments ...
1. I see you are kicking off 'post-koji-build' autoqa jobs for new
-pending tags. My impression was the output of the current
'post-koji-build' watcher wouldn't change. Am I incorrect?
(possibly related to point#3 below)
3. I'm a little confused as to how the new watcher relates to
post-bodhi-update. Does support for monitoring the -pending
tag, replace the need for post-bodhi-update? Anything related
to monitoring the -pending tag is new mechanism for monitoring
for proposed bodhi updates, right?
Yes, -pending tag represents the 'Bodhi event', because Bodhi assigns
the -pending tag after doing it's magic, so we can easily track it
using data from koji (i.e. the changes of the 'content' tagged with
the respective -pending tag)
Ad "output of koji won't change": I've briefly discussed this with
kparal and in the next release I'd like to distinguish the events
by adding a specific parameter to autoqa, so we won't need to 'guess'
it based on the watcher name. As you and me discussed some time ago with
wwoods, the watchers watch for 'events' (e.g. post-koji-watcher triggers
'new package in koji' event, the post-bodhi-update triggers the bodhi event).
At the moment, we're distinguishing the events using the name of
the respective watcher (which made perfect sense up until now), but
in the next release, I'd like to add a parameter to autoqa, which would
specify the type of event (e.g. "--event=new_package_in_koji"), so
we do not need to rely on the watcher name.
At the moment, the post-bodhi watcher is still active, so I did not
feel the need to implement this functionality right now, but it's
true, that this might be confusing.
2. Perhaps related to above, I see where you are removing duplicate
jobs from the updates-candidate set, can you talk to this a bit
more?
OK, in Koji, we have XYZ-updates-candidate tag. This tag contains
all the builds, which are not in XYZ-updates or XYZ core stable repo.
The "all not in stable" quantifier is important, because when Bodhi
wants to 'push' some update, it _adds_ the XYZ-pending tag to the
-updates-candidate tag. So when a build is tagged with -pending, it
has (at least) two tags at the same time: -updates-candidate & -pending.
We assume, that if the package has -pending tag, it was already tested
in the -updates-candidate stage, so I'm removing it from the -updates-candidate
listing, so the tests do not run twice needlessly.
Hope it makes sense :)
4. Not really related to your patch, but the tags we generate for
*-updates-candidates and *-pending always felt weird being
hard-coded. I don't know if there is a way to sanely integrate
this into repoinfo.conf or not.
I have not really thought about it, I'd definitely add some 'cleanup'
task to the next autoqa release milestone, rather than rushing some
late-time changes, which might break it :) (That is mostly because
I have no clear idea on what would need to get changed, and how will
the overall code change, and I have a feeling that it won't be
I think that's all that comes to me now. This is cool stuff, thanks
for
taking the time to create this support. I'm still trying to understand
how it fits/replaces existing watchers, but it looks like it's not far
from landing in master.
Thanks,
James
Once again, thank you for your feedback, I'll be glad to hear more!
joza
_______________________________________________
autoqa-devel mailing list
autoqa-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/autoqa-devel