Generalise visualizing volumes (Docker et al)

[cglewis]

I'd like to be able to create volume nodes that show how they are linked to containers in the graph visualization. I noticed that there doesn't seem to be a topology for volumes. Are there plans for supporting this? Would this be something better suited as a plugin? I'm happy to help work on an implementation, but a bit at a loss of where to start, as I'm pretty new to this project.

[jpellizzari]

@cglewis We have some reference plugins you can check out as well as some docs on how plugins work: https://github.com/weaveworks/scope/tree/master/examples/plugins

The scope-volume-count plugin might even have some code you can re-use: https://github.com/weaveworks-plugins/scope-volume-count

[cglewis]

@jpellizzari thanks, I was looking at that last night, but it seems that I can only update values in the metadata, not create new nodes in the visualization?

[jpellizzari]

@ekimekim or @2opremio, is it possible to synthesize new nodes via a plugin?

[ekimekim]

New nodes in a topology, yes. But not new topologies (a topology in this case is a term roughly meaning 'type of node', eg. container vs pod vs deployment). A plugin can put arbitrary items into the report, but the set of topologies the app will accept is sadly hard-coded into the app. Adding a volume topology is definitely something we could support without too much extra work though, and it makes a lot of sense to have.

[rade]

Are we talking about docker or kubernetes volumes here? I was guessing the former because the OP speaks of "containers" rather than pods.

How/where would we want to visualise volumes? The OP asks for "volume nodes that show how they are linked to containers in the graph visualization". So that's either a) a new view, showing both containers and volumes, with edges representing the container->volume relationship, or b) an embedding of this new relationship into the existing container (and possibly other) views. IMO both options present serious problems: edges in all scope views represent network connections. So introducing a completely new meaning for edges is bound to be confusing. More so when these edges appear in existing views with other edges that do represent network connections.

[cglewis]

@rade yes, you're points are along the lines of what I was envisioning. I was thinking docker volumes, but either really.

I was thinking edges, much like the network edges that link containers, but perhaps some visual indicator to differentiate the two types of edges.

It might be best for this to be a different view as a peer level to processes, containers, and hosts. Or perhaps only as a plugin to reduce confusion.

I do like the idea of having all of the network links of containers and volumes links of those containers in a single viewable diagram, but I agree there would have to be some ways to visualize the relationships differently. While I do think different node icons would help, it might need something else in addition that stands out more.

[rade]

some visual indicator to differentiate the two types of edges.

That would require some front-end and back-end changes, to introduce the concept of different kinds of edges. Or conceivably one could get away with just a front-end change, by detecting when an edge goes from a container to a volume, rather than another container, and rendering it differently.

Also, as @ekimekim said, introducing volumes as a new kind of thing would require some back-end changes.

a different view

Would that view only show the relationship between containers and volumes, and not (also) container network connections?

[cglewis]

Would that view only show the relationship between containers and volumes, and not (also) container network connections?

I could see either way working, obviously keeping the network connections separate in a different would simplify this problem and make it cleaner, visually.

[2opremio]

Related #3130

[satyamz]

@2opremio @cglewis Can we close this now? More details: #3132

[bboreham]

3132 does Kubernetes volumes; it would be interesting to think about how the structures generalise to Docker volumes

[cglewis]

@satyamz sounds good to me.