arroadie commented on issue #23512: URL: https://github.com/apache/airflow/issues/23512#issuecomment-1155678232
> @arroadie I semi-agree. Off hand, here are the basic reasons why it works this way. > Thanks for taking the time to address my comment! Appreciate the explanation > 1. In part it's that way bc it's a holdover from using Flask and Flask AppBuilder within Airflow. Modifying that would take a decent amount of work. Yeah, I thought it would come up to some component acting on its own. While I'm not proposing that this is the right path, I'd say diminishing the amount of "decisions" those components make would definitely improve usability > 2. Airflow generally tries to decouple pieces as much as possible. Your proposal would create a situation where the webserver permissions being up to date would depend on the scheduler running. I admit I haven't read/investigate on the reasons airflow needs to perform those checks and changes each time the webserver starts and I do agree that making those dependencies between the webserver and the scheduler seems like a counter intuitive way to act. Guess my suggestion was guided by the idea that only one component of the service as a whole should be taking the responsibility of making database changes (like migrations) and that component should deal with race conditions and so > 3. If permissions load properly, the current design should guarantee that they're always up to date as soon as the webserver loads, and DB reads/writes should only occur once. Obviously this broke down here. > And I really appreciate people coming to the rescue of the community and fixing them! <3 > So while I'm not aware of your proposed approach being explicitly considered, these are some of the design considerations that support the current design. While it's imperfect, when it works, this approach gives good enough performance and enough flexibility. I don't think it is/would/should... More like a randomly rambling about my thoughts on how tasks (specially internal ones) should be performed. > > That said, there's no reason that it _has_ to work this way, and there are downsides to this approach, such as the slower startup time for the webserver. If you encounter significant problems with the design, especially with multiple webservers, or have suggestions about better architectures, I encourage you to reach out to the community via the mailing list. Agree. I'd say if this should come to become a real issue instead, I'll try to investigate better and reach with a proposal! Again, thanks a bunch for your contributions and for taking the time to respond to my comment. -- 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]
