Bug 468801 - bodhi-client with "--mine" fails to return any results
bodhi-client with "--mine" fails to return any results
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: bodhi (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Luke Macken
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-28 00:50 EDT by Chris Weyl
Modified: 2016-09-19 22:39 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-20 15:23:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch implementing Option #1 & serverside #2 (1.23 KB, patch)
2008-11-19 20:20 EST, Toshio Ernie Kuratomi
no flags Details | Diff

  None (edit)
Description Chris Weyl 2008-10-28 00:50:06 EDT
Shouldn't:

[cweyl@athena bin]$ bodhi --status testing -m
0 updates found

Instead return a list of the updates I currently have in testing?

This is on an up-to-date F-9 system.
Comment 1 Toshio Ernie Kuratomi 2008-11-19 19:17:30 EST
We've identified the basic issue here: bodhi client is requesting the information from an API method that returns information whether you are logged in or not.  when logged in, it returns the list of packages.  When not logged in it returns an empty list.

There is another server side method that should do what we want but we need to write code to access it in python-fedora and bodhi-client has to be ported to use it instead of the current method.
Comment 2 Toshio Ernie Kuratomi 2008-11-19 20:10:33 EST
ugh.  So this isn't going to be as easy as I thought.  bodhi-client is currently using the fedora.client.BodhiClient.query() method.  This calls controllers.list() on the server which returns a list of updates filtered by criteria that's provided to it.  This is the method that allows unauthenticated access and therefore is causing us to fail.

There's also controllers.mine() on the server that returns a list of all the updates that the user owns. This requires an identity so it would prompt for username and password if the user was not logged in and then give us the correct values.  Unfortunately it: 1) Does not take other arguments to filter the return value and 2) Returns the list of updates as a preformatted text string so client-side filtering would have to jump through hoops.  :-(

Here's the options that I'd propose:

1) On the server in the list() method if the "mine" option is given to list() and identity.anonymous == True: response = 401; return dict()  This will raise an AuthError on the clientside so that the user will be asked for a password and then the server will be queried with a proper identity.

2) On the server, in the mine() method, do not turn the list of updates into a text string.  That way the client code (in fedora.client.BodhiClient) can filter according to the values passed into it.  The client code will also have to be ported to use the new mine() method in the client API.

3) On the server, in the mine() method, take optional keyword params that do the filtering serverside.  Then port the client code tothe new mine() method in the client API.

I think that #1 is the best choice for fixing this problem.  If we're going to keep the mine() method serverside, I'd implement the server portion of #2 as well as returning preformatted text from the server is just wrong ;-)
Comment 3 Toshio Ernie Kuratomi 2008-11-19 20:20:31 EST
Created attachment 324127 [details]
Patch implementing Option #1 & serverside #2

Untested patch to implement #1 and serverside #2.  If bodhi is running in the staging environment, this would be good to test there.  We'll have to wait for the freeze to be over to make this change.   Also note that 401 response code doesn't trigger AuthError until python-fedora-0.3.8 which I'll be releasing as soon as we get the other bodhi bug fix committed.
Comment 4 Bug Zapper 2009-06-09 23:06:14 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Luke Macken 2009-07-07 22:48:40 EDT
Thanks for the patch, Toshio.  I applied it to git, and will push out a new version to staging shortly.
Comment 6 Luke Macken 2009-07-20 15:23:35 EDT
This fix is now live in production.  Please re-open this ticket if you are still experiencing this issue.  Thanks!

Note You need to log in before you can comment on or make changes to this bug.