Project

General

Profile

coordination #10316

[epic] Better command line options extending "client"

Added by okurz over 5 years ago. Updated 10 months ago.

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

29%

Estimated time:
(Total: 0.00 h)
Difficulty:

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 (11.8 KB) proposals.txt first-proposal szarate, 2018-01-26 17:31

Subtasks

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

action #68008: Implement a retrigger command in openqa-cliWorkable

action #68011: Implement a clone command in openqa-cliNew

action #68014: Implement monitoring via openqa-cliNew

action #68023: Allow remote cloning of jobsResolvedokurz

action #68026: Implement SKIPTO option when cloningNew

action #68029: Implement convenience wrappers around API routesNew


Related issues

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

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

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)Resolved2018-01-23

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

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

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

History

#1 Updated by okurz over 5 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 3 years ago

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

#3 Updated by coolo over 3 years ago

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

#4 Updated by coolo over 3 years ago

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

#5 Updated by coolo over 3 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 over 3 years ago

  • Target version changed from Ready to Current Sprint

#7 Updated by dasantiago over 3 years ago

  • Assignee set to dasantiago

#8 Updated by okurz over 3 years ago

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

#9 Updated by okurz over 3 years ago

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

#10 Updated by okurz over 3 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 over 3 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 over 3 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 over 3 years ago

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

Back to Product backlog

@david to

#14 Updated by EDiGiacinto over 3 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 over 3 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 over 3 years ago

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

#17 Updated by okurz over 3 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 over 3 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 over 3 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 over 3 years ago

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

#21 Updated by szarate over 3 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 over 3 years ago

  • Priority changed from High to Normal

#23 Updated by okurz over 3 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 over 3 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 over 3 years ago

  • Status changed from In Progress to New

#26 Updated by szarate over 3 years ago

  • Target version changed from Current Sprint to Ready

#27 Updated by okurz over 3 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 about 3 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 over 1 year 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 over 1 year 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 over 1 year ago

  • Status changed from Workable to In Progress

#32 Updated by cdywan over 1 year ago

  • Target version changed from Ready to Current Sprint

#33 Updated by kraih over 1 year ago

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

#34 Updated by kraih over 1 year 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

#35 Updated by kraih over 1 year ago

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

#36 Updated by cdywan over 1 year ago

  • Status changed from In Progress to Feedback

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

#37 Updated by okurz over 1 year 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.

#38 Updated by kraih about 1 year ago

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

#39 Updated by okurz about 1 year 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.

#40 Updated by cdywan about 1 year ago

  • Assignee set to cdywan

#41 Updated by cdywan about 1 year ago

  • Due date set to 2020-06-12

due to changes in a related task: #68008

#42 Updated by cdywan about 1 year ago

  • Due date set to 2020-06-12

due to changes in a related task: #68011

#43 Updated by cdywan about 1 year ago

  • Due date set to 2020-06-12

due to changes in a related task: #68014

#44 Updated by cdywan about 1 year ago

  • Due date set to 2020-06-12

due to changes in a related task: #68023

#45 Updated by cdywan about 1 year ago

  • Due date set to 2020-06-12

due to changes in a related task: #68026

#46 Updated by cdywan about 1 year ago

  • Due date set to 2020-06-12

due to changes in a related task: #68029

#47 Updated by cdywan about 1 year ago

  • Status changed from New to Workable
  • Assignee deleted (cdywan)

#48 Updated by okurz about 1 year ago

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

Thanks for detailing the epic. Tracking subtasks

#49 Updated by okurz 12 months ago

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

For now left for community :)

#50 Updated by szarate 10 months ago

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

Also available in: Atom PDF