feat: make workload_id in host the kubernetes UID #219
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Mees-Molenaar
force-pushed
the
feat/make_workload_id_set_by_scheduler
branch
2 times, most recently
from
2cb07bf to
8e726c5
Compare
This prevents issues where the workload is not fully started, but a stop workload is called. Then the stop workload is called without an ID, and once the workload is fully started it wont be stopped. Therefore, it will run forever, which causes problems when you want to call a workload with a certain host. It might resolve to an old workload, which it shouldnt. Now it will always get removed successfully Also has some cleanups in log statements Signed-off-by: Mees Molenaar <[email protected]>
Mees-Molenaar
force-pushed
the
feat/make_workload_id_set_by_scheduler
branch
from
8e726c5 to
00b61da
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Feature or Problem
When redeploying a Workload, before the previous Workload is resolved, this Workload will not be removed from the host. So the Workload will exist forever.
When the Kubernetes operator sends a
WorkloadStartrequest to a Host, it will only get a Workload ID assigned when theworkload_startcommand is completely finished. Therefore, when you stop a Workload by redeploying, it will send aWorkloadStoprequest without an ID, because it does not have a Workload ID assigned yet.In this PR, I decided that we keep the Scheduler's (In this case the runtime-operator) UID. This way, the scheduler always knows which Workload is started and it always can be stopped by calling
WorkloadStoprequest with that ID.Another way of solving this, would be to wait in the Workloads finalizer for a Workload ID, or if the Workload deployment Errored for some reason. However, I preferred the implemented solution over this.
Release Information
nextConsumer Impact
When restarting the host without the correct runtime-operator, it will set empty workload_ids in for example the workload_to_host maps for http routing. Thus, the host should and runtime-operators should match.
Testing
Unit Test(s)
Acceptance or Integration
Manual Verification