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

Repeated colors for containers with different images #783

Open
2opremio opened this issue Dec 17, 2015 · 3 comments
Open

Repeated colors for containers with different images #783

2opremio opened this issue Dec 17, 2015 · 3 comments
Labels
chore Related to fix/refinement/improvement of end user or new/existing developer functionality component/ui Predominantly a front-end issue; most/all of the work can be completed by a f/e developer
Milestone

Comments

@2opremio
Copy link
Contributor

screen shot 2015-12-17 at 19 17 28

ecs-agent and httpserver containers use different images and yet they are represented with the same color

The same applies to weave, weaveproxy and weavescope containers. They all use different images and yet they are represented using the same color.

Here is the "by image" view:

screen shot 2015-12-17 at 19 16 20

Here's the report: https://gist.github.com/2opremio/0fa26c14f5340bd87d87

@davkal
Copy link
Contributor

davkal commented Dec 30, 2015

@2opremio Your intuition was that nodes of same color are based on the same image. That seems reasonable. In fact color is determined by a node field named rank. The backend render engine decides what to put there. In your report it was 2opremio/weaveecsdemo for all containers. I produced a screenshot that prints the rank to show it:

screen shot 2015-12-30 at 13 02 05

So the color engine works correctly. But I see 2 issues here:

  1. The ranking/grouping was not based on what your intuition would tell you (container image).
  2. It's unclear to the user what the color is based on, since we dont display the rank.

The quickfix for (1) would be to make rank more meaningful for container topologies. To fix (2) we need to associate the color with a meta data field that it is based on. The backend could mark the metafield that informs the rank with a flag, so the frontend know which one it is. Unfortunately ``2opremio/weaveecsdemo` does not appear in the node's metadata:

[
  {
    "id": "docker_container_id",
    "label": "ID",
    "value": "31f5360b12522404ce9e7e499a775b77ebb4e44f214b925fee9730ce5017b620"
  },
  {
    "id": "docker_image_id",
    "label": "Image ID",
    "value": "a4e0640a29e126734c124298e97dec0e0ff3461487939dcee89a1c55b6e70f02"
  },
  {
    "id": "docker_container_created",
    "label": "Created",
    "value": "17 Dec 15 19:00 UTC"
  },
  {
    "id": "docker_container_command",
    "label": "Command",
    "value": "/w/w bash -c set -x; sleep 7; while true; do DATA_PRODUCER_MESSAGE=`nc ${DATA_PRODUCER_NAME} 4540`; HTML=\"<html> <head> <link rel=\\\"icon\\\" href=\\\"data:;base64,iVBORw0KGgo=\\\"> <title>Weaveworks Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center><h1>Chosen data producer message:</h1> <h2>${DATA_PRODUCER_MESSAGE}</h2> </div>\"; echo -e \"HTTP/1.1 200 OK\\r\\nContent-Type: text/html\\r\\nConnection: close\\r\\nContent-Length: $(echo $HTML | wc -c)\\r\\n\\r\\n$HTML\" | nc -q 0 -l -p 80; done"
  },
  {
    "id": "weave_mac_address",
    "label": "Weave MAC",
    "value": "5e:58:8e:bf:3f:e9"
  },
  {
    "id": "weave_dns_hostname",
    "label": "Weave DNS Hostname",
    "value": "httpserver.weave.local"
  }
]

@davkal davkal assigned paulbellamy and unassigned davkal Dec 30, 2015
@paulbellamy
Copy link
Contributor

The ranking/grouping was not based on what your intuition would tell you (container image).

The ranking is based on the container image. These two nodes both render the same shade of purple for me.

container:53246d5d96efd10e1da0543b6c11d35cde757a6c7d5228718850bddf1ac85863: {
  id: "container:53246d5d96efd10e1da0543b6c11d35cde757a6c7d5228718850bddf1ac85863",
  label_major: "frontend1",
  label_minor: "vagrant-ubuntu-wily-64",
  rank: "tomwilkie/frontend",
  ...
},
container:97409c6d248fe84324c38a975dc9a2761118bb41591859480d87d9e9913ac97c: {
  id: "container:97409c6d248fe84324c38a975dc9a2761118bb41591859480d87d9e9913ac97c",
  label_major: "client1",
  label_minor: "vagrant-ubuntu-wily-64",
  rank: "tomwilkie/client",
  ...
},

@paulbellamy paulbellamy assigned davkal and unassigned paulbellamy Feb 11, 2016
@tomwilkie tomwilkie added the component/ui Predominantly a front-end issue; most/all of the work can be completed by a f/e developer label Apr 11, 2016
@davkal davkal removed their assignment Apr 12, 2016
@rade rade added this to the 0.16.0 milestone Jun 16, 2016
@davkal davkal removed this from the 0.16.0 milestone Jun 16, 2016
@rade rade added the chore Related to fix/refinement/improvement of end user or new/existing developer functionality label Jul 4, 2016
@rade rade modified the milestone: July2016 Jul 4, 2016
@rade rade modified the milestones: July2016, August2016 Aug 4, 2016
@rade rade modified the milestones: 0.18/1.0, October2016 Sep 15, 2016
@rade
Copy link
Member

rade commented Dec 5, 2016

This is really affecting the demoability of scope - the SockShop looks incredibly dull in both the k8s and ECS incarnation, will all nodes in the service views having the same colour. It also affects usability - colour are meant to be help users get their bearings in complex topologies w/o having to read / search through all labels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Related to fix/refinement/improvement of end user or new/existing developer functionality component/ui Predominantly a front-end issue; most/all of the work can be completed by a f/e developer
Projects
None yet
Development

No branches or pull requests

5 participants