Session Command

[petersutter]

What would you like to be added: It should be possible to manage sessions (attach, clone, list, cleanup)

Why is this needed:

[tedteng]

the history command gardenctl target xxxxx generated a history file, after the history PR merge. proposals extend history command feature load last one entry from the local history file. then create a new alias aaa='eval $(gardenctl xxxx-env zsh)'. This solution is more kind of target session stickiness

usage:

• if the user wants to session stickiness automatically in new terminal windows then 'eval $(gardenctl xxxx-env zsh)' set in ~/.zshrc, one drawback is normal operation with new terminal windows open will trigger the target feature as well.
• use alias aaa to attach the last target history in new terminal widows instead of automatically triggering in new terminal windows

in the end, The gardenctl v2 is already multi-session supported in different terminal windows simultaneously. Is the purpose of session management a kind of duplicate with fuzzy search target history?

[petersutter]

A gardenctl session is defined as following:

The state of gardenctl is bound to a shell session and is not shared across windows, tabs or panes. A shell session is defined by the environment variable GCTL_SESSION_ID. If this is not defined, the value of the TERM_SESSION_ID environment variable is used instead. If both are not defined, this leads to an error and gardenctl cannot be executed. The target.yaml and temporary kubeconfig.*.yaml files are store in the following directory ${TMPDIR}/garden/${GCTL_SESSION_ID}.

So "simply" speaking this would mean:

• Attach to session xyz (with side effects)
  • set GCTL_SESSION_ID to xyz to bind to an existing shell session
  • now you have more than one session with the same session ID. As these sessions point to to the same directory ${TMPDIR}/garden/${GCTL_SESSION_ID}, changes e.g. to the kubeconfig file, like changing the context will affect all sessions with this ID To be clarified:
    • should the current target be restored?
    • What about the provider-env or currently running ssh sessions?
• Clone session xyz (no side effects)
  • copy ${TMPDIR}/garden/${GCTL_SESSION_ID} to new session folder. Attach to newly created session To be clarified:
    • should the current target be restored?
    • should the user be able to choose from the target history of that particular session? What about the provider-env, ssh history? #162 currently only implements a global history
• List sessions
  • to be able to attach or clone to a session the existing sessions should be printed to the user, ideally with more context information about each session so that the user can easily identity the session
• Cleanup session(s):
  • there should be a command that basically removes the session folders
  • the idea was that a user could put the following command in his shell rc file gardenctl session clean --after=7d (just an example) to remove sessions that are older than duration x.

I haven't thought about it in detail and there are probably other things to consider