-
Notifications
You must be signed in to change notification settings - Fork 182
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
dbt with kubernetes #493
Comments
After moving my DBT project under Airflow Dags folder, I am getting same error. |
I've got the same issue. The step-by-step guide in the documentation doesn't look like its up to date either. It uses imports ( |
I've added a pull request for an attempt to fix this issue here. |
## Description When creating `DbtTaskGroup`s and `DbtDag`s, a `ProfileConfig` needs to be provided, since it's a required positional argument of the `DbtAirflowConverter` class. However, when providing a `profile_config` in `execution_mode="kubernetes"`, the following Exception is thrown: ``` AirflowException: Invalid arguments were passed to DbtRunKubernetesOperator (task_id: my_first_dbt_model_run). Invalid arguments were: **kwargs: {'profile_config': ProfileConfig(profile_name='jaffle_shop', target_name='dev', profiles_yml_filepath='jaffle_shop/profiles.yml', profile_mapping=None)} ``` In my humble attempt of a solution, I make the `profile_config` an optional argument of the `DbtKubernetesBaseOperator` class (mainly to satisfy the tests ... since its a required argument in the previous part of the "pipeline", having it being a required argument would make sense imho) and parse it inside the `build_kube_args` method (similar, but not identically) to how it is done in the `run_command` method of the `DbtLocalBaseOperator` class. This solution fixes the thrown exception and has the added benefit of giving the user that want to run dbt inside kubernetes the option to specify `--profile` and `--target`, which is a useful feature when wanting to schedule the same model in airflow, pointing to dev and prod targets. I've tested this solution in my GCC environment. ## Related Issue(s) This PR resolves the issue in issue #493 ## Breaking Change? This should fix something that is broken atm, as far as I can see. ## Checklist - [ ] I have made corresponding changes to the documentation (if required) - [ ] I have added tests that prove my fix is effective or that my feature works
Thanks @david-mag .
|
As far as I can see, with the release of this fix, more "unknown" arguments have been added, which broke the kubernetes DAGs and TaskGroups again right away. |
While trying latest release(1.1.1) I ran into another issue and getting below exception:
https://github.com/astronomer/astronomer-cosmos/blob/main/cosmos/operators/kubernetes.py#L21-L26 It seems like the latest version of the cosmos is using the Kubernetes >= 7.4 though the toml file says kubernetes version >=5.1 < 7.3 |
Fix behaviour when using `ExecutionMode.KUBERNETES`, broken between the Cosmos releases 1.0.0 and 1.1.1. Update the documentation to be representative of the 1.x Cosmos interface: https://astronomer.github.io/astronomer-cosmos/getting_started/kubernetes.html Add unit tests to avoid regressions on these fixes. Part of the documentation fixes are made in: astronomer/cosmos-example#4 As a next step, we must ensure integration tests for running Cosmos on K8s to avoid this breaking change moving forward (issue #535). Closes: #493 Closes: #548 Closes: #534 Co-authored-by: Pádraic Slattery <pgoslatara@gmail.com> (who created PR #551)
Fix behaviour when using `ExecutionMode.KUBERNETES`, broken between the Cosmos releases 1.0.0 and 1.1.1. Update the documentation to be representative of the 1.x Cosmos interface: https://astronomer.github.io/astronomer-cosmos/getting_started/kubernetes.html Add unit tests to avoid regressions on these fixes. Part of the documentation fixes are made in: astronomer/cosmos-example#4 As a next step, we must ensure integration tests for running Cosmos on K8s to avoid this breaking change moving forward (issue #535). Closes: #493 Closes: #548 Closes: #534 Co-authored-by: Pádraic Slattery <pgoslatara@gmail.com>
Fix behaviour when using `ExecutionMode.KUBERNETES`, broken between the Cosmos releases 1.0.0 and 1.1.1. Update the documentation to be representative of the 1.x Cosmos interface: https://astronomer.github.io/astronomer-cosmos/getting_started/kubernetes.html Add unit tests to avoid regressions on these fixes. Part of the documentation fixes are made in: astronomer/cosmos-example#4 As a next step, we must ensure integration tests for running Cosmos on K8s to avoid this breaking change moving forward (issue #535). Closes: #493 Closes: #548 Closes: #534 Co-authored-by: Pádraic Slattery <pgoslatara@gmail.com>
Thanks for the details, @rtooker @adityasharma1685 @david-mag, for all the support and information. I believe the release astronomer-cosmos 1.1.2 will solve the pending issues described in this thread: Please, do reach out if any of them persist. |
Similar to #491 but I think subtly different.
I'm using
DbtTaskGroup has a mandatory
profile_config
arg, but when set this seems to be passed through to the DbtRunKubernetesPodOperator causing in exceptionyields
The text was updated successfully, but these errors were encountered: