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 protocol to define methods relied upon by KubernetesPodOperator #31298

Merged
merged 4 commits into from
May 16, 2023

Conversation

dstandish
Copy link
Contributor

@dstandish dstandish commented May 15, 2023

Subclasses of KubernetesPodOperator, such as GKEStartPodOperator, may use hooks that don't extend KubernetesHook. We use this protocol to document the methods used by KPO and ensure that these methods exist on such other hooks.

Related: #31266

In #31266, I added the missing methods to GKESPO and test to ensure consistency. With the introduction of this protocol, this test would no longer be needed, though it will require a dependency for google on the latest CNCF provider

@dstandish dstandish requested review from potiuk and eladkal May 15, 2023 20:30
@dstandish dstandish requested a review from jedcunningham as a code owner May 15, 2023 20:30
@boring-cyborg boring-cyborg bot added provider:cncf-kubernetes Kubernetes provider related issues area:providers provider:google Google (including GCP) related issues labels May 15, 2023
@dstandish
Copy link
Contributor Author

@eladkal @potiuk I am surprised to not see cncf in the list of dependencies for google provider, because the GKPO does inherit from KPO.

Given that with this we'd be introducing a dep in GKPO that depends on a protocol defined in CNCF, first of all is this even workable? And how should we handle this with regard to deps?

Subclasses of KubernetesPodOperator, such as GKEStartPodOperator, may use
hooks that don't extend KubernetesHook.  We use this protocol to document the
methods used by KPO and ensure that these methods exist on such other hooks.
Copy link
Member

@hussein-awala hussein-awala left a comment

Choose a reason for hiding this comment

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

Nice one

@potiuk
Copy link
Member

potiuk commented May 15, 2023

@eladkal @potiuk I am surprised to not see cncf in the list of dependencies for google provider, because the GKPO does inherit from KPO.

We have them, implicitly.

"cross-providers-deps": [

When we prepare "generated/provider_dependencies.json", the cross-provider-dependencies are automatically derived by looking at the imports of other providers from a provider - and they are automatically added to the dependencies and made into "extras" of the provider.

The cross-provider package dependencies are automatically added as "extras" https://airflow.apache.org/docs/apache-airflow-providers-google/stable/index.html#cross-provider-package-dependencies

For example in this case pip install apache-airflow-providers-google[cncf.kubernetes] will automatically install the cncf.kubernetes provider.

This is a "weak" relation between providers which means that some things in the provider might not work in case the extra is not used when installing the provider (or when by chance the provider from extra is not installed). But if we think that the dependency is so strong that one cannot live by another - we can add explicit dependency (and even add >= explicit version which happened in some cases) in the past.

Given that with this we'd be introducing a dep in GKPO that depends on a protocol defined in CNCF, first of all is this even workable? And how should we handle this with regard to deps?

Given that this is one of about a 160 or so operators in google provider, I'd say the weak relation we have is "good enough". You can make an extremely good use of the 159 or so operators in the google provider, without having cncf.kubernetes one installed.

@potiuk
Copy link
Member

potiuk commented May 15, 2023

Btw - maybe thi is what you are after - we could -in fact - make even explicit VERSIONED extra dependency.

This is already happening for google provider `provider.yaml':

additional-extras:
  - name: apache.beam
    dependencies:
      - apache-beam[gcp]
  - name: leveldb
    dependencies:
      - plyvel
  - name: oracle
    dependencies:
      - apache-airflow-providers-oracle>=3.1.0
  - name: facebook
    dependencies:
      - apache-airflow-providers-facebook>=2.2.0
  - name: amazon
    dependencies:
      - apache-airflow-providers-amazon>=2.6.0

You could add there:

  - name: cncf.kubernetes
    dependencies:
      - apache-airflow-providers-cncf-kubernetes>=6.2.0

And what would happen, if someone does pip install apache-airflow-providers-google[cncf.kubernetes] - then minimum 6.2.0 version of the cncf.kubernetes provider will be installed (assuming that the protocol is going to be added in 6.2.0).

@@ -24,7 +24,7 @@
from contextlib import closing, suppress
from dataclasses import dataclass
from datetime import datetime, timedelta
from typing import TYPE_CHECKING, Generator, cast
from typing import TYPE_CHECKING, Generator, Protocol, cast
Copy link
Member

Choose a reason for hiding this comment

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

Small problem - until end of June, Protocol needs to be imported as:

from airflow.typing_compat import Protocol

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks

@dstandish
Copy link
Contributor Author

You could add there:

  - name: cncf.kubernetes
    dependencies:
      - apache-airflow-providers-cncf-kubernetes>=6.2.0

And what would happen, if someone does pip install apache-airflow-providers-google[cncf.kubernetes] - then minimum 6.2.0 version of the cncf.kubernetes provider will be installed (assuming that the protocol is going to be added in 6.2.0).

ok thanks i will do this

@potiuk
Copy link
Member

potiuk commented May 15, 2023

And what would happen, if someone does pip install apache-airflow-providers-google[cncf.kubernetes] - then minimum 6.2.0 version of the cncf.kubernetes provider will be installed (assuming that the protocol is going to be added in 6.2.0).

Yep. Just checked in https://github.com/apache/airflow/pull/31252/files that we are going to have 6.2.0 version of the cncf.kubernetes provider.

@uranusjr
Copy link
Member

I’m trying to bulk-fix the migration errors in #31306.

@dstandish
Copy link
Contributor Author

I’m trying to bulk-fix the migration errors in #31306.

cool, will wait for that one

i tried to fix them all in #31306 but it got merged just before i discovered there were others and tried to add them

@dstandish
Copy link
Contributor Author

er i'll just merge, don't think it will create a conflict for you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:providers provider:cncf-kubernetes Kubernetes provider related issues provider:google Google (including GCP) related issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants