Project

General

Profile

Actions

action #40772

closed

Proper display of cluster/dependencies

Added by coolo about 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2018-09-10
Due date:
% Done:

0%

Estimated time:

Description

We currently display parents and childrens of a job in #settings. This is not really good enough,
as the scheduler looks at the whole cluster - and we should display this properly.

https://circleci.com/workflow-run/7e4b4319-755a-4cb9-836f-9fc74b10910d looks like a good analogy, but
hopefully there are ready made libraries to render this.

Actions #1

Updated by coolo about 6 years ago

To illustrate the problem:
https://openqa.suse.de/tests/2033801#settings has one parent and one child - but the parent has actually 8 children, so we talk at least about 9 jobs to be considered. If just one of them has a chained dependency, you won't be able to detect the reason it stays in scheduled within reasonable time.

Actions #2

Updated by coolo about 6 years ago

Actions #4

Updated by mkittler about 6 years ago

Not a new idea actually.

When implementing this, we should keep in mind that we might want this graph on multiple pages: https://progress.opensuse.org/issues/15850, https://progress.opensuse.org/issues/18402

Additionally, I suppose those tickets should be postponed until we implement displaying the dependencies properly.

D3 looks good. And it wouldn't be hard to use considering the examples. However, how should a job be represented in the graph? I mean a graph of dots looks cool, but it is still kind of useless without knowing which point corresponds to which job. So likely the label placement example fits best here. I've just played around with it and it should be possible to customize it, eg. adding a tool-tip would be quite simple.

Actions #5

Updated by coolo about 6 years ago

I find this a lot of code compared to http://visjs.org/examples/network/edgeStyles/arrows.html

Actions #6

Updated by coolo about 6 years ago

I personally find the other places good enough - the icons used make it clear that it's part of a cluster. And if I want to know the details, I can go to any of the jobs within the cluster and get a full picture of the cluster within its details. So to me this is clearly a tab within tests/X

Actions #7

Updated by mkittler about 6 years ago

  • Assignee set to mkittler
Actions #8

Updated by mkittler about 6 years ago

  • Status changed from New to In Progress
  • Target version changed from Ready to Current Sprint
Actions #9

Updated by mkittler about 6 years ago

  • Status changed from In Progress to Resolved

PR is merged

Actions #10

Updated by mkravec about 6 years ago

Thanks for this change, it looks much better now.

Will it be possible to see parent/children relation also on dependencies tab?
It's quite important info for test writers - mostly when using mutexes.

Currently PARALLEL_WITH groups cluster jobs in single "blue box", we lost parent/children info that was on settings tab.
CaaSP for example: https://openqa.suse.de/tests/1760064#dependencies

Actions #11

Updated by coolo about 6 years ago

the parent is on top, no?

Actions #12

Updated by mkittler about 6 years ago

the parent is on top, no?

Not necessarily. That information is lost indeed. Each job which belongs to a cluster only has a cluster ID but no special role within the cluster anymore.

@mkravec Which job the parent is and which job the child is doesn't make a difference for PARALLEL_WITH dependencies. You get the same behavior if you switch those roles. Hence I thought it wouldn't be a problem to loose that information. I could add the information to the tooltip if that's required.

Actions #13

Updated by mkravec about 6 years ago

@mkittler it matters from test writer POV, for example:

  • running job - when parent dies, all children die - we need to handle log export from child jobs in case of parent failure
  • lockapi - if mutex owner is a child job then job_id has to be used - mutex_lock($name, $owner_id)
  • clone_job - only cloning child jobs work - because it clones parent automatically
Actions #14

Updated by mkittler about 6 years ago

good example for demo (3 chain levels, 2 cluster): https://openqa.suse.de/tests/2196682#dependencies

Actions #15

Updated by mkittler about 6 years ago

@mkravec Added the information to the tool-tip: https://github.com/os-autoinst/openQA/pull/1840 Seems like GitHub wasn't actually able to create that PR. I'll try it again when GitHub has fixed their issues.

Actions #16

Updated by mkravec about 6 years ago

@mkittler thank you

Actions #17

Updated by coolo almost 6 years ago

  • Target version changed from Current Sprint to Done
Actions

Also available in: Atom PDF