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 the Go dependencies, unless the build environment doesn't have network access
or any such peculiarities. 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 ## Distro support
By default, Toolbox creates the container using an By default, Toolbox creates the container using an