action #40772
closedProper display of cluster/dependencies
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.
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.
Updated by coolo about 6 years ago
http://visjs.org/showcase/index.html looks promising
Updated by EDiGiacinto about 6 years ago
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.
Updated by coolo about 6 years ago
I find this a lot of code compared to http://visjs.org/examples/network/edgeStyles/arrows.html
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
Updated by mkittler about 6 years ago
- Status changed from New to In Progress
- Target version changed from Ready to Current Sprint
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
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.
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
Updated by mkittler about 6 years ago
good example for demo (3 chain levels, 2 cluster): https://openqa.suse.de/tests/2196682#dependencies
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.
Updated by coolo almost 6 years ago
- Target version changed from Current Sprint to Done