@jlewi we could get this in for 0.5, but we need a precise description of how the namespace selector works.

Will it be functional in 0.5? I guess the question is, who is responsible for listing K8s namespaces, and how can iframe-d apps access the contents of this selector?

Similarly tf-operator and Katib dashboard's default namespace should respect namespace in central dashboard. @richardsliu @avdaredevil

Also as a side note, in our discussion here #2521 people expressed the need to not show k8s concepts such as Namespaces to the end user.

One option that was proposed was to use the term Project instead of Namespace. Should we also take this into account for the dashboard?

One option that was proposed was to use the term Project instead of Namespace. Should we also take this into account for the dashboard?

One of the principles we try to follow in Kubeflow is not introducing new concepts, terms, patterns when they are already such things in K8s.

So w.r.t to namespace vs. project. If we introduce project, I think we should be creating something that is fundamentally different from a namespace. If a project is 1:1 mapping to namespace then I think we should just call it namespace.

Will it be functional in 0.5? I guess the question is, who is responsible for listing K8s namespaces, and how can iframe-d apps access the contents of this selector?

I think this is the question for @avdaredevil .

There are a couple of different options for making the iframed applications aware of a namespace selection from its parent.

1. The parent page injects JS into the iframe child that is invoked when the parent's namespace selector changes. This requires the parent to be aware of and manipulate the DOM state of its children. This is a bit brittle since the child app can change and any injected scripts would fail.
2. The iframe children accept namespace as part of their URL structure or as a query-string parameter. The selector is then made to synchronize with the URL in both directions. This allows the parent to set/change the iframe's src to reflect its namespace.

I don't know that either option is feasible within the next week or so. For the time being, the 0.5.0 version of the landing page only shows the namespace selector on the Activities tab that allows a user to see recent K8s events for the chosen namespace.

+1 to Jason's points. Basically we can:

• Establish a communication channel via JS using a event-driven model like: https://gist.github.com/pbojinov/8965299
• Or, a one time-url query param or location hash object. For example:
  • <base-url>/route?ns=<namespace> OR .../route#ns=<namespace>

With regards to the listing. Technically when running in iframe mode, the subapp does not need to be aware of all namespaces available.

• Links from Central Dashboard should include the selected namespace
• Selected namespace should be passed down to iframed content after it's loaded

/assign @avdaredevil
/assign @prodonjs

@avdaredevil This issue should track the work that needs to follow #2926 to integrate the library with the Jupyter application. I'm going to create a separate issue for TFJobs dashboard.

@avdaredevil https://github.com/prodonjs/kubeflow/tree/iframe-lib-import-test is the test branch I created in my fork that has the proof-of-concept integration of the namespace selection passdown into the Notebooks server UI. That would probably be a good starting point to base your PR off of.