QA

I just tried it out. I logged in over the browser to https://bugzilla-next.suse.de/ going over the IDP authentication provider, same as we use for IBS. Then over the menues "Preferences", "API KEYS" I generated an API key and called

$ curl -s -H 'Bugzilla_login: okurz@suse.com' -H 'Bugzilla_api_key: XXX' 'https://bugzilla-next.suse.de/jsonrpc.cgi?method=Bug.get&params=%5B%7B%22ids%22%3A+%5B1204372%5D%7D%5D'

and I got

{"error":null,"result":{"faults":[],"bugs":[{"id":1204372,"is_cc_accessible":true,"cf_foundby":"---","product":"openSUSE Distribution","see_also":[],"creator":"caochenzi@163.com","priority":"P5 - None","creation_time":"2022-10-26T11:22:39Z","alias":[],"severity":"Major","flags":[],"blocks":[],"cf_biz_priority":"","component":"Basesystem","resolution":"","is_creator_accessible":true,"qa_contact":"qa-bugs@suse.de","assigned_to":"screening-team-bugs@suse.de","classification":"openSUSE","whiteboard":"","last_change_time":"2022-10-26T11:22:39Z","cf_blocker":"---","cf_marketing_qa_status":"---","dupe_of":null,"summary":"test filing bugs","depends_on":[],"op_sys":"Other","is_open":true,"cc_detail":[],"cc":[],"creator_detail":{"id":91750,"email":"caochenzi@163.com","real_name":"chenzi cao","name":"caochenzi@163.com"},"assigned_to_detail":{"id":87664,"real_name":"E-mail List","email":"screening-team-bugs@suse.de","name":"screening-team-bugs@suse.de"},"version":"Leap 15.3","groups":[],"status":"NEW","qa_contact_detail":{"id":7641,"name":"qa-bugs@suse.de","real_name":"E-mail List","email":"qa-bugs@suse.de"},"url":"","cf_nts_priority":"","platform":"x86-64","is_confirmed":true,"keywords":[],"cf_it_deployment":"---","deadline":null,"target_milestone":"---"}]},"id":"https://bugzilla-next.suse.de/"}

so everything looks good.

For another bug which I could see in the webUI but on the CLI using my API key that failed:

{"error":{"message":"You are not authorized to access bug #1204384. To see this bug, you must first log in to an account with the appropriate permissions.","code":102},"result":null,"id":"https://bugzilla-next.suse.de/"}

Within our code e.g. in github.com/os-autoinst/openqa_review we are passing the "auth" object which includes username and password. Likely we just need to change that part, e.g. see openqa_review/browser.py +139

Thanks Oliver for performing integration smoke test. Sign-off has been planned for end of this week and I confirmed with Cris, that during next week we should get ready for the new login method. This week my goal is to obtain key for openQA

As necessary there is a new user account which we can use, see https://gitlab.suse.de/openqa/password/-/merge_requests/3 for credentials

MTUI has connection to bugzilla using XML-RPC but after removing testopia support from MTUI it now don't use this code

btw -> https://confluence.suse.com/display/LITC/Bugzilla+-+API+access+howto is strongly recommending REST API as XML-RPC is deprecated and JSON-RPC newer got over experimental support

osukup wrote:

btw -> https://confluence.suse.com/display/LITC/Bugzilla+-+API+access+howto is strongly recommending REST API as XML-RPC is deprecated and JSON-RPC newer got over experimental support

I woudn't worry about the experimental status after having used it for so long 😉 The issue with using the new API is that we can't deploy it on the current version, so as a team we decided against doing that until the production instance provides it.

cdywan wrote:

osukup wrote:

btw -> https://confluence.suse.com/display/LITC/Bugzilla+-+API+access+howto is strongly recommending REST API as XML-RPC is deprecated and JSON-RPC newer got over experimental support

I woudn't worry about the experimental status after having used it for so long 😉 The issue with using the new API is that we can't deploy it on the current version, so as a team we decided against doing that until the production instance provides it.

--> used it for long , doesn't mean it cannot disappear --> co move to stable and preferred API isn't bad idea

>> curl -s -H 'Bugzilla_login: osukup@suse.com' -H 'Bugzilla_api_key: TOKEN' 'https://bugzilla-next.suse.de/jsonrpc.cgi?method=Bug.get&params=%5B%7B%22ids%22%3A+%5B1204372%5D%7D%5D'
{"result":null,"error":{"code":101,"message":"Bug #1204372 does not exist."},"id":"https://bugzilla-next.suse.de/"}

which looks like api works but returns invalid data ? after looking to instance it seems empty ...

• there is interesting part ... api examples in confluence have login and api key in params, not header ...?

hmm, funny thing -> example in confluence isn't valid and returns:

{'error': {'code': 32000, 'message': "When using JSON-RPC over GET, you must specify a 'method' parameter. See the documentation at https://bugzilla.readthedocs.org/en/5.0/api/Bugzilla/WebService/Server/JSONRPC.html"}, 'result': None, 'id': 'https://bugzilla-next.suse.de/'}

which is even more funny because mentioned documentation returns non-existing page .. in related bugzilla docu is mentioned XMLRPC and JSONRPC exists but links to pages with docu are invalid...

cdywan wrote:

For me it's simply not responding again. Mentioned this on ENGINFRA-1457.

Still waiting on this.

osukup wrote:

I'm working on change of openQA_review to be able use both apis ( if is api_key in config present use rest else json-rpc )

How was this unblocked now? And why does it sound like you're pursuing a very different plan now than we discussed within the team? Some reasoning would be appreciated.

@cdywan @osukup https://bugzilla-next.suse.de/ is reachable right now. I recommend you crosscheck our tooling against that instance with as little effort as possible.

For reference I'm testing with this snippet. It seems neither passing the token via headers nor params in the JSON or in the URL work... the docs say both should, and even just "token" should suffice but I'm always getting 102 for the private bug here:

for BUG in 1204372 1190670 1203578; do # non-existent public private
  echo "https://bugzilla-next.suse.de/show_bug.cgi?id=$BUG"
  curl -s -H "Bugzilla_login: $BZ_EMAIL" -H "Bugzilla_token: $BZ_API_KEY" "https://bugzilla-next.suse.de/jsonrpc.cgi?method=Bug.get&params=%5B%7B%22ids%22%3A+%5B$BUG%5D%7D%5D"
  echo .
  curl -s "https%3A%2F%2Fbugzilla-next.suse.de%2Fjsonrpc.cgi%3Fmethod%3DBug.get%26params%3D%5B%7B%22token%22%3A%22$BZ_API_KEY%22%2C%22ids%22%3A%2B%5B$BUG%5D%7D%5D"
  echo .
done

I'm also checking with Martin to confirm how the token should be passed here since it feels like the syntax may just be wrong? I expect the error won't tell me more than whether the JSON's valid.

Going ahead with a draft PR anyway to ensure things are easily testable, and maybe that also helps rule out mistakes made because of manual construction of URL's: https://github.com/os-autoinst/openqa_review/pull/219

Not sure how to fix the unit tests yet.

okurz wrote:

• Check if mtui accesses bugzilla, e.g. just call git grep

With relevant code having been recently dropped I guess there's nothing to do for mtui?

cdywan wrote:

Going ahead with a draft PR anyway to ensure things are easily testable, and maybe that also helps rule out mistakes made because of manual construction of URL's: https://github.com/os-autoinst/openqa_review/pull/219

Note that testing against the staging instance has one drawback. The database may not match. I solved this by locally injecting different bug numbers, i.e. something like this:

-        self.bugid = int(bugid_match.group(2)) if bugid_match else None                                                
+        self.bugid = 1203578 # 1190670

And both public and private bugs seem to work and show up in reports e.g. SKIP_SEND_MAIL=1 openqa-review -j ALP --query-issue-status (I'm using pip install -e . to run my local branch)