7:59 a.m.
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
joza
3:18 p.m.
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?
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)
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?
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?
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 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
4:45 a.m.
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
10:01 a.m.
On Thu, 2011-01-13 at 05:45 -0500, Josef Skladanka wrote:
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.
I agree, doesn't make sense to have each watchers cachedir in
autoqa.conf. I was thinking we might want the cachedir root, shared by
all watchers (/var/cache/autoqa), configurable in autoqa.conf.
Definitely falls into the "future optimization" category :)
> 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.
I see what you mean, but I'm hesitant to break the separation that has
existed between the watchers in the upcoming next release, and fix it
later.
For example, we have a different potential set of tests that are
triggered by 'post-koji-build' and by 'post-bodhi-update'. I understood
these tickets to mean we wanted to 1) adjust the existing
post-bodhi-update watcher to use the more reliable koji -pending tags
for monitoring, and 2) Add a batch event for bodhi-updates. Since both
watchers need similar code, I expected there to be a lot of sharing, but
I think we still need to distinguish between the two different test
events.
For example, if I run the new koji watcher ...
# python hooks/post-koji-build/watch-koji-builds.py --dryrun
autoqa post-koji-build --kojitag dist-f13-updates-candidate --arch x86_64
oxygen-gtk-1.0.1-1.fc13
This looks correct, and matches what the previous post-koji-watcher would emit.
autoqa post-koji-build --kojitag dist-f13-updates-pending --arch
x86_64 pam_ssh-1.97-4.fc13
This seems incorrect, since it will schedule post-koji-build tests for
that update. We'd want the set of tests defined for bodhi updates. I'd
expect to see this scheduled as ...
autoqa post-bodhi-update --title pam_ssh-1.97-4.fc13 --updateid
FEDORA-2011-0146 --target-tag dist-f13-updates --arch i686 --arch
x86_64 --arch noarch pam_ssh-1.97-4.fc13
Whether the underlying mechansim is querying bodhi, or inspecting koji
-pending tags, our tests need to distinguish between these different
events still.
For batch jobs ...
autoqa post-koji-build-batch --kojitag
dist-f13-updates-testing-pending kdepim-runtime-4.4.9-1.fc13
6:kdepim-4.4.9-2.fc13
Same as above, this isn't a koji build event that we are monitoring, it
should be a bodhi-update event, right? More appropriately,
bodhi-update-batch. I would expect to see this triggered something
like ...
autoqa post-bodhi-update-batch --target-tag dist-f13-updates-testing
--arch i686 --arch x86_64 --updateid FEDORA-2011-0146 --updateid
FEDORA-2011-0147 kdepim-runtime-4.4.9-1.fc13 6:kdepim-4.4.9-2.fc13
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 :)
It does, but I think we do want to schedule both events (koji build and
bodhi update). The set of tests that respond to the koji build events
are different from the set that responds to bodhi updates. All related
to my earlier comment.
I think we are combining the event being monitored and the
implementation for monitoring the event. But I keep thinking the event
is separate and distinct, while the implementation can be
shared/similar. Apologies if I'm completely missing something with the
patchset. If so, it might be easier for me to catch-up with you on
IRC/phone.
Thanks again,
James
5:21 a.m.
Ah, I see your point, and totally agree. I'll adjust the watcher
so it triggers post-bodhi-update on the -pending.
Thanks for the feedback, don't know how this slipped my mind :)
Joza
----- Original Message -----
From: "James Laska" <jlaska(a)redhat.com>
To: "AutoQA development" <autoqa-devel(a)lists.fedorahosted.org>
Sent: Thursday, January 13, 2011 5:01:48 PM
Subject: Re: New Koji Watcher (watching -pending tags & batch possibility)
On Thu, 2011-01-13 at 05:45 -0500, Josef Skladanka wrote:
> 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.
I agree, doesn't make sense to have each watchers cachedir in
autoqa.conf. I was thinking we might want the cachedir root, shared by
all watchers (/var/cache/autoqa), configurable in autoqa.conf.
Definitely falls into the "future optimization" category :)
> > 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.
I see what you mean, but I'm hesitant to break the separation that has
existed between the watchers in the upcoming next release, and fix it
later.
For example, we have a different potential set of tests that are
triggered by 'post-koji-build' and by 'post-bodhi-update'. I
understood
these tickets to mean we wanted to 1) adjust the existing
post-bodhi-update watcher to use the more reliable koji -pending tags
for monitoring, and 2) Add a batch event for bodhi-updates. Since both
watchers need similar code, I expected there to be a lot of sharing,
but
I think we still need to distinguish between the two different test
events.
For example, if I run the new koji watcher ...
> # python hooks/post-koji-build/watch-koji-builds.py --dryrun
> autoqa post-koji-build --kojitag dist-f13-updates-candidate --arch
> x86_64 oxygen-gtk-1.0.1-1.fc13
This looks correct, and matches what the previous post-koji-watcher
would emit.
> autoqa post-koji-build --kojitag dist-f13-updates-pending --arch
> x86_64 pam_ssh-1.97-4.fc13
This seems incorrect, since it will schedule post-koji-build tests for
that update. We'd want the set of tests defined for bodhi updates. I'd
expect to see this scheduled as ...
> autoqa post-bodhi-update --title pam_ssh-1.97-4.fc13 --updateid
> FEDORA-2011-0146 --target-tag dist-f13-updates --arch i686 --arch
> x86_64 --arch noarch pam_ssh-1.97-4.fc13
Whether the underlying mechansim is querying bodhi, or inspecting koji
-pending tags, our tests need to distinguish between these different
events still.
For batch jobs ...
> autoqa post-koji-build-batch --kojitag
> dist-f13-updates-testing-pending kdepim-runtime-4.4.9-1.fc13
> 6:kdepim-4.4.9-2.fc13
Same as above, this isn't a koji build event that we are monitoring,
it
should be a bodhi-update event, right? More appropriately,
bodhi-update-batch. I would expect to see this triggered something
like ...
> autoqa post-bodhi-update-batch --target-tag dist-f13-updates-testing
> --arch i686 --arch x86_64 --updateid FEDORA-2011-0146 --updateid
> FEDORA-2011-0147 kdepim-runtime-4.4.9-1.fc13 6:kdepim-4.4.9-2.fc13
> 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 :)
It does, but I think we do want to schedule both events (koji build
and
bodhi update). The set of tests that respond to the koji build events
are different from the set that responds to bodhi updates. All related
to my earlier comment.
I think we are combining the event being monitored and the
implementation for monitoring the event. But I keep thinking the event
is separate and distinct, while the implementation can be
shared/similar. Apologies if I'm completely missing something with the
patchset. If so, it might be easier for me to catch-up with you on
IRC/phone.
Thanks again,
James
_______________________________________________
autoqa-devel mailing list
autoqa-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/autoqa-devel
7:26 a.m.
On Fri, 2011-01-14 at 06:21 -0500, Josef Skladanka wrote:
Ah, I see your point, and totally agree. I'll adjust the watcher
so it triggers post-bodhi-update on the -pending.
Thanks for the feedback, don't know how this slipped my mind :)
I'm still not 100% comfortable with combining the two different watcher
scripts into a single script. I agree we shouldn't duplicate the code
between the two. I'm partial to having two distinct watcher scripts,
that share the same code-base through a library. I'm not sure why,
maybe just familiarity with the current separation.
The important thing is that as long as we can clearly articulate that we
monitor for different events: post-koji-build, post-bodhi-update and
post-bodhi-batch-updated, it doesn't matter if it's all a single watcher
script triggering the events. I wouldn't want to advertise to test
authors that in order to monitor for bodhi-updates, you trigger on
'post-koji-build' with tag.endswith('-pending'). That exposes too much
implementation detail that the test author shouldn't need to know.
Thanks,
James
6:40 a.m.
Finally a few coding comments from me:
lib/python/util.py:
-def get_basearch():
+def get_basearch(arch = None):
'''like get_arch, but returns the basearch (as used by yum
etc.)'''
- arch = os.uname()[4]
+ if arch == None:
+ arch = os.uname()[4]
if arch in ('i486', 'i586', 'i686'):
arch = 'i386'
elif arch == 'ppc64':
Please adjust the docstring, thanks.
hooks/post-koji-build-batch/README:
The watcher is actually in the post-koji-build directory, because querying Koji
takes quite a lot of time, and we do not need to do it twice.
It runs quite fast right now (jskladan made some optimizations), the
code sharing is the main reason for now I believe.
hooks/post-koji-build/watch-koji-builds.py:
watch-koji-builds.py:
if tag.endswith('-pending'):
harnesscall += ['post-bodhi-update-batch']
We don't have hooks/post-bodhi-update-batch/ directory, this shouldn't work?
There's also a lot of commented out code, maybe it's ready for deletion?
Sample output of the script:
Scheduling koji events for dist-f14-updates-candidate
autoqa autoqa post-koji-build --kojitag dist-f14-updates-candidate --arch x86_64 --arch
i386 wireshark-1.4.3-1.fc14
There seems to be 'autoqa' word listed twice.
And some generic comments:
jskladan wrote:
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.
Do we have this situation covered?
1. koji watcher runs at 13:00.
2. build foo-1.1 is tagged with -updates-candidate at 13:01.
3. build foo-1.1 is tagged with -updates-pending at 13:03.
4. koji watcher runs at 13:05.
In this situation we can't remove foo-1.1 from -updates-candidate
list, can we?
jskladan wrote:
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.
But the post-bodhi-update watcher script should be deleted shortly,
right? IIUC the bodhi watcher script shouldn't be needed anymore,
everything will be managed by the koji watcher.
jlaska wrote:
The important thing is that as long as we can clearly articulate that we
monitor for different events: post-koji-build, post-bodhi-update and
post-bodhi-batch-updated, it doesn't matter if it's all a single watcher
script triggering the events. I wouldn't want to advertise to test
authors that in order to monitor for bodhi-updates, you trigger on
'post-koji-build' with tag.endswith('-pending'). That exposes too much
implementation detail that the test author shouldn't need to know.
Definitely. I agree it's better to keep the different hook names
and let tests distinguish the events according to that hook name.
On the other hand, I'm not really opposed to having a single script
triggering those events (post-koji-watcher). The code is so similar
that yes, we could do a shared library and have two (or four)
distinct watchers, but it looks like a waste of energy.
The problem is that we've hit limits in our architecture (which
happens often, every time a new use case appears). As usual, we
need to change some basics a bit and refactor the relevant code.
Currently, things like collapsing architectures (running tests
for several archs at once) or batching events makes the whole our
process look quirky. We have to re-think some stuff a bit.
Some basic changes are already shaping in my mind. For example,
(as josef correctly noted), the important information for a test
is the event type - not the watcher script name! Until now, the
event type matched the hook name 1:1. That's no longer the case.
I believe we will soon remove the hook name from autoqa command
line and use event name instead. Then it won't really matter if
one hook triggers two different events or two different hooks
trigger the same event.
We will have to remake events batching into a single common layer
between the hooks and the tests. We can't implement this in the
individual hooks forever (it won't be possible with Fedora Message
Bus).
Etc, etc.
Those are larger changes, however, so I think currently the proposed
approach is sufficient. It also better aligns with my future ideas.
9:04 a.m.
On Mon, 2011-01-17 at 07:40 -0500, Kamil Paral wrote:
<snip>
Some basic changes are already shaping in my mind. For example,
(as josef correctly noted), the important information for a test
is the event type - not the watcher script name! Until now, the
event type matched the hook name 1:1. That's no longer the case.
I believe we will soon remove the hook name from autoqa command
line and use event name instead. Then it won't really matter if
one hook triggers two different events or two different hooks
trigger the same event.
Yeah, I agree. The important thing is the event name, not so much the
watcher name. Thanks for articulating this.
We will have to remake events batching into a single common layer
between the hooks and the tests. We can't implement this in the
individual hooks forever (it won't be possible with Fedora Message
Bus).
Etc, etc.
Thanks,
James
5:26 a.m.
Thanks for the feedback, Kamil!
Responses inside:
----- Original Message -----
From: "Kamil Paral" <kparal(a)redhat.com>
To: "AutoQA development" <autoqa-devel(a)lists.fedorahosted.org>
Sent: Monday, January 17, 2011 1:40:01 PM
Subject: Re: New Koji Watcher (watching -pending tags & batch possibility)
Finally a few coding comments from me:
>lib/python/util.py:
>-def get_basearch():
>+def get_basearch(arch = None):
> '''like get_arch, but returns the basearch (as used by yum
> etc.)'''
>- arch = os.uname()[4]
>+ if arch == None:
>+ arch = os.uname()[4]
> if arch in ('i486', 'i586', 'i686'):
> arch = 'i386'
> elif arch == 'ppc64':
Please adjust the docstring, thanks.
Done, thanks for spotting this.
>hooks/post-koji-build-batch/README:
>The watcher is actually in the post-koji-build directory, because
>querying Koji
>takes quite a lot of time, and we do not need to do it twice.
It runs quite fast right now (jskladan made some optimizations), the
code sharing is the main reason for now I believe.
Well, the code sharing, and time too - querying Koji for all the tags
takes about 90 seconds, so no need to query it twice, since we already
have the data.
>hooks/post-koji-build/watch-koji-builds.py:
>watch-koji-builds.py:
> if tag.endswith('-pending'):
> harnesscall += ['post-bodhi-update-batch']
We don't have hooks/post-bodhi-update-batch/ directory, this shouldn't
work?
Good catch, I'll add the bodhi-update-batch directory.
Sample output of the script:
>Scheduling koji events for dist-f14-updates-candidate
>autoqa autoqa post-koji-build --kojitag dist-f14-updates-candidate
>--arch x86_64 --arch i386 wireshark-1.4.3-1.fc14
There seems to be 'autoqa' word listed twice.
Fixed, thank you for spotting this.
And some generic comments:
>jskladan wrote:
>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.
Do we have this situation covered?
1. koji watcher runs at 13:00.
2. build foo-1.1 is tagged with -updates-candidate at 13:01.
3. build foo-1.1 is tagged with -updates-pending at 13:03.
4. koji watcher runs at 13:05.
In this situation we can't remove foo-1.1 from -updates-candidate
list, can we?
I've already discussed this with jlaska (shame on me for not sharing
the output of our weekly chat on the list), and I've removed this
functionality. It came from my misunderstanding (at the moment).
The commented code you've been pointing out contains this 'filtering'.
I'll clean the commented parts shortly.
>jskladan wrote:
>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.
But the post-bodhi-update watcher script should be deleted shortly,
right? IIUC the bodhi watcher script shouldn't be needed anymore,
everything will be managed by the koji watcher.
Yes, true, I was just not sure if we'll be deleting the post-bodhi wather
(see the "Post-bodhi-watcher and -pendig tags differences" thread),
but if we feel like this is OK and sorted out, I have no problem with it,
just that I don't feel to be capable of deciding this on my own :)
>jlaska wrote:
>The important thing is that as long as we can clearly articulate that
>we
>monitor for different events: post-koji-build, post-bodhi-update and
>post-bodhi-batch-updated, it doesn't matter if it's all a single
>watcher
>script triggering the events. I wouldn't want to advertise to test
>authors that in order to monitor for bodhi-updates, you trigger on
>'post-koji-build' with tag.endswith('-pending'). That exposes too
>much
>implementation detail that the test author shouldn't need to know.
Definitely. I agree it's better to keep the different hook names
and let tests distinguish the events according to that hook name.
On the other hand, I'm not really opposed to having a single script
triggering those events (post-koji-watcher). The code is so similar
that yes, we could do a shared library and have two (or four)
distinct watchers, but it looks like a waste of energy.
The problem is that we've hit limits in our architecture (which
happens often, every time a new use case appears). As usual, we
need to change some basics a bit and refactor the relevant code.
Currently, things like collapsing architectures (running tests
for several archs at once) or batching events makes the whole our
process look quirky. We have to re-think some stuff a bit.
Some basic changes are already shaping in my mind. For example,
(as josef correctly noted), the important information for a test
is the event type - not the watcher script name! Until now, the
event type matched the hook name 1:1. That's no longer the case.
I believe we will soon remove the hook name from autoqa command
line and use event name instead. Then it won't really matter if
one hook triggers two different events or two different hooks
trigger the same event.
We will have to remake events batching into a single common layer
between the hooks and the tests. We can't implement this in the
individual hooks forever (it won't be possible with Fedora Message
Bus).
Etc, etc.
Those are larger changes, however, so I think currently the proposed
approach is sufficient. It also better aligns with my future ideas.
+1
Thanks for the comments, updated version will land in git during this
afternoon.
Joza
4:28 a.m.
This patch has been finally pushed to master:
http://git.fedorahosted.org/git/?p=autoqa.git;a=commit;h=547f74ca67ca6e7d...
We solved problems with Bodhi and missing pending tags etc., so now it should work
correctly. lmacken should also be pushing some Bodhi fix soon, which should correct some
further problems.
4809
days inactive
4856
days old
autoqa-devel@lists.fedorahosted.org
9 comments
3 participants
participants (3)
-
James Laska -
Josef Skladanka -
Kamil Paral