Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Decouple API handlers from build execution #14



Copy link

pivotal-jwinters commented Nov 15, 2018


Signed-off-by: Jamie Klassen

Signed-off-by: Jamie Klassen <>
@pivotal-jwinters pivotal-jwinters changed the title Decouple API handlers from build execution RFC: Decouple API handlers from build execution Nov 15, 2018
Copy link

topherbullock left a comment

Feels like we also want a "runtime interface" similar to some of the concerns outlined in #2

1. `POST /api/v1/teams/:team/user-artifacts` to upload a folder to a volume
1. `GET /api/v1/teams/:team/user-artifacts/:uuid` to download the contents of a

This comment has been minimized.

Copy link

topherbullock Nov 20, 2018


These endpoints could also be under /api/v1/teams/:team/volumes where a POST can create a specific type of volume for the artifacts, and return the created handle. There could be other methods on individual volumes toGET the contents of the volume, and query parameters to find specific user artifacts.

What do you think?

We'll also want a separate interface which decouples this volume management behaviour from the internals of the worker and even the specifics of volumes and the pool of workers overall (per our meatspace conversation about the API handlers doing this directly). The K8s RFC kind of covers some of the details for that, and could maybe be changed to a generic "runtime interface" RFC.

This comment has been minimized.

Copy link

pivotal-jwinters Nov 21, 2018

Author Contributor

The plan is to treat artifacts, similar to resource_caches and task_caches. So we're going to have another foreign key reference in the volumes table. Since the volume is the lower level object, we were thinking it made more sense to have an artifacts endpoint that implicitly creates a volume record (instead of the other way around). No real strong opinions here though. Maybe we could have a volumes endpoint that creates different types of volumes (resource_caches, task_caches, user_artifacts, etc..).

@pivotal-jwinters pivotal-jwinters mentioned this pull request Feb 7, 2019
9 of 9 tasks complete

This comment has been minimized.

Copy link

vito commented Mar 12, 2019

This RFC predates the RFC process and was more of a brain dump for internal refactoring, so I'm gonna close it (after confirming with @pivotal-jwinters).

@vito vito closed this Mar 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.