{"action":"created","issue":{"url":"https://api.github.com/repos/weaveworks/scope/issues/1032","repository_url":"https://api.github.com/repos/weaveworks/scope","labels_url":"https://api.github.com/repos/weaveworks/scope/issues/1032/labels{/name}","comments_url":"https://api.github.com/repos/weaveworks/scope/issues/1032/comments","events_url":"https://api.github.com/repos/weaveworks/scope/issues/1032/events","html_url":"https://github.com/weaveworks/scope/issues/1032","id":136388261,"number":1032,"title":"Improve global container overview of the service","user":{"login":"2opremio","id":2362916,"avatar_url":"https://avatars.githubusercontent.com/u/2362916?v=3","gravatar_id":"","url":"https://api.github.com/users/2opremio","html_url":"https://github.com/2opremio","followers_url":"https://api.github.com/users/2opremio/followers","following_url":"https://api.github.com/users/2opremio/following{/other_user}","gists_url":"https://api.github.com/users/2opremio/gists{/gist_id}","starred_url":"https://api.github.com/users/2opremio/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/2opremio/subscriptions","organizations_url":"https://api.github.com/users/2opremio/orgs","repos_url":"https://api.github.com/users/2opremio/repos","events_url":"https://api.github.com/users/2opremio/events{/privacy}","received_events_url":"https://api.github.com/users/2opremio/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/weaveworks/scope/labels/dogfood","name":"dogfood","color":"A52A2A"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2016-02-25T13:29:48Z","updated_at":"2016-02-25T21:40:38Z","closed_at":null,"body":"Here's a screenshot of the service with (only) three k8s worker nodes and not even a probe in the master node (because #1030 ):\r\n\r\n<img width=\"1769\" alt=\"screen shot 2016-02-25 at 12 42 18\" src=\"https://cloud.githubusercontent.com/assets/2362916/13319964/4ae9c396-dbbd-11e5-903b-c4aed654df29.png\">\r\n\r\nAs you can see, the edges are really tangled, plus the `uncontained` nodes don't tell us anything in the top-level view.\r\n\r\n\r\nReport: [service_report.json.gz](https://github.com/weaveworks/scope/files/146491/service_report.json.gz)\r\n\r\nWe should try to improve the rendering (yes, the never-ending problem, I wish I could provide specific suggestions). \r\n\r\n\r\nI am not sure what we could do about the  `Uncontained` nodes. I think I'd rather see them expanded into process nodes with names even if it's the container view. \r\n\r\nI think the container view makes the assumption that all your services/infrastructure is containerized, which may not be the case (like in kubernetes). \r\n\r\nFor instance, in the case of k8s, all connections go through the kube-proxy. Seeing kube-proxy instead of `Uncontained` would be better (at least you see what's that `Unconnected` node)/ However, it's not good enough because  kube-proxy handles all the connections to services, which would result in a node like:\r\n\r\n```\r\n                  _______________________\r\ncontainer x ---> |                      | ---> container a\r\ncontainer y ---> |                      | ---> container b\r\ncontainer z ---> |      kube_proxy      | ---> container c\r\n        ... ---> |                      | ---> ...\r\n                  ----------------------\r\n```\r\n\r\nIn which you have no idea where an origin connection is leading. We could make use of the kubernetes information (the service IPs and to what containers they map) to improve the view to something like this:\r\n\r\n\r\n```\r\n                        /---------> container a\r\nconteainer x ---->service1 -------> container b\r\n                        \\---------> container c\r\n\r\n                       /----------> container a\r\ncontainer y ---->service2 --------> container d\r\n                       \\----------> container e\r\n\r\n```\r\n\r\n(I didn't draw a single `a`container because it's complicated with ascii art). Or even:\r\n\r\n```\r\n_____________\r\n             |---------> container a\r\ncontainer x  |----------> container b\r\n             |---------> container c\r\n-------------\r\n\r\n_____________\r\n             |---------> container a\r\ncontainer y  |----------> container d\r\n             |---------> container e\r\n-------------\r\n```\r\n(if we don't want to show services), which would be much more useful from the application's perspective.\r\n\r\nBut it would be good to be able to still see the infrastructural view (i.e. the kubelet_node) if wanted.\r\n\r\nSo to summarize I think we should:\r\n\r\n* Improve rendering of crossed edges\r\n* Show information about uncontained nodes at the top level\r\n* Use semantic information to improve the view of the connections from and to the kube-proxy.\r\n\r\n\r\nThoughts?"},"comment":{"url":"https://api.github.com/repos/weaveworks/scope/issues/comments/188999122","html_url":"https://github.com/weaveworks/scope/issues/1032#issuecomment-188999122","issue_url":"https://api.github.com/repos/weaveworks/scope/issues/1032","id":188999122,"user":{"login":"rade","id":109109,"avatar_url":"https://avatars.githubusercontent.com/u/109109?v=3","gravatar_id":"","url":"https://api.github.com/users/rade","html_url":"https://github.com/rade","followers_url":"https://api.github.com/users/rade/followers","following_url":"https://api.github.com/users/rade/following{/other_user}","gists_url":"https://api.github.com/users/rade/gists{/gist_id}","starred_url":"https://api.github.com/users/rade/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rade/subscriptions","organizations_url":"https://api.github.com/users/rade/orgs","repos_url":"https://api.github.com/users/rade/repos","events_url":"https://api.github.com/users/rade/events{/privacy}","received_events_url":"https://api.github.com/users/rade/received_events","type":"User","site_admin":false},"created_at":"2016-02-25T21:40:38Z","updated_at":"2016-02-25T21:40:38Z","body":"> Should we still bite the bullet and make Scope work with kube-proxy in userspace mode too?\r\n\r\nAs I mentioned on slack, we need figure out how to deal with proxies in general. There are plenty of other proxies around that people use, and some of them are in userspace by necessity, i.e. the kernel does not speak HTTP.\r\n\r\nBut there seems little point in investing in scoping userspace kube-proxy, if that is not what most people will be running soon."}}