Dashboard: ThirdPartyResources Page

[ianlewis]

We should allow viewing/creating/editing of ThirdPartyResources. There is a bit of UX to think about since the ThirdPartyResource types themselves can be viewed as well as the custom objects for each resource.

• How to display each ThirdPartyResource?
• How to we display the objects of each ThirdPartyResource type

[ianlewis]

This is something I'd like to look at doing; perhaps after I've finished the exec into pod feature.

[bryk]

@IanLewis Yes, this is an important feature. Definitely on track to work on after pod exec. And I agree that there are many UX challenges in this problem...

[foxish]

We have some thoughts on this as we start using TPRs alongside custom controllers as a way to represent them.
@kubernetes/sig-apps-misc

[erictune]

My take on this:

• Users think about their cluster as holding a number of "apps".
• Useful: an "app summary" view in dashboard that lists all their apps, regardless of what Kinds make up that app.
• Not as useful: Having one view which is just Deployments, another which is just StatefulSet, and another which is just TPR, etc.
• With Helm Charts, and similar packaging systems, users often won't even be aware what Kind implements their app.
• An "app" is a collection of resources, but you don't want to see most of them most of the time. There is a clear "parent" object which should be shown
  in the "app summary" view, and child objects should be hidden in a summary view, but show when you drill down on a pariticular app.
• Examples of "apps":
  
  
  
  • nginx app, parent object is Deployment, children are ReplicaSet and Pods.
  
  
  • mysql app, parent object is a StatefulSet, children are Pods and PVCs.
  
  
  • a spark job called, parent object is a TPR of type SparkJob, children are a ReplicaSets and Pods
  
  
  • there are too many possibilities to hard code.
  
  

[ianlewis]

@erictune Thanks for the input. Is this something that really has to do with ThirdPartyResources? Maybe it deserves it's own issue?

[erictune]

I commented on this issue because I am questioning the premise of this issue. Should third party resources have their own separate page, as the title of this issue suggests. Or should they be integrated into various pages alongside "first party resources"?

[ianlewis]

Ok. It sounded like a much broader idea that even things like Deployments, Services, Pods etc. should be shown differently which is why I thought different issue. And that issue could easily invalidate this issue.

[erictune]

Sorry if I came off a little strong there.

Better support for TPRs in any form is welcome. If doing this issue is the right next step, then that is welcome. Just saying where I hope we end up. Happy to file a separate issue if you like.

[ianlewis]

NP. It's cool and thanks for your comment! Emotion is something that doesn't come across well in text on the internet :)

I do worry about bandwidth but I think the idea is totally valid. I just thought it warranted more discussion (read I have lots of questions) and I tend to be biased towards creating new issues.

The idea of an "app" seems a bit vague to me. I wonder how we could tie objects together without being super opinionated about what makes up an "app". OpenShift sort of has this on it's overview page. Is that close to what you had in mind? I think it just uses the convention of service name == deployment name == ingress name currently but not totally sure.

There was a PR for a POC helm integration which also sort of feels related. https://github.com/kubernetes/dashboard/pull/1332

[ianlewis]

1570 is also related to Eric's comment since the OP expects that the entire "app" gets deleted when deleting a deployment (replicaset, services, etc.)

[davidopp]

I like @erictune 's idea. One refinement I would propose, though perhaps it's too radical, is to say that every app should have a TPR as the top-level parent. Obviously we can't force people to do this, but we could declare the pattern to be a best practice. The benefits would include

• uniformity
• Service objects can have a parent; if the parent is Deployment or StatefulSet (as in Eric's example for nginx and mysql) there isn't anywhere natural in the hierarchy to stick Service if the user wants one
• related to the previous bullet, this would address the issue @IanLewis pointed to (#1570) in a uniform way, since you could clean up the Service (and any other objects that don't fit into the single-line hierarchy)
• we could finally address kubernetes/kubernetes#14956

I agree that this should probably be split into a separate issue.

[ianlewis]

Lots of different systems that build on Kubernetes can be opinionated about how they deploy their apps, but I don't think the dashboard can be without some kind of generic best practice.

OpenShift's console seems to be able to group things but still work with generic objects but I find it frustrating to use and am often unsure about exactly what kind of object I'm looking at. I'd like to avoid some of those issues in dashboard if possible.

[ianlewis]

I created a design doc in PR #1586. For now I'd like to just support the third party resources in a generic fashion. How we deal with them may be change in the future as we figure out the idea of "apps"

The main thing I want to do is add ThirdPartyResources to the side menu alongside first party resources.

The detail page shows the ThirdPartyResource detail and a list of the objects.

Object detail shows the arbitrary JSON data in structured format

Let me know what you think.

[gurvindersingh]

I wonder if the helm based application deployment can be a starting point to support app concept in dashboard.

[ianlewis]

@gurvindersingh Yah, I thought about that too. That's why I mentioned #1332

AFAIK we still need a way to keep track of which objects belong to which "app" even after deploying. I'm not sure how helm charts does this but using the same methodology as helm uses is a possibility.

I still think dashboard will need to support objects individually for users that aren't using helm, or for helm apps that somehow got into an incomplete or broken state.

[gurvindersingh]

@IanLewis You are right about having a coupling between app concept and actual kubernetes objects. Also as you mentioned we do need to support direct objects as dashboard currently does. Not all users will be using app concept.

Helm uses ConfigMaps to store the information about the coupling. May be help team @technosophos might be able to chime in here for more info.

[erictune]

This doc has some ideas about conventions to group things into apps

[ianlewis]

For folks coming to this later, I created #1599 for the apps issue. Feel free to comment there.

[erictune]

@foxish do the above mocks make sense in the context of SparkJob resource?

[erictune]

There is an upcoming feature called APIserver aggregation. https://github.com/kubernetes/community/blob/master/contributors/design-proposals/aggregated-api-servers.md

Basically, TPR, and Aggregated API Servers (AAS) are two different ways to extend the Kubernetes API.

From the standpoint of the Dashboard, they are both "dynamic" types.

So, the UI mocks above would apply to both Third Party Resources, and to AAS resources.

I wonder if we want to plan to show both types under the same heading. From the standpoint of the user, they don't care whether TPR or AAS was used. So, maybe replace "Third Party Resources" in the UI with "Extensions" or something like that.

From an implementation standpoint, both TPR and AAS should be discoverable from the apiserver.

[ianlewis]

It seems reasonable to use "Extensions". Though I do want to caution about hiding resources and using different terminology from the CLI and Kubernetes documentation. There is already some folks who get confused because we use different terminology in the UI (ala #1523). Not everyone using Dashboard will be exclusively using Dashboard. If we do use different terminology we need to at least be consistent across docs, and ideally CLI as well.

[fabiand]

@erictune ain't AAS pretty common to be used with TPRs to i.e. ship custom admission controllers for that specific TPR?
What I want to say: Should we assume that they always come in these pairs - TPR plus a AAS?

[erictune]

That's not my understanding. You either (1) use TPR to create your
endpoint on the main apiserver and you don't get any custom admission
control on it , or you (2) write an entirely new api server with a schema
for your new resource(s) and any admission control you want, and aggregate
it with the main apiserver (hence AAS). Its one or the other, as I
understand.

On Thu, Feb 2, 2017 at 7:21 AM, Fabian Deutsch [e-mail]
wrote:

@erictune https://github.com/erictune ain't AAS pretty common to be
used with TPRs to i.e. ship custom admission controllers for that specific
TPR?
What I want to say: Should we assume that they always come in these pairs

• TPR plus a AAS?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/dashboard/issues/1504#issuecomment-276986699,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHuudsKoajWP4W3ta-1GhLi-MV0aLQCfks5rYfSLgaJpZM4LAUnL
.

[fabiand]

I do see your point, and it would be clear flows.
But don't we loose a lot of the convenience around TPRs - i.e. all the storage, manipulation and api server integration (myabe also important to enumerate all tprs?)? All of this needs to be re-written in the custom API server IIUIC. Or am I missing something?

To me it sounded like you can start with a TPR, and if you need admission control, you can use AAS to register it for that specific endpoint.

[erictune]

This summarizes what I learned about TPR and custom API servers:
https://docs.google.com/document/d/1y16jKL2hMjQO0trYBJJSczPAWj8vAgNFrdTZeCincmI/edit#

[maciaszczykm]

Last TODO thing here is detail page for instances. Other mockups are already implemented.

[foxish]

https://github.com/apache-spark-on-k8s/spark/issues/111 has some detail about the fields we want to expose.
The mocks do make sense for our use cases.