dstandish commented on a change in pull request #19726:
URL: https://github.com/apache/airflow/pull/19726#discussion_r763526991
##########
File path:
airflow/providers/cncf/kubernetes/backcompat/backwards_compat_converters.py
##########
@@ -21,18 +21,16 @@
from kubernetes.client import ApiClient, models as k8s
from airflow.exceptions import AirflowException
-from airflow.providers.cncf.kubernetes.backcompat.pod import Port, Resources
-from airflow.providers.cncf.kubernetes.backcompat.pod_runtime_info_env import
PodRuntimeInfoEnv
-def _convert_kube_model_object(obj, old_class, new_class):
+def _convert_kube_model_object(obj, new_class):
convert_op = getattr(obj, "to_k8s_client_obj", None)
if callable(convert_op):
return obj.to_k8s_client_obj()
Review comment:
> PS: Isn't it implied by definition of "Deprecation"?
Removal is implied by the word deprecation, yes. However, KPO is not
making any deprecation warning (which is my concern) yet the KPO _will
eventually_ remove this logic. I think 2 deprecations warnings is the lesser
of 2 evils here (one for "backcompat is gonna be removed" the other for "we
aren't gonna convert forever"), but not a hill to die on and i don't stand in
the way.
Further, the logic
[here](https://github.com/apache/airflow/pull/19726/files#diff-fe570c8d3e660e4fca5e3d1f4be8f3c075d30c37d41d2f66f90d5bfbde964f33R76)
does not even assume a backcompat class -- it is logic to accept kwargs from
a dict. So in that case the user won't have a deprecation warning at all.
Again no dying on hills for me here either and i defer to @jedcunningham
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@airflow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
