-
Notifications
You must be signed in to change notification settings - Fork 16.4k
Create an explicit control for createUserJob #56057
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
Conversation
|
@hussein-awala can you take a look here ? |
|
@jedcunningham can you take a look here? |
Miretpl
left a comment
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.
Could you add a test case for it?
|
@Miretpl I will add a test for it today |
373df71 to
1a70432
Compare
1a70432 to
40057fc
Compare
|
@prakharcode to me the change looks good now. @jedcunningham @hussein-awala @jscheffl could you take a look in a free moment? |
|
@Miretpl @jedcunningham @jscheffl can we move the PR forward? |
|
@prakharcode I can't do much more really, cause I'm not able to merge the change to the repository. Just be patient till one of the PMC members takes a look. |
* [fix]: Creating an explicit control for createUserJob * added tests
closes: #51304
As describe in the issue, the createUserJob fails on the new standalone installation on helm.
This is because the createUserJob only checks in the setting for
defaultUser.enabledin webserver. This value check while being perfectly fine for older versions of airflow, created a bit of confusion for newer versions where you just putwebserver.enable: falseand expect nothing to be coupled with other deployments.Particularly, deployment trying to use simple_auth get an "unwanted" createUserJob which always fails.
To make the creation of
createUserJobexplicit, I have included another value which explicitly setsenabled: true | false.This should make things clear and init control (a bit) independent.
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.