Project

General

Profile

Actions

coordination #10316

open

[epic] Better command line options extending "client"

Added by okurz almost 9 years ago. Updated about 4 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Feature requests
Target version:
QA - future
Start date:
2018-03-27
Due date:
% Done:

29%

Estimated time:
(Total: 0.00 h)

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


Files

proposals.txt (11.8 KB) proposals.txt first-proposal szarate, 2018-01-26 17:31

Subtasks 7 (5 open2 closed)

action #33892: Allow the client to trigger a build for a jobgroupResolvedmkittler2018-03-27

Actions
action #68008: Implement a retrigger command in openqa-cliWorkable2020-06-12

Actions
action #68011: Implement a clone command in openqa-cliNew2020-06-12

Actions
action #68014: Implement monitoring via openqa-cliNew2020-06-12

Actions
action #68023: Allow remote cloning of jobsResolvedokurz2020-06-12

Actions
action #68026: Implement SKIPTO option when cloningNew2020-06-12

Actions
action #68029: Implement convenience wrappers around API routesNew2020-06-12

Actions

Related issues 6 (0 open6 closed)

Related to openQA Project - action #16188: Easier way to clone jobs for test developmentResolvedokurz2017-01-23

Actions
Related to openQA Project - action #30274: isos post sometimes trigger iso_cancel for whole productResolvedXiaojing_liu2018-01-12

Actions
Related to openQA Project - action #30730: [tools] Improve behaviour of "isos post" when triggering a (sub)set of jobs with parent jobs (e.g. qcow creation jobs)ResolvedXiaojing_liu2018-01-23

Actions
Related to openQA Project - action #14580: Add ability to backup selected jobs/tests results outside of o.s.d/o.o.oResolvedszarate2016-10-31

Actions
Has duplicate openQA Project - action #23844: [tools] Need tools to auto trigger migration milestone groupClosed2017-09-01

Actions
Has duplicate openQA Project - action #28021: Add option/script to be able to start an entire "Job group"Closed2017-11-21

Actions
Actions #1

Updated by okurz almost 9 years ago

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

Updated by coolo about 7 years ago

  • Priority changed from Low to Normal
  • Target version set to Ready
Actions #3

Updated by coolo about 7 years ago

  • Has duplicate action #23844: [tools] Need tools to auto trigger migration milestone group added
Actions #4

Updated by coolo about 7 years ago

  • Has duplicate action #28021: Add option/script to be able to start an entire "Job group" added
Actions #5

Updated by coolo about 7 years ago

  • Priority changed from Normal to High

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

Actions #6

Updated by szarate almost 7 years ago

  • Target version changed from Ready to Current Sprint
Actions #7

Updated by dasantiago almost 7 years ago

  • Assignee set to dasantiago
Actions #8

Updated by okurz almost 7 years ago

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

Updated by okurz almost 7 years ago

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

Updated by okurz almost 7 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.

Actions #11

Updated by mgriessmeier almost 7 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
Actions #12

Updated by szarate almost 7 years ago

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

Updated by szarate almost 7 years ago

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

Back to Product backlog

@david to

Actions #14

Updated by EDiGiacinto almost 7 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.
Actions #15

Updated by dasantiago almost 7 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.

Actions #16

Updated by szarate almost 7 years ago

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

Actions #17

Updated by okurz almost 7 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.

Actions #18

Updated by coolo over 6 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

Actions #19

Updated by dasantiago over 6 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.

Actions #20

Updated by szarate over 6 years ago

  • Status changed from New to In Progress
  • Assignee set to szarate
Actions #21

Updated by szarate over 6 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
Actions #22

Updated by szarate over 6 years ago

  • Priority changed from High to Normal
Actions #23

Updated by okurz over 6 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.

Actions #24

Updated by szarate over 6 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.

Actions #25

Updated by szarate over 6 years ago

  • Status changed from In Progress to New
Actions #26

Updated by szarate over 6 years ago

  • Target version changed from Current Sprint to Ready
Actions #27

Updated by okurz over 6 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?

Actions #28

Updated by szarate over 6 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.

Actions #29

Updated by okurz almost 5 years ago

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

Updated by kraih almost 5 years 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).

Actions #31

Updated by kraih almost 5 years ago

  • Status changed from Workable to In Progress
Actions #32

Updated by livdywan almost 5 years ago

  • Target version changed from Ready to Current Sprint
Actions #33

Updated by kraih over 4 years ago

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

Actions #34

Updated by kraih over 4 years 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

Actions #35

Updated by kraih over 4 years ago

After many more updates the PR is no longer a draft and will be merged soon.

Actions #36

Updated by livdywan over 4 years ago

  • Status changed from In Progress to Feedback

PR got merged! (Sadly Redmine has no party emoji)

Actions #37

Updated by okurz over 4 years ago

@kraih can you comment on what you see as done and what you think should be done next? E.g. compare to the suggestions given in the ticket description. We should keep in mind that this ticket is an "epic" and hence I see it as not "workable" by itself. So we can define subtickets for specific tasks.

Actions #38

Updated by kraih over 4 years ago

I've started working on some documentation for openqa-cli. https://github.com/os-autoinst/openQA/pull/3009

Actions #39

Updated by okurz over 4 years ago

  • Status changed from Feedback to New
  • Assignee deleted (kraih)
  • Target version changed from Current Sprint to future

Discussed with cdywan as SM-PO couple. There are many proposals and some specific examples. To have a "Workable" state someone would need to create at least workable steps within the description with concrete proposals or subtickets.

Actions #40

Updated by livdywan over 4 years ago

  • Assignee set to livdywan
Actions #41

Updated by livdywan over 4 years ago

  • Due date set to 2020-06-12

due to changes in a related task: #68008

Actions #42

Updated by livdywan over 4 years ago

  • Due date set to 2020-06-12

due to changes in a related task: #68011

Actions #43

Updated by livdywan over 4 years ago

  • Due date set to 2020-06-12

due to changes in a related task: #68014

Actions #44

Updated by livdywan over 4 years ago

  • Due date set to 2020-06-12

due to changes in a related task: #68023

Actions #45

Updated by livdywan over 4 years ago

  • Due date set to 2020-06-12

due to changes in a related task: #68026

Actions #46

Updated by livdywan over 4 years ago

  • Due date set to 2020-06-12

due to changes in a related task: #68029

Actions #47

Updated by livdywan over 4 years ago

  • Status changed from New to Workable
  • Assignee deleted (livdywan)
Actions #48

Updated by okurz over 4 years ago

  • Status changed from Workable to Blocked
  • Assignee set to okurz

Thanks for detailing the epic. Tracking subtasks

Actions #49

Updated by okurz over 4 years ago

  • Status changed from Blocked to Workable
  • Assignee deleted (okurz)

For now left for community :)

Actions #50

Updated by szarate about 4 years ago

  • Tracker changed from action to coordination
  • Status changed from Workable to New
Actions

Also available in: Atom PDF