Epic Goal

Make sure that the toolbox experience is good for users/admins of RHCOS nodes.

Why is this important?

Toolbox is mostly used for debugging issues thus this is important for the customer experience when then have issues and what to figure out a solution or report a bug.

With RHCOS 9, we're trying to move away from maintaining a script on top of podman for toolbox. We have the following options:

1. Provide containers/toolbox (toolbx) instead of coreos/toolbox. The behavior of the new toolbox is slightly different.
2. Completely stop providing a script and write doc examples to directly call podman instead with a defined container image and arguments

In both cases, docs will need an update.

The currently chosen option in the RHCOS 9 / SCOS is to ship the new containers/toolbox.

Scenarios

1. TODO

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>