wbrawner/toolbox
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

GOALS.md, README.md: Move the Goals and Use Cases to a separate file

Browse source 
... to prevent the README.md file from becoming too long.

https://github.com/containers/toolbox/pull/684
This commit is contained in:
Debarshi Ray 2021-01-25 20:35:46 +01:00
parent ba1097a6db
commit 20a8a0551a
2 changed files with 60 additions and 59 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

60
GOALS.md Normal file
View file

@ -0,0 +1,60 @@
<img src="data/logo/toolbox-logo-landscape.svg" alt="Toolbox logo landscape" width="800"/>
## Goals and Use Cases
### High Level Goals
- Provide a CLI convenience interface to run containers (via `podman`) easily
- Support for Developer and Debugging/Management use cases
- Support for multiple distros
- toolbox package in multiple distros
- toolbox containers for multiple distros
### Non-Goals - Anti Use Cases
- Supporting multiple container runtimes. `toolbox` will use `podman` exclusively
- Adding significant features on top of `podman`
- Significant feature requests should be driven into `podman` upstream
- To run containers that aren't tightly integrated with the host
- i.e. extremely sandboxed containers become specific to the user quickly
### Developer Use Cases
- I’m a developer hacking on source code and building/testing code
- Most cases: user doesn't need root, rootless containers work fine
- Some cases: user needs root for testing
- Desktop Development:
- developers need things like dbus, display, etc, to be forwarded into the toolbox
- Headless Development:
- toolbox works properly in headless environments (no display, etc)
- Need development tools like gdb, strace, etc to work
### Debugging/System management Use Cases
- Inspecting Host Processes/Kernel
- Typically need root access
- Need bpftrace, strace on host processes to work
- Ideally even do things like helping get kernel-debuginfo data for the host kernel
- Managing system services
- systemctl restart foo.service
- journalctl
- Managing updates to the host
- rpm-ostree
- dnf/yum (classic systems)
### Specific environments
- Fedora Silverblue
- Silverblue comes with a subset of packages and discourages host software changes
- Users need a toolbox container as a working environment
- Future: use toolbox container by default when a user opens a shell
- Fedora CoreOS
- Similar to silverblue, but non-graphical and smaller package set
- RHEL CoreOS
- Similar to Fedora CoreOS. Based on RHEL content and the underlying OS for OpenShift
- Need to [use default authfile on pull](https://github.com/coreos/toolbox/pull/58/commits/413f83f7240d3c31121b557bfd55e489fad24489)
- Need to ensure compatibility with the rhel7/support-tools container
- currently not a toolbox image, opportunity for collaboration
- Alignment with `oc debug node/` (OpenShift)
- `oc debug node` opens a shell on a kubernetes node
- Value in having a consistent environment for both `toolbox` in debugging mode and `oc debug node`

59
README.md
View file

@ -88,65 +88,6 @@ automatically downloaded as part of the build. There's no need to worry about
the Go dependencies, unless the build environment doesn't have network access
or any such peculiarities.
## Goals and Use Cases
### High Level Goals
- Provide a CLI convenience interface to run containers (via `podman`) easily
- Support for Developer and Debugging/Management use cases
- Support for multiple distros
- toolbox package in multiple distros
- toolbox containers for multiple distros
### Non-Goals - Anti Use Cases
- Supporting multiple container runtimes. `toolbox` will use `podman` exclusively
- Adding significant features on top of `podman`
- Significant feature requests should be driven into `podman` upstream
- To run containers that aren't tightly integrated with the host
- i.e. extremely sandboxed containers become specific to the user quickly
### Developer Use Cases
- I’m a developer hacking on source code and building/testing code
- Most cases: user doesn't need root, rootless containers work fine
- Some cases: user needs root for testing
- Desktop Development:
- developers need things like dbus, display, etc, to be forwarded into the toolbox
- Headless Development:
- toolbox works properly in headless environments (no display, etc)
- Need development tools like gdb, strace, etc to work
### Debugging/System management Use Cases
- Inspecting Host Processes/Kernel
- Typically need root access
- Need bpftrace, strace on host processes to work
- Ideally even do things like helping get kernel-debuginfo data for the host kernel
- Managing system services
- systemctl restart foo.service
- journalctl
- Managing updates to the host
- rpm-ostree
- dnf/yum (classic systems)
### Specific environments
- Fedora Silverblue
- Silverblue comes with a subset of packages and discourages host software changes
- Users need a toolbox container as a working environment
- Future: use toolbox container by default when a user opens a shell
- Fedora CoreOS
- Similar to silverblue, but non-graphical and smaller package set
- RHEL CoreOS
- Similar to Fedora CoreOS. Based on RHEL content and the underlying OS for OpenShift
- Need to [use default authfile on pull](https://github.com/coreos/toolbox/pull/58/commits/413f83f7240d3c31121b557bfd55e489fad24489)
- Need to ensure compatibility with the rhel7/support-tools container
- currently not a toolbox image, opportunity for collaboration
- Alignment with `oc debug node/` (OpenShift)
- `oc debug node` opens a shell on a kubernetes node
- Value in having a consistent environment for both `toolbox` in debugging mode and `oc debug node`
## Distro support
By default, Toolbox creates the container using an