Currently Drydock resources are consumed solely by Harbormaster. Harbormaster provides a human friendly way to interact with working copies from a web interface, but humans aren't necessarily the only reasonable consumers of those resources. Similarly, a web interface doesn't need to be the only way that people can access hosts or working copies managed by Drydock.
A simple, contrived, and nifty use case for interacting with drydock resources directly might look like this:
- Users want to contribute small changes to a project
- Setting up all of the system prerequisites to get this project's unit tests working correctly is highly complex
- Instead of running unit tests locally during arc diff, we could do the following
- Push the users diff to a staging ref
- Lease a working copy over the API for that particular ref
- Issue arc unit over ssh to that working copy, displaying the output back to the user locally as the tests evaluate remotely
This exact use case is merely illustrative of the sorts of things this task is supposed to enable and shouldn't be considered part of the work here.