Commands to retrieve results from the Dashboard API (KCIDB data)

[padovan]

As of today,kci-dev only interacts with Maestro. It can request test on the Maestro infra and also pull Maestro results back with the kci-dev results command.

However, we also want to enable kci-dev to show results from all the data available in KCIDB. We are proposing using the dashboard API for that, as it is already being designed with efficiency in mind and their current interfaces overlap some of the cmdline usecases.

step 1: rename kci-dev results to kci-dev maestro-results`

The current results only supports the maestro API. It is quite useful for those also submitting tests to Maestro through the kci-dev, but users who only wants to check general tests results from Maestro are better off using the infra we are putting around KCIDB.

So, the core of this step is to isolate the results command that pulls directly from the Maestro API and open the path for a results command that pulls data from the Dashboard API. We can debate the name, but the core of the proposal is the split.

Having two backends for the results command (maestro and dashboard) will bring a lot of complexity, so I don't believe we should go there. Instead we should build a clean 'results' command for everyone while still maintaining the current maestro results somewhere else'

step 2: 'kci-dev results` from the Dashboard API

Implement some basic commands to get some initial experiments and users going on. We had requests to:

• see the list of hardware the test was executed on a give checkout
• download the logs for a given checkout and set of hardware
• ...this list will grow quite quickly

So, the proposal will bring experimental commands such as:

• kci-dev results status -origin=<origin> --tree <tree> --branch <branch> show quick stats about the results
• kci-dev results hardware --origin=<origin> --tree <tree> --branch <branch> list hardware tested (and possibly its tests results)
• kci-dev results fetch-log --tree <tree> --branch <branch> --filter-params...

[aliceinwire]

As of today,kci-dev only interacts with Maestro. It can request test on the Maestro infra and also pull Maestro results back with the kci-dev results command.

However, we also want to enable kci-dev to show results from all the data available in KCIDB. We are proposing using the dashboard API for that, as it is already being designed with efficiency in mind and their current interfaces overlap some of the cmdline usecases.

Actually what I was trying to do when I started writing kci-dev was to get data directly out of kcidb instead of getting it from maestro, maybe from grafana API or google cloud API?
I still think that having a dashboard api could be useful.
I'm currently looking into this case as I'm not familiar with the internal structure of dashboard but kci-dev should give the user to choose from which API to get the data, in cases like the dashboard API is unusable or unreliable.
Can you explain what already added interfaces overlap with kci-dev ?

step 1: rename kci-dev results to kci-dev maestro-results`

The current results only supports the maestro API. It is quite useful for those also submitting tests to Maestro through the kci-dev, but users who only wants to check general tests results from Maestro are better off using the infra we are putting around KCIDB.

So, the core of this step is to isolate the results command that pulls directly from the Maestro API and open the path for a results command that pulls data from the Dashboard API. We can debate the name, but the core of the proposal is the split.

Having two backends for the results command (maestro and dashboard) will bring a lot of complexity, so I don't believe we should go there. Instead we should build a clean 'results' command for everyone while still maintaining the current maestro results somewhere else'

we should have one command kci-dev results with a subcommand --source that define the source api and have one source as default that I didn't yet choose, but still configurable.

step 2: 'kci-dev results` from the Dashboard API

Implement some basic commands to get some initial experiments and users going on. We had requests to:

* see the list of hardware the test was executed on a give checkout

* download the logs for a given checkout and set of hardware

* ...this list will grow quite quickly

That are nice experimental feature for the dashboard but I doubt that log download that can be done by a simple curl on the terminal should be done by adding pressure to the dashboard.
I'm more than happy to just get the raw kcidb results and than work on it from kci-dev, mostly because from the terminal the user can do more complex parsing and visualizations than the dashboard.

#27
#26

but I'm still looking into this issue

[aliceinwire]

I see that the dashboard solution for connecting to kcidb is by connect directly to google cloud by postgresql database.
In such case I suppose that the dashboard should be the default source choice, if there is no better way to connect to kcidb without intermediary

[padovan]

I see that the dashboard solution for connecting to kcidb is by connect directly to google cloud by postgresql database. In such case I suppose that the dashboard should be the default source choice, if there is no better way to connect to kcidb without intermediary

Yes. It abstracts that complex and offers a open public API for pulling the data from. I strongly believe the Dashboard is best positioned to offer such API, they already have various queries optimizations to extract data from KCIDB efficiently. Then, in the coming months as the results command evolve, I'll be working with the Dashboard team to improve some API endpoints for us.

[padovan]

Feeback received from the community to inform our next steps: #60 (comment)