Letting each condition control its frequency #150
Merged
Conversation
This file contains 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
Using throttling, each condition was being checked once per minute. But a condition may need to perform its check at a different pace like for example the TaskMonitor condition. This change applies throttling at individual condition instead of applying it generically at the subprocess level. The TaskMonitor condition will not be executed once per 10 seconds instead of one minute. This will allow for faster evaluation of worker idleness which would help in scaling down the worker fleet a lot more effectively.
ashishgo-aws
added a commit
to ashishgo-aws/amazon-mwaa-docker-images
that referenced
this pull request
Oct 1, 2024
The task monitor needs to process the following 4 MWAA signals for the graceful update project: 1. Termination signal: Graceful termination of the workers when the environment is going through a graceful update 2. Resume signal: Reverting the state of graceful termination and resume work when the environment is going through a rollback after attempting a graceful update 3. Kill signal: Shutting down the worker without waiting for the current Airflow tasks to finish when the environment is going through a forced update 4. Activation signal: Starting consumption of work from the queue after termination protection has enabled on the corresponding Fargate task The processing is gated behind certain environment variables which are either absent or marked as false for an environment which does not have graceful updates enabled. The CR brings the changes that have been merged for 2.9.2 (aws#137 and aws#150) to the newer version.
Pause task consumption in the close method helps reduce the probability of worker picking up work during the shutdown procedure. Plus, AIRFLOW__CELERY__WORKER_AUTOSCALE value to "80,80" was done when 2xlarge environment class was introduced. This change got left out when porting improved autoscaling changes to 2.9
dhegberg
reviewed
Oct 2, 2024
kuyperse
requested changes
Oct 3, 2024
I believe I have covered these in #151. Is there anything you saw that is missing in that PR? |
kuyperse
approved these changes
Oct 3, 2024
I didn't check the other PRs to see if the changes were ported there. Nothing seems to be missing. LGTM. |
dhegberg
approved these changes
Oct 3, 2024
ashishgo-aws
added a commit
that referenced
this pull request
Oct 3, 2024
) The task monitor needs to process the following 4 MWAA signals for the graceful update project: 1. Termination signal: Graceful termination of the workers when the environment is going through a graceful update 2. Resume signal: Reverting the state of graceful termination and resume work when the environment is going through a rollback after attempting a graceful update 3. Kill signal: Shutting down the worker without waiting for the current Airflow tasks to finish when the environment is going through a forced update 4. Activation signal: Starting consumption of work from the queue after termination protection has enabled on the corresponding Fargate task The processing is gated behind certain environment variables which are either absent or marked as false for an environment which does not have graceful updates enabled. The CR brings the changes that have been merged for 2.9.2 (#137 and #150) to the newer version. By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Using throttling, each condition was being checked once per minute. But a condition may need to perform its check at a different pace like for example the TaskMonitor condition. This change applies throttling at individual condition instead of applying it generically at the subprocess level. The TaskMonitor condition will not be executed once per 10 seconds instead of one minute. This will allow for faster evaluation of worker idleness which would help in scaling down the worker fleet a lot more effectively.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.