action #10316

[epic] Better command line options extending "client"

Added by okurz about 4 years ago. Updated 12 days ago.

Status:In ProgressStart date:27/03/2018
Priority:NormalDue date:
Assignee:kraih% Done:

100%

Category:Feature requests
Target version:Current Sprint
Difficulty:
Duration:

Description

Acceptance criteria

  • AC1: openqa-client fulfills more high-level use cases with commands

Further details

I think "client" is pretty good what it offers but should be extended to be more user friendly and support some common use cases. Also see https://github.com/os-autoinst/openQA-python-client as an inspiration or alternative.

Envisioned usage

e.g. openqa rebuild --failed --job-group 'Tumbleweed' --arch x86_64

proposals.txt Magnifier - first-proposal (11.8 KB) szarate, 26/01/2018 05:31 pm


Subtasks

action #33892: Allow the client to trigger a build for a jobgroupResolvedmkittler


Related issues

Related to openQA Project - action #16188: Easier way to clone jobs for test development Resolved 23/01/2017
Related to openQA Project - action #30274: isos post sometimes trigger iso_cancel for whole product Resolved 12/01/2018
Related to openQA Project - action #30730: [tools] Improve behaviour of "isos post" when triggering ... Resolved 23/01/2018
Related to openQA Project - action #14580: Add ability to backup selected jobs/tests results outside... Resolved 31/10/2016
Duplicated by openQA Project - action #23844: [tools] Need tools to auto trigger migration milestone group Closed 01/09/2017
Duplicated by openQA Project - action #28021: Add option/script to be able to start an entire "Job group" Closed 21/11/2017

History

#1 Updated by okurz about 4 years ago

  • Subject changed from Better command line client extending/replacing "client" to Better command line options extending "client"
  • Description updated (diff)

#2 Updated by coolo over 2 years ago

  • Priority changed from Low to Normal
  • Target version set to Ready

#3 Updated by coolo over 2 years ago

  • Duplicated by action #23844: [tools] Need tools to auto trigger migration milestone group added

#4 Updated by coolo over 2 years ago

  • Duplicated by action #28021: Add option/script to be able to start an entire "Job group" added

#5 Updated by coolo over 2 years ago

  • Priority changed from Normal to High

let's raise the priority even more - as we got yet another request for this

#6 Updated by szarate about 2 years ago

  • Target version changed from Ready to Current Sprint

#7 Updated by dasantiago about 2 years ago

  • Assignee set to dasantiago

#8 Updated by okurz about 2 years ago

  • Related to action #16188: Easier way to clone jobs for test development added

#9 Updated by okurz about 2 years ago

  • Related to action #30274: isos post sometimes trigger iso_cancel for whole product added

#10 Updated by okurz about 2 years ago

I think mkittler also wanted to take a look into it. Don't know if he's in the office today though.

I also added related tickets which can give some ideas on what's wished for.

#11 Updated by mgriessmeier about 2 years ago

  • Related to action #30730: [tools] Improve behaviour of "isos post" when triggering a (sub)set of jobs with parent jobs (e.g. qcow creation jobs) added

#12 Updated by szarate about 2 years ago

  • Related to action #14580: Add ability to backup selected jobs/tests results outside of o.s.d/o.o.o added

#13 Updated by szarate about 2 years ago

  • Assignee deleted (dasantiago)
  • Target version changed from Current Sprint to Ready

Back to Product backlog

@david to

#14 Updated by EDiGiacinto about 2 years ago

Just (small) side note for who's gonna take this task: openqa-client fails when we specify an invalid json file or not existant badly:

Usage: JSON::XS::decode(self, jsonstr) at /usr/bin/openqa-client line 156.

#15 Updated by dasantiago about 2 years ago

Most of the new features requested are just features that require some repetition (like restarting all the tests, stopping all the tests), or improving some new existing features, like start a job without starting the parent job and so on...

Since some of the features overlap over the scripts we have, i thought of unifying the features.

This is my first proposal:

http://pastebin.nue.suse.com/20219/src

The invocation examples are not complete and not reflect the final result and are subject to change.
Please note that since json is returned we allow the users of the cli application to process the results in their scripts, like for example with the jq utility.

#16 Updated by szarate about 2 years ago

Saving david's proposal just in case paste app deletes it

#17 Updated by okurz about 2 years ago

In your proposal I strongly recommend to not leave any unacompanied word "test" around but stick to the definition in https://github.com/os-autoinst/openQA/blob/master/docs/GettingStarted.asciidoc#concepts . I guess your "test" is most likely "job". But then I would also be careful about the word "restart" because strictly speaking the job is never changed as it is a static result, like for what is "build" in the jenkins domain. How about "retrigger"? The word "group" is a new definition or the "job group" as defined in openQA glossary? Your overall proposal looks like you basically want to rewrite everything or just extend? I really like your complete view on what could be helpful. I would suggest though to keep the interface and functionality as is of now, e.g. openqa-client jobs/<id> delete. The implementation is less important of course and may change.

#18 Updated by coolo about 2 years ago

  • Subject changed from Better command line options extending "client" to [EPIC] Better command line options extending "client"
  • Target version changed from Ready to Current Sprint

revisiting the proposal for this sprint

#19 Updated by dasantiago about 2 years ago

okurz wrote:

In your proposal I strongly recommend to not leave any unacompanied word "test" around but stick to the definition in https://github.com/os-autoinst/openQA/blob/master/docs/GettingStarted.asciidoc#concepts . I guess your "test" is most likely "job". But then I would also be careful about the word "restart" because strictly speaking the job is never changed as it is a static result, like for what is "build" in the jenkins domain. How about "retrigger"? The word "group" is a new definition or the "job group" as defined in openQA glossary? Your overall proposal looks like you basically want to rewrite everything or just extend? I really like your complete view on what could be helpful. I would suggest though to keep the interface and functionality as is of now, e.g. openqa-client jobs/<id> delete. The implementation is less important of course and may change.

I used the terms as they are indicated in the webinterface. There's a small explanation of what i meant with each term:

Your overall proposal looks like you basically want to rewrite everything or just extend

Lots of rewriting that's for sure. My idea was the client would only wrap the web calls to openqa (a dumb client). For example, the client could have a command that would call a webservice in openqa, filter the response, and do another call to another webservice with the filtered results and then displaying to the user the outcome. Eventually we could create a webservice that does those two calls, so the client would just do one call.

#20 Updated by szarate about 2 years ago

  • Status changed from New to In Progress
  • Assignee set to szarate

#21 Updated by szarate about 2 years ago

With the changes to the openQA client in pr#1571 and pr#1564, we can now extend the client to add features/functionalities self contained running in a similar way to what OpenQA::Client::Archive is doing.

On top of that, while the ideas proposed by David are a good starting point, there are few things that are going to be needed:

  • Implement a generic wrapper that allows the client to group calls to the API The reasoning here is that what we currently have it's just a rest client that mainly just talks to the API, requiring the person to look at the api help. Having an help embedded within the client would greatly improve this, and since we have already work that generates help for the routes, this could be ported to the client, and generated while packaging.

New Functionality for the client
* Job monitoring
* Build monitoring

Extensions to Clone Job:
* Allow remote clonning (Dangerous and should be dropped :))
* Make it part of OpenQA::Client to reduce code that is repeated
* Allow using SKIPTO on tests, that basically the tests would be cloned with TEST_DEBUG=1 and then when finished, next one would start with SKIPTO already set to the initial value.

Build Administration
* Allow the client to trigger a build for a jobgroup

#22 Updated by szarate about 2 years ago

  • Priority changed from High to Normal

#23 Updated by okurz about 2 years ago

szarate wrote:

Extensions to Clone Job:

* Allow remote clonning (Dangerous and should be dropped :))

that already works, see https://github.com/okurz/scripts/blob/master/openqa_clone_job_o3 and if you "drop" it as in "remove the feature" then I would be very sad.

  • Allow using SKIPTO on tests, that basically the tests would be cloned with TEST_DEBUG=1 and then when finished, next one would start with SKIPTO already set to the initial value.

That would be nice feature in case you do not actually want to fix something but repeatedly only run one test module, e.g. to gather better statistics.

#24 Updated by szarate about 2 years ago

that already works, see https://github.com/okurz/scripts/blob/master/openqa_clone_job_o3 and if you "drop" it as in "remove the feature" then I would be very sad.

What this does, is cloning a job without downloading assets, the actual suggestion was "I would like to be able to do a clone_job without needing to download the assets manually on the remote webUI.

#25 Updated by szarate about 2 years ago

  • Status changed from In Progress to New

#26 Updated by szarate about 2 years ago

  • Target version changed from Current Sprint to Ready

#27 Updated by okurz about 2 years ago

What this does, is cloning a job without downloading assets, the actual suggestion was "I would like to be able to do a clone_job without needing to download the assets manually on the remote webUI."

uhm, what is the difference between these two? What do you mean with "needing to download the assets manually on the remote webUI." when would you need to do this?

#28 Updated by szarate almost 2 years ago

  • Assignee deleted (szarate)

uhm, what is the difference between these two? What do you mean with "needing to download the assets manually on the remote webUI." when would you need to do this?

When you need to run clone_job from your local machine, but you want to actually clone them to a different host.

Anyway, removing myself for now from this ticket.

#29 Updated by okurz 4 months ago

  • Subject changed from [EPIC] Better command line options extending "client" to [epic] Better command line options extending "client"
  • Description updated (diff)

#30 Updated by kraih 4 months ago

  • Status changed from New to Workable
  • Assignee set to kraih

I'll take a look at this after my next cache service patch. Please keep collecting ideas for client features that need shortcut commands (like openqa rebuild).

#31 Updated by kraih 3 months ago

  • Status changed from Workable to In Progress

#32 Updated by cdywan 2 months ago

  • Target version changed from Ready to Current Sprint

#33 Updated by kraih 16 days ago

I've started working on this, should have something to share soon.

#34 Updated by kraih 12 days ago

I've opened a draft PR with a first proof of concept for a new openQA client. https://github.com/os-autoinst/openQA/pull/2859

Also available in: Atom PDF