Idea #22580
Updated by Peter Amstutz about 2 months ago
The purpose of @arvbox@ is
# to provide a self container developer environment capable of running the entire test suite
# to enable launching a self-contained, auto-configured cluster that is can support integration tests (such as running CWL workflows) and manual testing of components that the end user might interact with such as Workbench and keep-web.
Arvbox has significant overlap with other functionality -- all of which was written after @arvbox@ was created, but the approaches taken by @arvbox@ were not intended to be general purpose, where as these new methods (mostly based around Ansible) are general purpose, and thus could support a new arvbox.
So I'm thinking about how a new iteration of arvbox should work.
Current functional overlap:
* arvbox Dockerfile uses @arvados-server install@ plus installs some additional packages, but @arvados-server install@ is redundant with the new ansible playbook and will be removed (#22436)
* arvbox can launch run-tests, but the "test" environment (set up by run-tests) has entirely separate code from the arvbox scripts that create a "development" environment. having separate binaries depending on how you're running things is a bit confusing.
* arvbox has its own code to configure and launch services, which overlaps with code in @run-tests@, @sdk/python/tests/run_test_server.py@, @arvados-server boot@ and the production @systemd@ units