---
# System prepended metadata

title: 'Design patterns to discuss:'

---

# Design patterns to discuss:

Previous private google docs that should probably also be converted and made public:

Kickoff meeting notes: [link](https://docs.google.com/document/d/1EpUkIWWBuX0Z-WZfzwsP9BFSne0bl69P6P5W7MJhzgU/edit#heading=h.b30vn2mwxopg) (private gdoc)
Use Cases meeting notes: [link](https://hackmd.io/QZzHNLFUSzSeiubxzCVmow) 


# Design Topics

## Future:
- automatic re-entry on new tab
    - option 1: use a profile
    - option 2: VTE patch
    - option 3: toolbox --create-gnome-terminal-profile

- how should people use toolbox
    - treat it like a pet that will be updated indefinitely
    - periodically save via `podman commit`
    - rebuild it often based on a custom user defined definition
        - something like `toolbox up` on a definition


## Some Things we like about original debarshiray/toolbox (current containers/toolbox)
- code:
    - reuses some flatpak code (taking part of a bigger community)
- UI:
    - try to keep old toolbox containers working when we release new toolbox versions
    - nice help screen for interactive commands
        - helps the user along with commands
    - don't like
        - some historical mistakes with the CLI
            - onerous UI if you create a differently name toolbox
    - CLI bash completions

## Some things we like about original cgwalters/coretoolbox code ([to be merged too](https://github.com/containers/toolbox/pull/303))

- UI:
    - Some points gleaned from [coretoolbox README](https://github.com/cgwalters/coretoolbox/blob/master/README.md#rationale)
        - support for making derived custom toolbox containers that can be rebuilt. i.e. `podman build` periodically vs `toolbox enter && dnf update -y`
        - inject more dynamic state at runtime
            - username
            - `HOME` path
        - bind mount everything from host into `/host` and symlink popular directories into their counterparts in `/host`
        - The above allows for the set of things exposed to be easily changed and tailored to an individuals custom use cases
    - In the entrypoint we call mount inside the container
        - users are creating their own toolbox like things, we could dynamically do useradd in the entrypoint (runtime, not buildtime)
- code:
    - 

## Parts from https://github.com/coreos/toolbox (maybe should be merged too)

- UI: rhel7/support-tools (matches `oc debug node/`)
- code: kubelet auth

## Other things from previous meeting: 

- Split runtime and dynamic state
    - https://github.com/cgwalters/coretoolbox/commit/f618ce69bca762f9f4bd2835d11d7aa87e3915f2


Notes:

My (Ondra) branch with initial go rewrite bits of code: https://github.com/HarryMichal/toolbox/tree/rewrite-in-go