Can I associate a context with a tab?

[pwright]

Trying to figure out the best way to create a notebook that switches kube context as they proceed thru steps.

With skupper.io we have automatically rendered README.md files to illustrate various examples, eg https://github.com/skupperproject/skupper-example-hello-world

I think it might be possible to redirect the markdown to kui to give a great experience for new skupper users, but I'm new to kui and don't know the best way to approach it.

With skupper, you switch between clusters/namespaces for each procedure 'step', and I thought I could use 'tabs' for this experience, for example:

but I'm not sure if it's possible to tie each tab to a kube context, or if there is another approach I should try?

thanks in advance for a super tool, any 'getting started' links appreciated.

currently using steps like:

=== "west"

    ~~~ shell
    kubectl create deployment frontend --image quay.io/skupper/hello-world-frontend
    ~~~

=== "east"

    ~~~ shell
    kubectl create deployment backend --image quay.io/skupper/hello-world-backend --replicas 3
    ~~~

[starpit]

hello there. thanks for sharing some great thoughts!

each top-level tab in kui should lock itself to a kubernetes context, but currently this only happens after a command execution, in that tab, to change context. it should be possible to add support for expressing the desire that this should happen onload, perhaps via a topmatter element.

markdown tabs currently do not have this capability. there also isn't a great way to add any kind of topmatter to a tab (we are using the pymdown/mkdocs syntax, which is pretty limiting in this respect)

one other thing we could do is add a bit of metadata support to kui's markdown code block implementation. right now, you can express things like

```shell
---
execute: now
---
```

i.e. kui does support adding a "topmatter" element to each code block (in this case, the execute: now tells kui that you want it to execute the code block on the initial render, rather than when the user clicks to execute.

we could add context: xxx support, perhaps? or maybe more generally, a suffix: --context west, where kui will automatically add the given suffix to the command line execution?

🤔

[pwright]

Thanks @starpit
So, if i was to approach this (without major customization), I would set up two top level tabs:

East
0. Set kube context

1. Perform step
2. Switch to West tab to perform step X
3. Perform step

West
0. Set kube context

1. Perform step
2. Switch back to East tab to perform step Y
3. Perform step

I'm not sure how auto-executing steps would help me, so, for now I think my best option is to generate markdown with the context embedded, eg skupper init --namespace west

thanks @starpit Any pointers for new kui users who want to create markdown notebooks, I'm currently using https://github.com/kui-shell/KuiClientTemplate but I dunno if that's the best option... Ideally I want the flow for skupper users to be:

• Install kui
• Run the skupper notebook

but is that what folks do? (I'm not finding any doc for that flow)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.