Last modified: 2014-10-16 11:52:39 UTC
To allow our many toolserver users to do exciting things with the bugzilla database which are not possible (or are very messy) to do through the web interface.
This isn't so much a WMF action item, as a TS one Max has already reported this on JIRA https://jira.toolserver.org/browse/TS-901
It probably requires action from both ends, however, because the BZ database is not (AFAIK) part of the main cluster, and so its binlogs are probably not accessible.
Don't we have "secret" bugs in the security section now? That might have to be taken into account when doing this (Although I imagine that's not much different then the other secret info which is taken into account by the toolserver).
(In reply to comment #2) > It probably requires action from both ends, however, because the BZ database is > not (AFAIK) part of the main cluster, and so its binlogs are probably not > accessible. As per Max originally, River is WMF root also, so can just do it if necessary. Granted, there is some filtering needed...
(In reply to comment #3) > Don't we have "secret" bugs in the security section now? That might have to be > taken into account when doing this (Although I imagine that's not much > different then the other secret info which is taken into account by the > toolserver). There's none yet, but there could be some someday :)
(In reply to comment #3) > Don't we have "secret" bugs in the security section now? That might have to be > taken into account when doing this (Although I imagine that's not much > different then the other secret info which is taken into account by the > toolserver). I don't that that would be any differnt than the revdel entries in the wiki dbs, which iirc are available to the ts users.
(In reply to comment #5) > (In reply to comment #3) > > Don't we have "secret" bugs in the security section now? That might have to be > > taken into account when doing this (Although I imagine that's not much > > different then the other secret info which is taken into account by the > > toolserver). > > There's none yet, but there could be some someday :) I thought there was one atm? Which obviously, go public when the fix is released...
(In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #3) > > > Don't we have "secret" bugs in the security section now? That might have to be > > > taken into account when doing this (Although I imagine that's not much > > > different then the other secret info which is taken into account by the > > > toolserver). > > > > There's none yet, but there could be some someday :) > > I thought there was one atm? Which obviously, go public when the fix is > released... I lied, there's one added since I last checked :p
Adding (likely necessary) "shell" keyword. Lowering priority since this information is available via the API, which takes care of any "secret" bug problems. I should have a demonstration of getting information out of Bz using the API shortly. For the record, I'm not saying the API is just-as-good as being able to do do raw SQL queries, but it is better than the web interface for programmatic extraction of data. Bz4 has improved on the API some, as well.
(In reply to comment #9) > Adding (likely necessary) "shell" keyword. Lowering priority since this > information is available via the API, which takes care of any "secret" bug > problems. I should have a demonstration of getting information out of Bz using > the API shortly. > > For the record, I'm not saying the API is just-as-good as being able to do do > raw SQL queries, but it is better than the web interface for programmatic > extraction of data. Bz4 has improved on the API some, as well. You mean this api: http://bugzilla.wikimedia.org/bzapi ? (The one that gives a 500 error after about a 5 minute timeout) ;)
(In reply to comment #10) > You mean this api: http://bugzilla.wikimedia.org/bzapi ? (The one that gives a > 500 error after about a 5 minute timeout) ;) I think if you align the runestones correctly you can get it to at least fail noisily (I managed to get a "you must use POST requests" out of it, can't quite remember how); but it's certainly suboptimal.
I think it used to work and was subsequently broken. I've tried queries directly out of the bugzilla docs (that work on mozilla's bugzilla instance), and they still fail here. (for example, https://api-dev.bugzilla.mozilla.org/0.9/bug/1234?include_fields=summary vs https://bugzilla.wikimedia.org/bzapi/bug/1234?include_fields=summary ). I suppose this is getting off topic though.
Has anyone actually tried the bz4 api?
Does BZ4 *have* a built-in API?
(In reply to comment #10) > You mean this api: http://bugzilla.wikimedia.org/bzapi ? (The one that gives a > 500 error after about a 5 minute timeout) ;) No, I don't mean that one. This one: https://bugzilla.wikimedia.org/jsonrpc.cgi I've been using it to build some queries and reports. See http://www.bugzilla.org/docs/3.6/en/html/api/Bugzilla/WebService/Server/JSONRPC.html for documentation. (In reply to comment #14) > Does BZ4 *have* a built-in API? Yes. http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService.html
Bugmeister is the new Bugzilla maintainer and default assignee.
Removing "shell" keyword for things that aren't directly doable by shell users etc
Adding ops keyword
Removing shell keyword if exists
Why is this assigned to Mark? And has there been any progress on this?
(In reply to comment #20) > Why is this assigned to Mark? When he became the Bugmeister, All the BZ open bugs got reassigned to him. Assigning back to wikibugs-l
Is this leaning to a WONTFIX or do we think that API is still not flexible enough and that private stuff is not a problem?
The API is not sufficient
There are XMLRPC and JSONRPC interfaces, see http://www.bugzilla.org/docs/4.2/en/html/api/Bugzilla/WebService.html - however there is no full availability of all web search options, see https://bugzilla.mozilla.org/show\_bug.cgi?id=475754 I (bug wrangler) do not plan to work on this, also considering https://meta.wikimedia.org/wiki/Future_of_Toolserver , so to me this is a WONTFIX (will not fix this request). (In reply to comment #23 by Betacommand) > The API is not sufficient Please elaborate what is needed.
Changing summary to Labs, as Toolserver will die. We have an instance on https://wikitech.wikimedia.org/wiki/Nova_Resource:Bugzilla but without data, and I think we cannot easily replicate due to privacy concerns. Happy-melon: Please elaborate some examples that you have in mind what to do, otherwise I'd say it's not worth the hassle.
From JIRA (as that ticket isn't going anywhere...): --- MZMcBride added a comment - 12 January 2011 10:52:50 The Bugzilla database schema is available here: <http://www.ravenbrook.com/project/p4dti/tool/cgi/bugzilla-schema/index.cgi?action=single&version=3.4.2&view=View+schema>. ---
(In reply to comment #25) > We have an instance on > https://wikitech.wikimedia.org/wiki/Nova_Resource:Bugzilla but without data, > and I think we cannot easily replicate due to privacy concerns. We replicate a lot of tables with much more sensitive data (the MediaWiki user table, for example). I don't think it's reasonable to argue that privacy concerns are relevant here (it's a public Bugzilla instance). There are a few database table fields that would need to be filtered out (only one, as I recall based on the database schema, but we'll assume there's more than one and say "a few"). Given that we already have tools and infrastructure in place to replicate database tables, I'm almost inclined to mark this bug with the "easy" keyword. But I'll resist. There should perhaps also be some consideration for "Security" bugs, but that would be mostly paranoia, I think. Surely the important security bugs are resolved fairly quickly. :-)
MZMcBride: I cross my fingers and hope that you'll be right - I don't know or understand the infrastructure well enough to really judge.
(In reply to comment #1) > Max has already reported this on JIRA > https://jira.toolserver.org/browse/TS-901 Who's Max? Copying from that ticket, while it's still accessible: --- Wikimedia Bugzilla database should be replicated with views to Toolserver users The Wikimedia bug tracker (<https://bugzilla.wikimedia.org/>) has a MySQL backend that's currently inaccessible to Toolserver users. It would be helpful (for statistics particularly) if the underlying databases could be exposed to Toolserver users in the same way that the MediaWiki wiki databases are exposed (using replication and views). This requires auditing the Bugzilla database schema to ensure that no private information is leaked, however doing so shouldn't be very difficult. The Bugzilla database schema is available here: <http://www.ravenbrook.com/project/p4dti/tool/cgi/bugzilla-schema/index.cgi?action=single&version=3.4.2&view=View+schema>. ---
(Wikidata also requested this.) Somebody interested in pushing this forward should bring it up on the Ops mailing list, to discuss what is needed here.
(In reply to comment #30) > [...] > Somebody interested in pushing this forward should bring it up on the Ops > mailing list, to discuss what is needed here. Eh, that's non-public AFAIK.
Meh. Still <ops@lists.wmorg> should have a moderator who allows external postings. I hope.
