use multiCall in rpm_to_build in koji utils
ClosedPublic

Authored by garretraziel on Jul 3 2014, 8:52 AM.

Details

Summary

Optimize rpm_to_build in koji utils by using multiCall
for simultaneous downloading of several builds.

Test Plan

py.test -F testing/, run (patched) depcheck.

Diff Detail

Repository
rLTRN libtaskotron
Lint
Lint Skipped
Unit
Unit Tests Skipped
garretraziel retitled this revision from to use multiCall in rpm_to_build in koji utils.Jul 3 2014, 8:52 AM
garretraziel updated this object.
garretraziel edited the test plan for this revision. (Show Details)
garretraziel added reviewers: jskladan, kparal.

Other than that, LGTM.

libtaskotron/koji_utils.py
37–38

since this is not used anymore, please remove the line and the respective comment

37–38

Add comment explaining that the buildinfos are returned in the same respective order as the rpms on input.

53

Please explain in a comment why this (and the other similar) block of code is written like this.

jskladan accepted this revision.Jul 3 2014, 9:26 AM
This revision is now accepted and ready to land.Jul 3 2014, 9:26 AM
garretraziel updated this revision to Diff 512.Jul 3 2014, 9:51 AM
  • add comments for rpms_to_build
kparal requested changes to this revision.Jul 4 2014, 11:36 AM

I think it's fine, but I'd really like to display Koji response in the error. Separating the sections for better readability is also preferred. Eliminating duplicate queries would be a nice bonus, but it depends on how simple you could write it. This ticket is about performance optimization, but we still don't want cryptic code. But I guess it could be written in a readable manner :)

libtaskotron/koji_utils.py
41–42

If you want to be more precise here, you can use:

:param rpms: ...
:type rpms: list of str
44–45

Just a note, I like to highlight param names which makes the descriptions simpler and clearer. So for example you can write it like

... in the same respective order as in ``rpms``
63–75

I understand the purpose here - check error codes and call further queries simultaneously. However, would it be more readable if you split this into two separate cycles? Like this:

# check errors
for rpminfo in rpminfos:
  if isinstance(rpminfo, dict):
    raise ...

# request builds
self.session.multicall = True
for rpminfo in rpminfos:
  self.session.getBuild(rpminfo[0]['build_id'])
buildinfos = self.session.multiCall()
67

map->dict, if you edited this

72

Can you please also specify which RPM caused the problem and the response from Koji (error code and string)?

73

If you wanted to get really fancy, you could eliminate duplicate queries to the same build_ids. There will be probably a lot of them. You could make the list unique, and then match the results back to original list of RPMs.

81–82

Again, let's show the Koji response.

testing/test_koji_utils.py
77–87

I guess this could be extracted into a separate method that would accept two input arguments, and the return them on the first and the second call? Then you would use this method from both test_* methods (and possibly some other methods in the future).

This revision now requires changes to proceed.Jul 4 2014, 11:36 AM

Just a side note, I have tested it on 7 packages from f19-updates-testing and it took 1.4s, old method took 10.3s.

garretraziel updated this revision to Diff 534.Jul 8 2014, 10:08 AM
  • some changes to rpms_to_build
jskladan accepted this revision.Jul 8 2014, 12:58 PM

As far as I can tell, this looks fine.

kparal added a comment.Jul 8 2014, 1:14 PM

AFAIK Jan is preparing one further update to this.

garretraziel updated this revision to Diff 542.Jul 9 2014, 9:59 AM
  • remove redundant builds from query
kparal accepted this revision.Jul 9 2014, 10:19 AM
This revision is now accepted and ready to land.Jul 9 2014, 10:19 AM
tflink accepted this revision.Jul 9 2014, 1:27 PM

Looks good to me

garretraziel closed this revision.Jul 11 2014, 8:45 AM
garretraziel updated this revision to Diff 548.

Closed by commit rLTRNe80dc4835d60 (authored by Garret Raziel <boloomka@gmail.com>).