652454 - Switch to using a supported Bugzilla API for adding comments, no matter how horrid that API is

Status: RESOLVED WONTFIX

(Tree Management Graveyard :: TBPL, defect)

Description

[Phil Ringnalda (:philor)]

tbpl uses BzAPI to comment on starred failures, because it's non-horrid and the supported XMLRPC Bugzilla API is... XMLRPC.

However, as bug 652452 and the way the reaction to the bmo upgrade having broken tbpl being "tell gerv" show, using BzAPI makes our bus number 1. If Gerv is not available, then tbpl no longer comments on bugs. If Gerv never again becomes available, then tbpl never again comments on bugs, though I suppose plenty of people would call that a feature.

Comment 1

[Max Kanat-Alexander]

Note that Bugzilla also supports JSON-RPC, if you prefer that.

(And hopefully BzAPI will be integrated into Bugzilla in the future by some willing soul.)

Comment 2

[Gervase Markham [:gerv]]

<cough> bug 652505. It seems at the moment that using the official API would not have helped - that's what BzAPI uses, and that's what's broken.

The reaction "tell gerv" was probably the wrong first reaction. But even if it was the right thing to say, what's wrong with that? When you upgrade, stuff breaks, and the people responsible fix it. 

Also, you can't have both "anyone necessary is around for instant fixes to problems" and also "we'll do the upgrade at a time no-one's around".

Gerv

Comment 3

[(no longer active)]

Bug 652505 has been fixed, but this bug still persists.  This is blocking a number of tools that people rely on from working.  Setting the priority to blocker because of that.

Gerv, can you please see why this is still failing on BzAPI's end?

Comment 4

[(no longer active)]

Seems like bug 652505 was all that there was to be done here.

Comment 5

[Phil Ringnalda (:philor)]

I think you were confused about what bug this was, twice in a row.

Comment 6

[Gervase Markham [:gerv]]

philor: so why is it that you think using BzAPI adds extra unreliability to tbpl's commenting on Bugzilla bugs? That certainly hasn't been true for this upgrade - it was a Bugzilla core problem with their API (which is what you might use in the alternative) and I, the BzAPI maintainer, was the person who worked out what the problem was.

BzAPI has a 1000-test test suite which is regularly run against stable and development Bugzilla versions, and against a copy of the BMO code. Things breaking in BzAPI, or things BzAPI uses, are much more likely to be found more quickly than other things.

I am currently the only person working on BzAPI, but that's because more people are not needed. There's good docs and a good test suite; if I get hit by a bus, others could step in.

Gerv

Comment 7

[Phil Ringnalda (:philor)]

I didn't file "switch to a more reliable Bugzilla API," I filed "switch to a supported Bugzilla API."

There certainly is more potential for unreliability in what we do now, which requires that both bmo and api-dev.bmo be up, and that both the API BzAPI uses to talk to bmo and BzAPI be working and that nothing has changed in either the Bugzilla API or BzAPI, rather than just requiring that bmo be up and have a working and unchanged API, but that's not what I filed, nor is it a problem I've seen.

What I want is that when the very same thing happens during the Bugzilla 5.0 upgrade, to have the response I get be either "let me look" or "file a bug on us." (Well, what I actually want is to be able to s/bugzilla/bugzilla-stage-tip/ or maybe /ldapuser:pass@bugzilla-stage-tip/ in my local copy of tbpl and catch it before it happens, but I'd settle for the former.) If I get that, and whoever in MoCo IT winds up doing the next upgrade can't figure it out, and all of the bmo admins and Bugzilla developers who would see the bug can't figure it out, and you come in a couple of days later and find that BzAPI is broken too, and figure it out, then I haven't lost a thing, I've only gained the chance at quicker support.

Comment 8

[Gervase Markham [:gerv]]

The reaction you got wasn't the right reaction. It should have been "Hmm, all BzAPI does is pass things on to Bugzilla, and we just changed Bugzilla. We should check that whatever API it's using is working before automatically jumping to the conclusion that BzAPI is at fault."

If you want a BzAPI installation pointed at bugzilla-stage-tip, we can certainly provide one. 

I have been very happy for months now to have IT take over and formally manage the BzAPI server as a fully-supported service, but there seems to have been no movement from their side.

Just so you know, one of the projects for the new full-time BMO team is to implement the BzAPI API on top of Bugzilla itself. Then, it won't make a difference which API you use.

Gerv

Comment 9

[Phil Ringnalda (:philor)]

I actually did this, to the point of losing interest, on a now dead hard drive. Maybe 5 minutes to switch everything but posting comments, an hour to figure out how to trick our PHP JSON library into producing the JSON the Bugzilla REST API wants, and then with everything working fine I came face to face with the fact that Bugzilla returns search results in an unhandy order, and I'd have to figure out what the close-enough-to-right order BzAPI returns them in actually is, and then I wandered off.