o-nikolas commented on PR #69989: URL: https://github.com/apache/airflow/pull/69989#issuecomment-5284154098
> In context of https://github.com/apache/airflow/pull/69989/files#r3616746261 > > I see your point, and on the one hand that makes sense, but on the other hand I worry about listener code from multiple teams and what it means for the security of the shared API server component. Hey @ashb thanks for another review! Are you able to provide some more details on the worries you have here? I don't have much to go off of to really respond without knowing more about what exactly it is that you're worried about. > > Listeners are already a special case and advanced "be careful you might break it feature" so I'm half tempted here to say that since listeners are a power user feature that we don't need, nor want, a per-team listener. I would rather think that exactly because it is a power user feature, that they would want that level of control and security with listener events. But we have no user data to go off of here, it's all speculation. > > My (re)reading of https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/294816378/AIP-67+Multi-team+deployment+of+Airflow+components implies to me that the Listeners are the responsibility of the Deployment manager, and so should be shared across all components, i.e. not per team. All that is really trying to say is that for any plugins that need to be installed on shared components (Scheduler, API Server, etc) the Admin/Deployment Manager is responsible for that (i.e. no single team should have access to the shared space). Meaning that, as part of that management, they may enable or configure team based items (e.g. the team executor configuration lives inside the scheduler host). > > (I am doing this change as a "request changes" so it is more obvious. This is not my veto and a permenant -1, but a big item and needs more eyes on.) Sure no worries, I wouldn't merge a PR without going through the comments and I've been eagerly awaiting your re-review. So no need for the request of change for visibility next time :) --- tl;dr: I'm not sure what your exact concerns/worries are so hard to comment on that. But if anyone else knows or has similar concerns, I'm okay with not making Listeners team based for now. But it is still not clear to me why. Maybe other multi-team folks can weigh in, @vincbeck and @potiuk? -- 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]
