{"action":"created","issue":{"url":"https://api.github.com/repos/kubernetes/console/issues/21","labels_url":"https://api.github.com/repos/kubernetes/console/issues/21/labels{/name}","comments_url":"https://api.github.com/repos/kubernetes/console/issues/21/comments","events_url":"https://api.github.com/repos/kubernetes/console/issues/21/events","html_url":"https://github.com/kubernetes/console/issues/21","id":113101298,"number":21,"title":"Console thoughts","user":{"login":"bgrant0607","id":7725777,"avatar_url":"https://avatars.githubusercontent.com/u/7725777?v=3","gravatar_id":"","url":"https://api.github.com/users/bgrant0607","html_url":"https://github.com/bgrant0607","followers_url":"https://api.github.com/users/bgrant0607/followers","following_url":"https://api.github.com/users/bgrant0607/following{/other_user}","gists_url":"https://api.github.com/users/bgrant0607/gists{/gist_id}","starred_url":"https://api.github.com/users/bgrant0607/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bgrant0607/subscriptions","organizations_url":"https://api.github.com/users/bgrant0607/orgs","repos_url":"https://api.github.com/users/bgrant0607/repos","events_url":"https://api.github.com/users/bgrant0607/events{/privacy}","received_events_url":"https://api.github.com/users/bgrant0607/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2015-10-23T21:12:50Z","updated_at":"2015-10-27T20:38:16Z","closed_at":null,"body":"Copying from https://github.com/kubernetes/kubernetes/issues/8270:\r\n\r\nThis was discussed at the Kubernetes contributors meeting in December.\r\n\r\nFirst of all, visualization/dashboard is more important than actuation. The CLI (kubectl) is expected to be the main tool for controlling the system and applications running on it. Table-friendly views should also be incorporated into kubectl, not just a GUI. I want to ensure that we maintain a common look and feel and functionality with kubectl for analogous table views and use cases -- the primary use cases and essential information are identical. That's not to say it shouldn't support actuation, but that creates additional issues, such as SSO auth.\r\n\r\nWith respect to visualization/dashboards,  we need views that are customized to the most common use cases:\r\n\r\n1. Understanding the system architecture and/or application topology: diagram view that shows interconnection between objects\r\n2. Deployment status: what images/versions are deployed, what deployments are in progress, what pods deviate, health by deployment version, provenance info\r\n3. App debugging: for devs -- what’s failing most recently / most often, why, how often, logs, events\r\n4. System debugging: dashboard w/ system and node health, uptime, versions, config, status events, change history, surface logs (from builds, containers or container failures), what’s where (node-centric view: example visualization: http://azure.microsoft.com/blog/2014/08/28/hackathon-with-kubernetes-on-azure/)\r\n5. Resource usage analysis: how much resources  (mem, cpu, disk) are being used (current/historical, individual/distribution), usage relative to quota or limits, why did my thing run out of resources, top (sort by decreasing usage)\r\n6. App dashboard / launchpad: status overview, launch links to app-domain, custom app dashboards, links to cadvisor and/or kubelet GUIs, links to elasticsearch and heapster (logging and monitoring dashboards), etc.\r\n\r\nSome functionality is probably lacking in order to support all these views at the moment (e.g., stats collection).\r\n\r\nPresentation guidelines:\r\n* timeseries graphs: single-column, all same time-scale, for easy correlation\r\n* text:\r\n  * dense (information density)\r\n    * multi-column tables\r\n    * alternate colors of rows/columns rather than introduce whitespace\r\n  * highlight high-value content\r\n    * sort by “most important” information for the view (e.g., priority, scale, recency, eventful)\r\n    * color to highlight important/abnormal details\r\n    * don’t show fields in tables by default that are almost the default/boilerplate values\r\n* flexible grouping (e.g., tree view), filtering, sorting, searching, aggregating\r\n  * by namespace\r\n  * by labels\r\n  * by reverse label lookup\r\n  * by image\r\n  * by phase\r\n\r\nCome up with recommended semantic labels/annotation keys and meanings:\r\n* env (dev, test, stage, prod)\r\n* source/containing object/provenance\r\n* responsible party (name, email, etc)\r\n* links (urls to app-specific dashboards, GUIs, web UI, etc)\r\n* html (arbitrary html to inject link, description, status)\r\n* workload type (web frontend, database, etc.)\r\n* other descriptions\r\n* icons\r\n\r\nOther issues:\r\n* simplify user experience of dealing with multiple API objects (e.g., replication controller, template, pods)\r\n* summarization of large numbers of pods\r\n* event/status history\r\n* change history\r\n* latency\r\n* similar views in CLI\r\n* help\r\n* customizable user preferences\r\n* bookmarkable view URLs\r\n* carry filter/context across views\r\n* need to show information that’s most relevant to most people by default\r\n* link to applications: https://github.com/kubernetes/kubernetes/issues/6908\r\n\r\ncc @lavalamp @jackgr @smarterclayton @bryk @JanetKuo "},"comment":{"url":"https://api.github.com/repos/kubernetes/console/issues/comments/151636666","html_url":"https://github.com/kubernetes/console/issues/21#issuecomment-151636666","issue_url":"https://api.github.com/repos/kubernetes/console/issues/21","id":151636666,"user":{"login":"jimmidyson","id":464659,"avatar_url":"https://avatars.githubusercontent.com/u/464659?v=3","gravatar_id":"","url":"https://api.github.com/users/jimmidyson","html_url":"https://github.com/jimmidyson","followers_url":"https://api.github.com/users/jimmidyson/followers","following_url":"https://api.github.com/users/jimmidyson/following{/other_user}","gists_url":"https://api.github.com/users/jimmidyson/gists{/gist_id}","starred_url":"https://api.github.com/users/jimmidyson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jimmidyson/subscriptions","organizations_url":"https://api.github.com/users/jimmidyson/orgs","repos_url":"https://api.github.com/users/jimmidyson/repos","events_url":"https://api.github.com/users/jimmidyson/events{/privacy}","received_events_url":"https://api.github.com/users/jimmidyson/received_events","type":"User","site_admin":false},"created_at":"2015-10-27T20:38:16Z","updated_at":"2015-10-27T20:38:16Z","body":"Having the console as a \"simple\" front-end to REST APIs gives us much more flexibility to deploy extensions & build a modular (microservice-y) console. This is the approach that fabric8 has taken with the work by @gashcrumb & @jstrachan. Views & REST APIs need to be kept separate. Totally agree on moving as much stuff up into the API layer though, with JSON-encoded responses that the view  (CLI browser, etc) layers render appropriately."}}