-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Display only the running configuration in configurations view #28892
Conversation
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.
Looks good
default configuration is not displayed anymore.
I think we should still display defaults because if user is not aware of them he needs to look them up.
Maybe a toggle could solve this as it will allow both states in the same view?
Why? I encounter confusion about this page very regularly, people expect this page to show the running configuration. They do not expect the default configuration and are also not interested in knowing the default value when viewing this page, so I don't see the point in showing that. |
I agree that now its confusing. |
Wasnt sure about that. |
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.
Looks cool. very useful to not show defaults and super helpful to see the source of the values.
I think it would be useful but more difficult to show the same values for other components (especially if they differ from the one that webserve sees). This is also an often source of confusion for users especially those who set up a self-managed versions where the values might differ. But this is much more difficult to avhieve via GUI, so this is another story (and discussed/implemented elsewhere).
Agreed! Also saw failures happening at projects where the configuration wasn't applied consistently to all components, which was difficult to debug because the webserver showed the correct value. It would be cool to build some sort of "configuration-drift-detection", but I'll leave that for another time ;-) |
This PR displays only the running configuration in the configurations view. The (very confusing) default configuration is not displayed anymore. I regularly encounter confusion among Airflow users on this page about what is actually the running value of a config option, because it's not obvious you first have to scroll past the default configuration.
This follows up on #14641, which went stale.
There's an undocumented
/configuration?raw=true
endpoint to download the config. Users should use the/config
endpoint in the REST API instead. I can't imagine anybody using thisraw=true
endpoint, but added aDeprecation
header to the response to indicate the upcoming removal. If there's a better way to indicate deprecation, please let me know.After:
AIRFLOW__WEBSERVER__EXPOSE_CONFIG=True
:AIRFLOW__WEBSERVER__EXPOSE_CONFIG=False
:Before:
AIRFLOW__WEBSERVER__EXPOSE_CONFIG=True
:AIRFLOW__WEBSERVER__EXPOSE_CONFIG=False
:^ 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.rst
or{issue_number}.significant.rst
, in newsfragments.