jedcunningham commented on a change in pull request #19726:
URL: https://github.com/apache/airflow/pull/19726#discussion_r768197737
##########
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:
At least in my eyes, "backcompat" and "convert" is the same thing 🤷♂️.
I don't think we need to warn about both, but the nuance may be more important
for end users.
In cases where there users aren't using the "old" classes directly, like
your `resources` example (which will
actually get a deprecation warning in #20031), I think we should swallow
the deprecation warning and emit a more helpful one for the user.
For example, for users using dict resources, instead of saying:
```
This module is deprecated. Please use
`kubernetes.client.models.V1ResourceRequirements` and
`kubernetes.client.models.V1ContainerPort`."
```
say (or something like it):
```
Setting resources as a dict is deprecated. Please use
`kubernetes.client.models.V1ResourceRequirements`
```
`env_vars` also has this issue, not sure if there are others though.
Either way, I think the new deprecation warning stuff should be handled in
#20031.
--
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
