potiuk commented on code in PR #52952:
URL: https://github.com/apache/airflow/pull/52952#discussion_r2189721063
##########
providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py:
##########
@@ -213,12 +214,18 @@ def change_maintenance_comment(self, worker_name: str):
except AirflowConfigException:
EDGE_EXECUTOR_ACTIVE = False
+# Load the API endpoint only on api-server (Airflow 3.x) or webserver (Airflow
2.x)
+if AIRFLOW_V_3_0_PLUS:
+ RUNNING_ON_APISERVER = sys.argv[1] in ["api-server"] if len(sys.argv) > 1
else False
+else:
+ RUNNING_ON_APISERVER = "gunicorn" in sys.argv[0] and "airflow-webserver"
in sys.argv
Review Comment:
> Thanks for the general comment. I agree and ad-hoc I have no "something"
better idea. I would call it a "bootstrap" problem of dependencies.
Yep. That's a good term.
> From my experience the plugins_manager is very central in the middle.
Whereas I am not sure whether the "@providers_configurations_loaded" is the
right approach. I feel like in a couple of areas we initialize too much.
Yeah. It was more of an attempt to make a deferred initialization, but we
could be even more explicit and simply do the initialization verbatim in every
`CLI` command we run doing the right set of initilalizations. That would likely
be even better
> Challenge is that we have passed the release of 3.0 and if we change this
it will be very fundamental- Calling for a 4.0 is too early so we need to be
able to accept short term the situation and if we want to make something
"better" we need to make it backwards-compatible. Which makes it even harder.
I do not think doing stuff in `__init__.py` is part of the public interface
of ours. And I do not think it's even highly breaking as long as we make sure
all our CLIs have "proper" initialization sequence, we should be good I think,
While it might break some CI's or some test scenarios out there, I think it's
not breaking for any "production" use of Airlfow. There quite a few even more
potentially breaking changes coming in 3.1 when we complete Task Isolation -
mostly because it is not finished in 3.0 and because we implicitly depended on
some imports and intiialisations - but this will also be fixed in 3.1, so I'd
say 3.1 (or 3.2 - dependnig on task isolation completeness) might be even
**better** suited for this than 3.0 was (mostly because the work on task
isolation was not completed in 3.0).
> I share this feeling.
> Calling for ideas on devlist would be a good option. But if you did
already it might end-up in the same. At least I will have some sleeps about
it... but I am not sure if I will have any better idea...
I will raise it then. I see a chance for a good discussions and decisions
then :)
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
