action #40772

Proper display of cluster/dependencies

Added by coolo over 1 year ago. Updated about 1 year ago.

Status:ResolvedStart date:10/09/2018
Priority:NormalDue date:
Assignee:mkittler% Done:

0%

Category:Feature requests
Target version:Done
Difficulty:medium
Duration:

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.

History

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

#2 Updated by coolo over 1 year ago

#4 Updated by mkittler over 1 year 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.

#5 Updated by coolo over 1 year ago

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

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

#7 Updated by mkittler over 1 year ago

  • Assignee set to mkittler

#8 Updated by mkittler over 1 year ago

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

#9 Updated by mkittler over 1 year ago

  • Status changed from In Progress to Resolved

PR is merged

#10 Updated by mkravec over 1 year 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

#11 Updated by coolo over 1 year ago

the parent is on top, no?

#12 Updated by mkittler over 1 year 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.

#13 Updated by mkravec over 1 year 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

#14 Updated by mkittler over 1 year ago

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

#15 Updated by mkittler over 1 year 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.

#16 Updated by mkravec over 1 year ago

@mkittler thank you

#17 Updated by coolo about 1 year ago

  • Target version changed from Current Sprint to Done

Also available in: Atom PDF