-
Notifications
You must be signed in to change notification settings - Fork 994
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
Clean up Docker Compose and add test #668
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: woop The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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.
Does this require any updates to the documentation?
Yes it does, but I will update that through |
I am in favor of a singular docker-compose file if possible in the future. Maybe we could ensure that all the dependencies is loaded before exposing its gRPC port? Then we can synchronize the order that Core/Dependencies and Serving has to started up in the future with wait-for-it automatically.
Perhaps we should make this this failure explicit by making Batch Serving to refuse to run if Feast core does not have the required service account. Seems like otherwise this could be a silent error that can catch new users by surprise. |
So am I. Right now I am just trying to make the startup process explicit. It's still a one-liner so I dont see it being too painful.
Makes sense. Quite like the
Yes, ideally that would be the case. The system shouldnt load if the configuration isn't set up correctly. However, this would require a moderate amount of code changes because job management only detects the problem when it spins up new jobs after feature set registration. The fact that Feast Core needs the service account is the bigger problem. Which is why we want to move job management to Serving so that failure can be immediate and localized. I am not in favour of adding more complexity between these two services until we have done that. |
What this PR does / why we need it:
Docker Compose
configuration. This won't test the latest commit's code (on PR or push). It will test based on what is configured on that commit. Currently master is set to use thelatest
docker image for the docker-compose setup, with the SDK usingv0.4.7
.Which issue(s) this PR fixes:
Fixes #652
Does this PR introduce a user-facing change?:
Problems with the current setup
A new release has to be made to backport the tutorials from master into 0.4. That would allow us to clean the tutorials up a bit to match the Docker Compose. The current tutorial has unnecessary steps like reinstalling the SDK.