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

DbtTaskGroup - Kubernetes Execution with RenderConfig #943

Closed
Tracked by #1103
harshag7dm opened this issue May 7, 2024 · 5 comments · Fixed by #1100
Closed
Tracked by #1103

DbtTaskGroup - Kubernetes Execution with RenderConfig #943

harshag7dm opened this issue May 7, 2024 · 5 comments · Fixed by #1100
Assignees
Labels
area:execution Related to the execution environment/mode, like Docker, Kubernetes, Local, VirtualEnv, etc area:rendering Related to rendering, like Jinja, Airflow tasks, etc epic-assigned execution:kubernetes Related to Kubernetes execution environment triage-needed Items need to be reviewed / assigned to milestone
Milestone

Comments

@harshag7dm
Copy link

When I use Kubernetes Execution in DbtTaskGroup and try to filter out the Models using tag, it doesn't work. There is no Kubernetes pod being run.
If I remove the RenderConfig, then all the models are run?
Is this a bug or am I missing something?

Copy link

dosubot bot commented May 7, 2024

It sounds like you're encountering an issue where using RenderConfig with DbtTaskGroup in a Kubernetes environment doesn't trigger the execution of pods when filtering models by tag. This could be due to a configuration issue or a more complex problem within the interaction of DbtTaskGroup, RenderConfig, and Kubernetes Execution.

To address this, ensure that your DbtTaskGroup is correctly configured to include the tag filter in its arguments for dbt tasks. The RenderConfig should be set up properly with the necessary class arguments and Kubernetes-specific configurations. For detailed guidance, refer to the documentation on configuring RenderConfig and Kubernetes execution in the Cosmos repository.

Additionally, check for any recent changes or updates in the Cosmos repository that might affect this functionality. Specifically, look into the changelog for updates related to Docker and Kubernetes operators, as these could impact how DbtTaskGroup operates with Kubernetes Execution.

If the issue persists, examining the logs or error messages for any clues on why the Kubernetes pod is not being initiated could provide further insights. The DbtTestKubernetesOperator class, for example, includes methods designed to handle warnings and extract log issues, which might reveal underlying problems.

If you can provide more details about your configuration and any specific error messages you're encountering, it would help in diagnosing and resolving the issue more effectively.

Details

Sources


About Dosu
This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

To continue the conversation, mention @dosu.

@dosubot dosubot bot added area:execution Related to the execution environment/mode, like Docker, Kubernetes, Local, VirtualEnv, etc area:rendering Related to rendering, like Jinja, Airflow tasks, etc execution:kubernetes Related to Kubernetes execution environment labels May 7, 2024
@tatiana
Copy link
Collaborator

tatiana commented May 8, 2024

@harshag7dm please, could you confirm which version of Cosmos you've tried, with which DAG?

@tatiana
Copy link
Collaborator

tatiana commented May 17, 2024

@tatiana tatiana added this to the 1.5.0 milestone May 17, 2024
@tatiana tatiana added the triage-needed Items need to be reviewed / assigned to milestone label May 17, 2024
@tatiana tatiana modified the milestones: Cosmos 1.5.0, Cosmos 1.6.0 Jun 6, 2024
@tatiana tatiana modified the milestone: Cosmos 1.6.0 Jul 1, 2024
@pankajastro
Copy link
Contributor

This is a legitimate issue. I can replicate it using the steps outlined above. I’ll create a PR to address it.
Screenshot 2024-07-16 at 10 51 00 PM

@pankajastro
Copy link
Contributor

pankajastro commented Jul 17, 2024

I investigated further and found that when the manifest is unavailable and the execution mode isn't set to ExecutionMode.LOCAL, we're using the custom parser to load the dbt project. However, this custom parser currently does not support selectors.

if execution_mode == ExecutionMode.LOCAL and self.profile_config:
try:
self.load_via_dbt_ls()
except FileNotFoundError:
self.load_via_custom_parser()
else:
self.load_via_custom_parser()

The workaround I tried

  • Use load_via_dbt_ls for other execution modes as well, although I'm uncertain about any potential side effects.
  • Extract the tag in the custom parser method and assign it to the node. This is currently set to empty.

In both cases, the DAG rendering is like below for dag https://github.com/astronomer/cosmos-example/blob/main/dags/jaffle_shop_kubernetes.py with addition param render_config

render_config=RenderConfig(
            select=["tag:customers"],
        ),
Screenshot 2024-07-17 at 7 01 53 PM

tatiana pushed a commit that referenced this issue Jul 19, 2024
…1101)

The `load_via_custom_parser` method is not very effective 
when it comes to filtering. Currently, if the ExecutionMode 
is not Local, we always use load_via_custom_parser to parse 
the dbt project. However, I believe it's beneficial to utilize DBT LS 
whenever it's available. This PR removes the check if the 
execution mode is ExecutionMode.LOCAL before `load_via_dbt_ls`

Related: #943
@tatiana tatiana mentioned this issue Aug 16, 2024
18 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:execution Related to the execution environment/mode, like Docker, Kubernetes, Local, VirtualEnv, etc area:rendering Related to rendering, like Jinja, Airflow tasks, etc epic-assigned execution:kubernetes Related to Kubernetes execution environment triage-needed Items need to be reviewed / assigned to milestone
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants