Forgot to mention: this issue relates to #145

This looks awesome proposal Gerti! Give me and others some time to review and think about it.

The [Learn more] links will reference existing K8S documentation topics as far as possible (see below for details), or, where the K8S documentation is not sufficient or needs to be extended, reference HTML pages that must be newly created.

The currently implemented tooltips can / should be extended and provide a bit more information, where applicable.

LGTM

If references to the existing K8S documentation are not sufficient, how can we provide newly created content?
Proposal: Write HTML pages and include references to K8S documentation in the new HTML pages. Is it OK to simply use the Kubernetes style sheet for the new HTML pages?

Alternative: Write markdown pages in a structure in analogy to the K8S project, and implement the generation of HTML pages in anology with the K8S documentation generation process also in the dashboard project.

I'd go for the alternative, i.e., write in markdown and generate HTML for this. The reason is that markdown is really good for writing pages of text, as opposed to HTML, which burdens you about tags/styles/etc. What do you think?

Links to the K8S documentation contain specific version information. I.e. if a specific topic of the K8S documentation shall be referenced, it is not possible to omit the version information. Currently, this is V1.1. If it is omitted in the link, the user is redirected to the K8S main documentation page.

Correct. I say that this is OKay. In 1.2 or 1.3 things may change, and we want to reference the world we know. We can do quick upgrade of all links with find&replace or storing in a common constant.

Monitoring your App: By design, a link is to be provided. But this link is not necessary since the Zero State page is only shown when no application has been deployed yet.

Troubleshooting: By design, a link is to be provided. But this link is not necessary since the Zero State page is only shown when no application has been deployed yet.

Correct. The designs here are a little bit too distant in the future :)

Will the Image pull secret field be shown if the user enters a private repo, or will there be a toggle to indicate whether the repo is private/public?

For now the input will be in "More options". We don't have an easy way to test whether a repo is private or not.

To be created: Short introduction explaining what a Replica Set is, plus link to the

What do you think about changing our wording from "Replica Set" to "Replication Controller". The name change was supposed to happen soon in K8s core, but it is not. So, to me, it is better to use what is officially supported. @cheld @floreks

Links you've provided LGTM. Let's resolve outstanding questions and implement it.

This is a really high quality writeup. Huge thanks!

What do you think about changing our wording from "Replica Set" to "Replication Controller". The name change was supposed to happen soon in K8s core, but it is not. So, to me, it is better to use what is officially supported.

I was thinking about that since the beginning of project. We should stick with k8s core naming convention.

I'd go for the alternative, i.e., write in markdown and generate HTML for this. The reason is that markdown is really good for writing pages of text, as opposed to HTML, which burdens you about tags/styles/etc. What do you think?

I agree that new doc should be written in markdown (also for consistency reasons with K8S documentation). Do you know the mechanism for generating HTML out of the markdowns? And can this just be taken over from the kubernetes project?

Do you know the mechanism for generating HTML out of the markdowns? And can this just be taken over from the kubernetes project?

K8s core has some custom code for handling markdown. We can potentially reuse it. See source: https://github.com/kubernetes/kubernetes/tree/4ca66d2aefa20c27b670b2fa890052daadc05294/cmd/mungedocs

What do you think about changing our wording from "Replica Set" to "Replication Controller". The name change was supposed to happen soon in K8s core, but it is not. So, to me, it is better to use what is officially supported.

I was thinking about that since the beginning of project. We should stick with k8s core naming convention.

Good.

@gertipoppel Me (or somebody from the team) can research standard markdown processors that are out there. I expect that there are lots of them.

Me (or somebody from the team) can research standard markdown processors that are out there. I expect that there are lots of them.

This would be great! Thank you!

@bryk I would like to rename replica set into replication controller. Should this be "rc" then, or "replicationcontroller" / ReplicationController? I vote for rc / RC.

Hmm... This is getting more complicated. Take a look at the issue: kubernetes/kubernetes#3024

Current status is that there are both, Replication Controller and Replica Sets. Ideally, I think that we should display both on our list page, because their difference is very slight.

However I do feel that we need to do the renaming. As for the name, I'd go for full names everywhere, i.e., replicationcontrolller, not rc. All code in the project uses long names. The reason is that we optimize for code reading, not writing :) rc maybe obvious at the time when you write code, but when a new team member comes to the project, it is not.

If I understand the discussion in kubernetes/kubernetes#3024 correctly, Replication Controller was renamed to ReplicaSet.

bgrant0607 changed the title from Rename ReplicationController to ReplicaSet to Create ReplicaSet on 12 Nov 2015

So, maybe we should postpone the renaming ;-)

Current status is that there are both, Replication Controller and Replica Sets. Ideally, I think that we should display both on our list page, because their difference is very slight.

I am not sure whether I understand the difference between a Replication Controller and ReplicaSet.

I agree to using long names throughout the project, just thought of the rc usage of kubectl.

By reading the bug I believe that this is no longer renaming. This is having two objects for some time and then deprecating one. This means that Replica Sets and Replication Controllers will be there for some amount of time and our UI shows Controllers, not Sets. Hence, I think we should rename. What do you?

OK. I understand. Then I will rename replica sets to replication controllers.

@gertipoppel Is this done?

@bryk This is almost done. What is still missing:

• Dashboard Tour: I am currently working on the extension of the Dashboard documentation in the K8S project. (https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/ui.md).
• A link to the Dashboard tour should be added to the Deploy pages.
• Deploying your App: Create documentation on the concepts of deploying applications to K8S pods; parts can be taken over from Managing Applications: Deploying continuously running applications of the K8S documentation.
  Imho, this is no longer required once the Deploy pages contain a link to the Dashboard tour. The Dashboard tour itself can then reference the K8S concepts.
• The Zero state page should only contain a link to the Dashboard tour. This is not yet implemented. The three other links (which are no links, currently) should be removed.

@gertipoppel

I agree with everything you said :) Are you working on this?

@bryk @cheld
I am working on the dashboard tour and will take care that the other issues will also be resolved.

Awesome, thank you @gertipoppel :)

I have update/extended the dashboard tour and just created a PR (kubernetes/kubernetes#22276)
What is still missing:

• A link to the Dashboard tour should be added to the Deploy pages (http://kubernetes.io/v1.1/docs/user-guide/ui.html).
• The Zero state page should only contain a link to the Dashboard tour. This is not yet implemented. The three other links (which are no links, currently) should be removed.

@gertipoppel I think both mentioned issues are fixed now. Could you confirm?

@maciaszczykm Yes, this issue can be closed. Thank's a lot.