-
Notifications
You must be signed in to change notification settings - Fork 23
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
Automate ensembler image building with Turing API #170
Automate ensembler image building with Turing API #170
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the detailed summary, @deadlycoconuts ! I took a quick look and left some comments / questions. You may also want to get another set of eyes on this MR.
Could you also help clean up the README? There is a section showing the config-dev.yaml
contents. But I think it can be removed, with a link to the config file, which you have already updated with the required configs for this feature.
Lastly, I imagine there will some user docs being updated, for the Pyfunc ensembler creation and router deployment (similar to batch ensemblers, both for the public docs and our internal docs; although batch docs are currently only internal - we can sort that out later). Will this be a part of the UI card? If not, please capture this in the backlog.
Thank you!
} | ||
|
||
// Verify if the ensembler given by its ProjectID and EnsemblerID exist | ||
ensembler, err := ensemblersSvc.FindByID( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question - can the ensembler be deleted while it is being referenced by a router? Can it be deleted at all (I can't seem to find the delete method in the codebase, for the real or the batch ensemblers). May be @ashwinath has some context too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope there doesn't seem to be an API endpoint for deleting ensemblers. Not sure if this was a conscious design choice though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok.. I'm not sure either. Could you create a card for this (delete for batch / real-time ensemblers) in the backlog, just to track it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't remember why there isn't a delete ensembler API for this or maybe I wasn't kept in the loop. Ensemblers I believe was done by Roman where as I did the orchestration. There is a delete for the orchestration part.
2dd0eb8
to
8a383c1
Compare
api/api/openapi.bundle.yaml
Outdated
@@ -551,7 +551,7 @@ paths: | |||
content: | |||
application/json: | |||
schema: | |||
$ref: '#/components/schemas/inline_response_200' | |||
$ref: '#/components/schemas/IdObject' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cleaned up all these stuff in the latest update
@@ -199,7 +199,7 @@ func (sb *clusterSvcBuilder) buildRouterEnvs( | |||
{Name: envEnricherTimeout, Value: ver.Enricher.Timeout}, | |||
}...) | |||
} | |||
if ver.Ensembler != nil && ver.Ensembler.Type == models.EnsemblerDockerType { | |||
if ver.HasDockerConfig() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simplified this to make the intention of the check explicit
experimentConfig json.RawMessage, | ||
eventsCh *EventChannel, | ||
) (string, error) { | ||
var endpoint string | ||
|
||
// If pyfunc ensembler is specified as an ensembler service, build/retrieve its image | ||
if pyfuncEnsembler != nil { | ||
err := ds.buildEnsemblerServiceImage(pyfuncEnsembler, project, routerVersion, eventsCh) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DeploymentService
now does the weightlighting for image building.
@@ -551,7 +551,7 @@ paths: | |||
content: | |||
application/json: | |||
schema: | |||
$ref: '#/components/schemas/inline_response_200' | |||
$ref: '#/components/schemas/IdObject_1' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is automatically generated by the Makefile right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep that's right. I corrected the source openapi specs that was generated with make bundle-openapi
Thanks a lot for all the comments everyone! I'll rebase this on @leonlnj 's latest changes and it'll be good to go! |
0e06c66
to
f2767fc
Compare
Context
In PR #164 and most notably PR #165, a real-time ensembler engine was introduced to process live ensembling requests, using an ensembler that is predefined in the
mlflow
pyfunc flavour. This engine can then be run in a container to serve real-time ensembling requests. However, the creation of such a container is a manual process which required the user to build aDocker
image, followed by spinning up his/hero own container from the template files provided.Hence, this PR introduces a process to automatically allow Turing API to orchestrate the
Docker
image building process when a user specifies a pre-defined pyfunc ensembler (identified by its givenproject_id
andensembler_id
) when creating a Turing Router. Turing API then pushes the newly created image to a specified registry, and saves the image name as part of the configuration of the said Turing Router, which will then use this image to run a container containing the real-time ensembler web service with the specified pyfunc ensembler.Features
Docker
image of the real-time ensembler web service with the ensembling logic given by the specified pyfunc ensemblerpyfunc_config
/PyfuncConfig
that contains resource request and timeout information regarding a pyfunc ensembler to be automatically deployed as a containerised web serviceFixes
8080
to8083
, since Turing API already listens on8080
Main Modifications
api/turing/api/deployment_controller.go
- Addition of steps to orchestrate the building of the web service image when deploying a new router (version)api/turing/api/appcontext.go
- Addition of anEnsemblerServiceBuilder
to theappContext
api/turing/api/request/request.go
- Addition of checks to verify HTTP requests to Turing API that specify pyfunc ensemblers contain a validproject_id
andensembler_id
(one that points to a pyfunc ensembler that has already been stored in Turing API)api/turing/models/ensembler.go
- Addition of a new field forpyfunc_config
/PyfuncConfig
api/turing/imagebuilder/ensembler.go
- Addition of new utility functions to create ensembler builder and service namesapi/config-dev.yaml
- Addition of new configuration for the web service buildingapi/db-migrations/*
- Addition of SQL scripts for up/down migrations due to addition ofpyfunc_config
/PyfuncConfig
api/api/*
- Changes to the OpenAPI specs from the addition ofpyfunc_config
/PyfuncConfig
infra/charts/turing/values.yaml
- Addition of new default configuration for web service building to helm charts