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

Add ability to interact with OpenSearch in AWS #39378

Open
1 task done
eladkal opened this issue May 2, 2024 · 3 comments
Open
1 task done

Add ability to interact with OpenSearch in AWS #39378

eladkal opened this issue May 2, 2024 · 3 comments
Labels

Comments

@eladkal
Copy link
Contributor

eladkal commented May 2, 2024

Body

We have OpenSearch provider but currently it can't be used with AWS auth mechanisms.
We need to create a version of it in AWS provider (overriding only that particular portion of the Hook)

This effort started in #34693

Note this is about querying open search - it's not about submitting Airflow logs to open search (for that we have another task #33619 )

Committer

  • I acknowledge that I am a maintainer/committer of the Apache Airflow project.
@Taragolis
Copy link
Contributor

We have OpenSearch provider but currently it can't be used with AWS auth mechanisms.

My 2 cents, it is happen due to fundamental problem with Connections and Hooks, it is very tight coupled with hooks and can't easily extend in current implementation due to current Airflow design.

Some abstract example:

  • 1 Hook which interact with some stuff, like AwsomeDbWhichEveryoneWantToUse
  • 10 Operators, 5 sensors, 15 Triggers all of them use Hook

In this case it is required not only change implementation in hoop but also change in operators, sensors, triggers. For each cloud provider with own auth methods 🙄

@rawwar
Copy link
Contributor

rawwar commented May 5, 2024

In this case it is required not only change implementation in hoop but also change in operators, sensors, triggers. For each cloud provider with own auth methods 🙄

Would it be a good idea to implement a dialect like sqlalchemy does? This would allow the user to provide the necessary details and the dialect, and internally, we would choose the appropriate hook. This approach would make it easier to maintain or extend the system, especially when multiple hooks cater to different types of backend systems while the user will always use a single operator class with varying arguments

@Taragolis
Copy link
Contributor

It is close to idea of dialects in SA, but more related to the authentication. Some of the hooks supports more then one method of auth thought extras, which is hard to validate in the UI due to mutuality exclusions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants