merge of fedora-toolbox and coreos-toolbox efforts

[dustymabe]

From @debarshiray:

Goal:

Evaluate the current state of fedora-toolbox on Fedora CoreOS; identify
problems and use-cases; and start filing issues and writing patches.

Background:

So far, fedora-toolbox has been written, tested and used solely on Fedora
Silverblue systems. In short (here is a longer write-up), on Silverblue,
fedora-toolbox is meant to offer a mutable RPM-based development environment
that's seamlessly integrated with the host OS. That means running rootless,
shared $HOME, access to hardware like GPUs, etc.. It's not about security,
but giving the developer a safe sandbox to tinker in without breaking the host
OS or being conscious of the underlying container technology.

From @dustymabe:

The above writeup is from @debarshiray. There seems to be some general agreement that we'd like to merge the efforts of https://github.com/debarshiray/fedora-toolbox and https://github.com/coreos/toolbox. Let's discuss at our next meeting how we can get there.

Previous discussions:

• Ticket for getting "toolbox" like functionality into FCOS
• alignment/comparison with coreos/toolbox

[dustymabe]

In the weekly meeting today we discussed merging the coreos-toolbox and fedora-toolbox efforts into just toolbox. A summary of the discussion is below:

• the goal is to get users a command they can run without a lot of CLI options
  • the holy grail is just running toolbox or sudo toolbox and allowing the user to get to the environment he/she wants
• currently the two implementations have different flags/mountpoints, base images, build process and sudo/non-sudo needs
• we would like to break the problem space into two "modes", switchable with --mode flag or by setting defaults in config files.
  • developing mode - silverblue/Fedora workstation
    • I'm a dev hacking on git repos and building/testing code
    • usually run as non-root. error if root, allow overriding
  • debugging mode - Fedora Server/Fedora Cloud/FCOS
    • I'm a sysadmin trying to debug a problem on my server
    • usually run with root permissions. error if non-root. allow overriding
• we'd like to consolidate things like cli flags and make other parts configurable based on mode
  • [config.defaults]: mode, mountpoints, base images
  • [config.developing]: override defaults for mountpoints, base images, CLI args to podman
  • [config.debugging]: override defaults for mountpoints, base images, CLI args to podman
• we'd like configuration to be similar to systemd with read-only default files and directory dropin style overrides
  • this would allow users and distribution creators to customize things in a sane familiar

[bgilbert]

For the record, what are the practical differences between the two modes?

[cgwalters]

Hm, I think of the "debugging, privileged" case as "general sysadmin work". For example, running tcpdump. Or running more sophisticated htop like programs, killing processes. And maybe one wants to use emacs inside the container to edit systemd unit files on the host. etc.

[jlebon]

@dustymabe I think we can close this, right? FCOS now ships toolbox.

Re. specifically about the running as root case, if it's indeed the case that it doesn't work yet (as per containers/toolbox#267), we should open a new ticket and bump priority on that.