Design doc for next version of user experience of the UI

[bryk]

Tracking issue: #584

---

This change is

[bryk]

Please review and CC others @dodwyer @preillyme @joeatwork @bgrant0607

[bgrant0607]

cc @pwittrock @janetkuo

[janetkuo]

Will you add filters to tabularized resource lists? For example, filter by status, by label, ...etc. It'd be useful when, say, I want to find all failing pods with label "app=nginx, track=stable", or I want to hide all resources with 0 replicas.

[janetkuo]

Some resources have hierarchical relationships. For example, a Deployment manages multiple ReplicaSets, each manages multiple Pods. How do you plan to present that relationship (parent/children) in the detail page of each resource?

Does it look like this:

Deployment foo:

• ReplicaSet: foo-123, foo-456, ... (the children)
• Pods: foo-123-aaa, foo-456-aaa, ... (the grandchildren?)
• Service: foo-service

ReplicaSet foo-123:

• Deployment: foo (the parent)
• Pods: foo-123-aaa, foo-123-bbb (the children)
• Service: foo-service

Pod foo-123-aaa:

• Deployment: (grandparent?)
• ReplicaSet: (parent)
• Service: foo-service

Service foo-service:

• Deployment:
• ReplicaSet:
• Pods:

[janetkuo]

Do we plan to show that hierarchical relationships in the apps view, too?

[bgrant0607]

Ref #21

[bgrant0607]

Cards are suitable for <= 6 IMO

[bgrant0607]

We need to keep multiple audiences and scenarios in mind. I outlined some operational scenarios on #21.

Personally, I think most people running workloads in production won't mutate them with the UI:
http://martinfowler.com/bliki/InfrastructureAsCode.html

However, one scenario I didn't cover is demos. The current functionality is aimed at that use case, IMO (as was kube-ui), and there's more we could do there, such as visualizations of cluster and app topology.

[bryk]

Cards are suitable for <= 6 IMO

Abstracting from the actual number, I think we agree that cards dont scale.

Personally, I think most people running workloads in production won't mutate them with the UI:
http://martinfowler.com/bliki/InfrastructureAsCode.html

Yes, I generally agree. That's why we're focusing on displaying data for now. However, edit functionality in the UI is still very useful for one-off operations that you dot automate (e.g., kill zombie pod, change service IP address, etc).

[bgrant0607]

Also be aware that Templates are coming:
https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/templates.md

[bgrant0607]

It's kind of weird that controllers have endpoints.

The unstructured Pods column is problematic IMO

[bgrant0607]

I'd eliminate endpoints, but we should think about where we could provide links to the app, that would hit external IPs/ports of the service, or would use the apiserver proxy.

[bryk]

I'd eliminate endpoints, but we should think about where we could provide links to the app, that would hit external IPs/ports of the service, or would use the apiserver proxy.

Yeah, endpoints are problematic, but, in reality, very useful. Perhaps this needs better title/wording/documentation. Perhaps this can be moved to the unstructured part of the card.

But this is a problem with the specific page, not the proposed new UX language here. I assume non blocker.

[bryk]

The unstructured Pods column is problematic IMO

What's the problem? Should it be structured and split into a few columns?

[bgrant0607]

Yes, exactly, pods should be structured and split into a few columns, to facilitate sorting.

[pwittrock]

As of release 1.2, the kubelet exposes disk usage metrics via the new metrics api. This would be something good to expose as well.

[pwittrock]

Would it be of use to have a "Nodes" section and / or have the pod link to which node it is running on. I am of 2 minds on this. On the one hand, when things are working well users should be able to abstract away the concept of nodes and just know things run in the cluster. On the other hand, if a node gets in a bad state the user is going to need to know about it and take action.

[bgrant0607]

I'm still looking through this, but overall I like the direction.

[pwittrock]

In the Apps overview section, should there be 1 global search bar that applies to all the app types instead of separate search bars for each?

[pwittrock]

Does clicking on a replica set link to all of the associated pods?

[bgrant0607]

@pwittrock see "Replication Controller details overview". That page includes the pods.

[bgrant0607]

@pwittrock Re. search box: One advantage of per section is that the search can automatically narrow to that section.

[bgrant0607]

@pwittrock A "Node details" page would be an appropriate cluster-admin view.

[bgrant0607]

@bryk Recent changes would be determined how? Watch?

[bgrant0607]

cc @mml

[bgrant0607]

@janetkuo Right now, it looks like relationships are shown on details pages, such as "Replication Controller details overview". I agree it might be useful to group by service (in the case of definite selector overlap kubernetes/kubernetes#19830) on the Apps page, and to group by controllers in the pods list, which I think should be a separate page, or maybe a toggled view, with the pods interleaved between controllers.

[bgrant0607]

Is there a button or selection to view the yaml/json for every resource?

[bryk]

@bgrant0607

I like the increased info density, but lightly coloring alternating rows would be helpful to visually break up the display. It would also be nice to select the number of items displayed per section (like gmail inbox) and to be able to collapse sections on the Apps page

This is just wireframes, so things look big. I hope we'll get dense display.

Selecting numbers of items displayed and collapsing - I like this. But for Q3+. Will add to future work section.

[bryk]

@bgrant0607

Deployment is not shown in the mocks. Is that deliberate? I'd put it at the top of the Apps view, above Replica Sets.

No. The example we used just does not cover everything. In actual implementation it'd be there.

[bryk]

PTAL. Responded to all comments and updated mocks.

I think we're in pretty good state with this proposal. I see many feature requests that I mostly sadly defer for future, since we have tight Q2/1.3 schedule.

[jwforres]

Along those same lines... we exposed a YAML editor for all resources, it
provides a stopgap solution to edit anything until you can provide a rich
GUI editor for that particular resource. FWIW we picked ACE editor but it
was a toss-up between that and codemirror. I believe it came down to ACE
having better OOTB support for YAML syntax highlighting

On Fri, Apr 1, 2016 at 4:42 AM, Piotr Bryk [email protected] wrote:

@bgrant0607 https://github.com/bgrant0607

Is there a button or selection to view the yaml/json for every resource?

Yes, we discussed to add it to every details page of a resource. The use
case is that somebody wants to "export" the resource, do some work on it in
CLI or the UI does not handle some case.
I'll update the mocks to reflect this.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#589 (comment)

[jwforres]

We called our tab "Terminal", and yeah its exec. One annoying thing is the
API not supporting SIGWINCH signal still, there is an open issue for it.
So the terminal can't be responsive.

On Fri, Apr 1, 2016 at 4:51 AM, Piotr Bryk [email protected] wrote:

@bgrant0607 https://github.com/bgrant0607

I assume that "ssh" is actually exec?

Yes

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#589 (comment)

[cheld]

CC @fwalker

[bgrant0607]

@bryk Please file issues for the suggestions you'd like to defer to future work.

[bgrant0607]

@bryk Also please post an announcement to kubernetes-dev to point the contributor community at large to this proposal.

[bgrant0607]

@bryk Do you plan to update this proposal at all or are we deferring additional details to the designs of individual pages?

[bryk]

I'll update this proposal. Just were waiting for additional comments come it after I posted it on kubernetes-dev.

More designs of individual pages will come later, but I'll update the designs that are here.

[bryk]

@bgrant0607

@bryk Recent changes would be determined how? Watch?

We're hoping to get all data from the apiserver. If apiserver does not support this, we'll most likely drop the feature.

Having a history of changes for a resource was one of top feature requests we've seen. This is an important thing for us.

[bryk]

Addressed comments to the scale and navigation UX design doc.

• Changed toolbar and left nav: now combined cluster/namespace selector and user info are in the toolbar.
• Added "Future work" section with suggested items that will not happen in 1-2 quarters (mostly due to our staffing).
• Made contents of some propsed resource columns shorter (e.g., "Pods" column is no longer "1 running, 7 desired", but "1 / 3" and format is explained in a tooltip).
• Responded to comments.

PTAL

[bryk]

Ping? Is everything resolved or we need some more discussions?

If all is resolved, then let's merge this.

[janetkuo]

It's minor but some of the mockups are still showing "Apps" instead of "Workloads" and you may want to update them too:

• docs/design/mockups/23-03-2016-scale-and-navigation/category-page-template.png
• docs/design/mockups/23-03-2016-scale-and-navigation/landing-page.png
• docs/design/mockups/23-03-2016-scale-and-navigation/action-bar.png

[bgrant0607]

@bryk Please notify me directly (with @). Otherwise, it's easy for github notifications to get lost in the literally thousands of other notifications per week.

[bgrant0607]

There are some other details that could be fixed, also, such as absence of Deployment from the menus, but I'm happy to merge and iterate.