Skip to content
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

Simplify CeleryKubernetesExecutor tests #13307

Merged
merged 3 commits into from
Dec 31, 2020

Conversation

dstandish
Copy link
Contributor

@dstandish dstandish commented Dec 24, 2020

Existing tests for CeleryKubernetesExecutor had some code duplication that made it somewhat more difficult to understand what was being tested.

Here I use parameterization to reduce code, simplify, and make intention more clear.

In the tests test_has_tasks and test_adopt_tasks I take the opportunity to add a little more coverage.

@boring-cyborg boring-cyborg bot added the area:Scheduler including HA (high availability) scheduler label Dec 24, 2020
@XD-DENG
Copy link
Member

XD-DENG commented Dec 27, 2020

Hi @dstandish mind checking the failures in K8S tests (https://github.com/apache/airflow/runs/1607640815) before we can further review?

It should be related to the change introduced in #13289, and @potiuk has fixed it in #13316 . So simply rebasing to the latest master should help.

@potiuk
Copy link
Member

potiuk commented Dec 27, 2020

Also related @XD-DENG: can you please kindly take a look at #13323. this should enormously help in analysing logs of failed kubernetes jobs in CI. I added groups/sections to logs and they should load many times faster and by default hide irrelevant details (but they are easy to unfold :)).

@XD-DENG
Copy link
Member

XD-DENG commented Dec 27, 2020

Also related @XD-DENG: can you please kindly take a look at #13323. this should enormously help in analysing logs of failed kubernetes jobs in CI. I added groups/sections to logs and they should load many times faster and by default hide irrelevant details (but they are easy to unfold :)).

Sure. Will be a bit slow checking it if you don't mind ;-) But should be getting back to you within today.

@dstandish
Copy link
Contributor Author

thanks @XD-DENG, done

@dstandish
Copy link
Contributor Author

there are also 3 related PRs... related because they all came up as i was checking out CeleryKubernetesExecutor

ignore_ti_state = False
pool = None
cfg_path = None
assert cke.has_task(None) == cke_has
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is different from the original assertion (assert cke.has_task(ti)). May you clarify a bit ?

Copy link
Contributor Author

@dstandish dstandish Dec 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i will update

simple_task_instance.queue = 'non-kubernetes-queue'
@parameterized.expand(
[
('other-queue',),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: let's use the original queue name "'non-kubernetes-queue"? to be consistent with other related test cases, also being more explicit about what's tested here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about 'any-queue' or 'any-other-queue' -- because the behavior were testing is the difference in handling between the kubernetes queue (there is only one) and any queue besides the kubernetes queue

or 'arbitrarily-named-queue' or 'could-be-anything':)

my only hesitation with 'non-kubernetes-queue' is that there's some possibility it could be interpreted to mean that there is a particular designated queue, namely 'non-kubernetes-queue' which routes to celery, and otherwise it goes to kubernetes queue

my making the naming more generic, or more obviously arbitrary, i think it adds to readability.

let me know what you think. happy to defer to your judgment on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i went with 'any-other-queue'


@parameterized.expand(
[
('non-kubernetes-queue',),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dstandish I agree with your proposal. Then I assume this line should be updated as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup. didn't see it. done.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool.

I was about to request for a rebase to the latest master, but I see you have already done that 👍

Overall in good shape now. It's a great PR which does make the tests much cleaner. I will do a final check and get back to you tomorrow. Cheers.

Copy link
Member

@XD-DENG XD-DENG left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGMT

@XD-DENG
Copy link
Member

XD-DENG commented Dec 31, 2020

Apparently the CI failure is due to un-related reason. Will merge this first.

@XD-DENG XD-DENG merged commit 10be375 into apache:master Dec 31, 2020
@XD-DENG XD-DENG added the type:misc/internal Changelog: Misc changes that should appear in change log label Dec 31, 2020
kaxil pushed a commit that referenced this pull request Jan 21, 2021
* Simplify CeleryKubernetesExecutor tests

Co-authored-by: Daniel Standish <[email protected]>
(cherry picked from commit 10be375)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:Scheduler including HA (high availability) scheduler type:misc/internal Changelog: Misc changes that should appear in change log
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants