Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Separate node colors #1567

Closed
wants to merge 1 commit into from
Closed

[RFC] Separate node colors #1567

wants to merge 1 commit into from

Conversation

davkal
Copy link
Contributor

@davkal davkal commented Jun 8, 2016

Node colors are procedurally generated by a node's rank. This can be a
string like tnsfork/lb-1. Now if all the nodes share the same
prefix in their rank, e.g. tnsfork/ they will all get the same
color.

screen shot 2016-06-08 at 15 56 50

An approach to separate colors a bit more would be to remove the longest
common rank prefix and set that as the color key.

screen shot 2016-06-08 at 15 56 03

Pros:

  • colors are better separation for homogeneous rank values

Cons:

  • if 99 nodes share a prefix and one does not, the 99 will be colored
    similarly (which is what happens now)
  • if that one node appears and dissappears, the 99 nodes' colors will
    switch based on their new LCP
  • Loading details panels from other topologies may yield a different
    color because that node is loaded in isolation (LCP of that
    topology's nodes is undetermined)

Node colors are procedurally generated by a node's rank. This can be a
string like `weaveworks/lb-1`. Now if all the nodes share the same
prefix in their rank, e.g. `weaveworks/` they will all get the same
color.

An approach to separate colors a bit more would be to remove the longest
common rank prefix and set that as the color key.

Pros:

- colors are better separation for homogeneous rank values

Cons:

- if 99 nodes share a prefix and one does not, the 99 will be colored
  similarly (which is what happens now)
- if that one node appears and dissappears, the 99 nodes' colors will
  switch based on their new LCP
- Loading details panels from other topologies may yield a different
  color because that node is loaded in isolation (LCP of that
topology's nodes is undetermined)
@rade
Copy link
Member

rade commented Jun 13, 2016

The 99-1 problem is nasty; and presumably the node appearance issue would also arise for 2-1, which is also nasty.

Perhaps ranking should operate on words rather than characters, e.g. tnsfork_lb2_1 would result in three words - 'tnsfork', 'lb2', '1', which you could hash to get a series of number in MSB...LSB order for determining the colour.

@rade
Copy link
Member

rade commented Jun 16, 2016

See #783 and #1539 for the issue this is meant to fix.

Network colouring already use the prefix removal algo above, and it turns out to run into the 99-1 problem for trivial examples. I have raised #1592 for that.

So back to the drawing board.

@davkal
Copy link
Contributor Author

davkal commented Nov 24, 2016

Closing this for inactivity.

@davkal davkal closed this Nov 24, 2016
@fbarl fbarl deleted the color-prefix branch January 13, 2020 14:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants