-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Use JobManager's backend as persistent storage and source of truth #903
Use JobManager's backend as persistent storage and source of truth #903
Conversation
/hold |
a18e468
to
2cd87a1
Compare
/test test-end-to-end |
fixes after rebase fix python tests
1a6c17e
to
3532dcf
Compare
/unhold |
/test test-end-to-end-batch |
/test test-end-to-end-redis-cluster |
/test test-end-to-end-auth |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pyalex, 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 |
What this PR does / why we need it:
As part of the plan to decouple JobCoordinator & Core and eventually move Job Management to dedicated service this PR is the first step in this direction.
JobCoordinator doesn't rely on any persistent storage anymore. We store temporary state in memory (see
InMemoryJobRepository
) and fetch this state each time application is being started (seeJobManager.listJobs
).For
DataflowJobManager
it means that we fetch list of jobs directly from Dataflow. We distinguish jobs that are being managed by current application by job's labels (see propertyfeast.jobs.coordinator.jobSelector
). Same set of labels is being applied to job on creation.For
DirectJobManager
we just start with empty job list.Refactoring:
Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?: