Ales, can you please tell us exactly what recipe information you need from this search? What is the purpose of your script? I'd like to understand better so that we can design a useful API. The example you gave is searching by system -- is your script trying to find the currently running recipe for a system? Or the N most recent recipes? Or does it allow arbitrary job/recipe searches? What information does it need about each job/recipe -- result? status? progress? Does it need identifying details for humans, like recipe whiteboard or job whiteboard?
Perhaps the most expedient approach would be to accept a Content-Type header on the search pages? That is, rather than design a new API, could we leverage Flask to return JSON for "Content-Type: application/json" and fall back to the existing CherryPy output otherwise?
(In reply to Dan Callaghan from comment #2) > Ales, can you please tell us exactly what recipe information you need from > this search? The recipe IDs at a minimum. I would then feed it to some other api/command designed to provide detailed recipe information. Maybe providing also the ID of the job the recipe comes from might be useful > What is the purpose of your script? I'd like to understand > better so that we can design a useful API. The particular use-case that made me file this RFE is gathering machine-usage metrics: * current (running jobs/loans) heaviest s390x users (in machine hours consumed) * heaviest s390x users (in machine hours consumed) for last 30 jobs * the same metrics but this time only for users and services from BaseOS QE (distinguished by a combination of a username and a particularly formatted job whiteboard). > > The example you gave is searching by system -- is your script trying to find > the currently running recipe for a system? Or the N most recent recipes? Or > does it allow arbitrary job/recipe searches? What information does it need both the currently running (I parse this from the machine detail page) and the N most recent (I parse that from the recipe search details). > about each job/recipe -- result? status? progress? Does it need identifying > details for humans, like recipe whiteboard or job whiteboard? having all the recipe/job properties available in the search results would be nice (configurable in a similar fashion to rpm --queryformat ?) but not necessary, only the recipe IDs matching the search criteria are.
We *really* don't want that kind of metrics gathering hitting the main application server - allowing that kind of analysis without placing additional load on production systems is why data mining systems were invented.
This reminds me of a conversation we had almost a year ago to the day, about making it actually easy for people to script up these kinds of metrics gathering tools. I imagine that until we make it just as easy for people to solve the problem via our preferred method, we will be fighting an uphill battle and will be relying on people to 'do the right thing' (not always peoples strong suit).
My scripts come from the pre-teiid days so they're probably not a representative sample of how users go about beaker metrics computation.
Agreed we need to make it easier for people to find out the "right" way to do data mining on any given instance. That's part of the rationale for bug 1012224 (per-instance theming support) - a given instance should be able to include direct URLs for instance specific documentation, error reporting and data mining/live monitoring resources. The Reports->External submenu isn't discoverable enough to count as a reasonable long term solution.