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

[WIP] Deprecate dagrun conf and add params argument for the different APIs #29174

Closed
wants to merge 16 commits into from

Conversation

hussein-awala
Copy link
Member

@hussein-awala hussein-awala commented Jan 26, 2023

closes: #29018

Deprecate dagrun conf argument and add params argument for the different Airflow APIs (UI, CLI, Python API, internal API and REST API), and add a check for the extra/missing params.

@boring-cyborg boring-cyborg bot added area:API Airflow's REST/HTTP API area:CLI area:Scheduler including HA (high availability) scheduler area:UI Related to UI/UX. For Frontend Developers. area:webserver Webserver related Issues labels Jan 26, 2023
@github-actions
Copy link

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale Stale PRs per the .github/workflows/stale.yml policy file label Mar 23, 2023
@hussein-awala hussein-awala removed the stale Stale PRs per the .github/workflows/stale.yml policy file label Mar 25, 2023
@github-actions
Copy link

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale Stale PRs per the .github/workflows/stale.yml policy file label May 10, 2023
@github-actions github-actions bot closed this May 15, 2023
Copy link
Contributor

@jscheffl jscheffl left a comment

Choose a reason for hiding this comment

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

I like in general the idea to replace the dag_run.confwith params. Som ecomments being added to PR.
What I don't really understand is, why are you adding params as a parallel path and dict in the DB and across all API Calls. Are you planning to keep both in parallel and redundant until dag_run.conf is dropped?
If yes, what happens if user apecifies both in parallel? Will dag_run.conf still pass values over parameters?
If yes, then I believe for the time until fully migrated/deprecated this will generate a lot of confusion for users.
In general I like the approach but the steps for migrating over are not 100% clear to me, might be good to agree with the comminuty which steps to take that majority agree.

type: object
description: |
JSON object describing additional configuration parameters.

The value of this field can be set only when creating the object. If you try to modify the
field of an existing object, the request fails with an BAD_REQUEST error.

*New in version 2.6.0*
Copy link
Contributor

Choose a reason for hiding this comment

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

Needs a bit of update if you re-vitalize

@@ -2627,9 +2665,17 @@ def create_dagrun(
stacklevel=3,
)

if conf:
warnings.warn(
"dag_run conf is deprecated. Please use params instead", DeprecationWarning, stacklevel=2
Copy link
Contributor

Choose a reason for hiding this comment

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

Di we need to add a deprecation warning on CLI as well?

document.getElementById('generated_json_toggle').addEventListener('click', () => {
setTimeout(jsonForm.refresh, 300);
});
// // Ensure layout is refreshed on generated JSON as well
Copy link
Contributor

Choose a reason for hiding this comment

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

Why did you disable this? Was there an error in testing?
This is needed because the section is hidden during load of the form and then the JSON view is not correctly initialized - don't know why - workaround was to initialize it lazy by this.

@@ -129,7 +129,19 @@ <h2>Trigger DAG: {{ dag_id }}</h2>
<input type="text" class="form-control" placeholder="Run ID" name="run_id">
</div>
</div>
{% if recent_confs|length > 0 %}
{% if form_fields and recent_params|length > 0 %}
<div class="form-group row">
Copy link
Contributor

Choose a reason for hiding this comment

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

Mhm, you really want to add two JSON elements here, to be able to trigger using a conf and a params dict? I'd propose to switch to params from conf in this PR, having two fields rather confuses which to use (in my eyes)

@@ -164,65 +176,14 @@ <h4 class="panel-title">DAG conf Parameters</h4>
{% endfor %}
</tbody>
</table>

{% for form_section, form_items in form_fields.values() | groupby(attribute="schema.section", default="") %}
Copy link
Contributor

Choose a reason for hiding this comment

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

Here you remove further sections being displayed... why?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:API Airflow's REST/HTTP API area:CLI area:Scheduler including HA (high availability) scheduler area:UI Related to UI/UX. For Frontend Developers. area:webserver Webserver related Issues stale Stale PRs per the .github/workflows/stale.yml policy file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Able to pass arguments to --conf not specified in parameters argument
2 participants