o-nikolas commented on PR #68403:
URL: https://github.com/apache/airflow/pull/68403#issuecomment-6128400882

   > For the executors etc: it feels like the fix is to say "configure it for 
the worker, so it knows what team it's running for", no?
   
   Yeah, you could probably do it that way, or a few other ways. It comes with 
it's own pros and cons that I'm not sure are any better than the current 
approach thinking about it briefly. If it's important to you to have it work 
that way, and the pieces of code that need an authoritative source of team-name 
still receive that value I'm more than happy to review the PR for that and 
approve.
   
   > > Dag authors: AIRFLOW_CTX_TEAM_NAME / context["dag_run"].team_name makes 
the team name available to dag authors
   > 
   > Yes, but _why_? Making it available isn't a use case or a justification 
for why we should do this.
   
   Sure, you can pick on this one, it's a nice side effect, but the first two 
in mentioned before this one are the current critical uses.
   
   > Again, aren't workers already exclusive to one team, or a free-for-all, so 
this value should be pre-configured and not come form the server? Either the 
executors are per team, or they aren't, but if they aren't can you actually use 
this value and trust it in anyway?
   
   Workers are not necessarily per team. You could have two teams using the 
same pool of celery workers for just one example. And again see the local 
executor, where all workers run in the same host. Workers are also in team 
spaces, so they could just configure any team-name (whether maliciously or 
simply by mistake) which would pollute/break the above items that depend on it.
   
   > If we still think this is a necessary feature to add, I'd rather this was 
exposed to user code as `dag.team_name` or something, not via dag run. (The 
plumbing to get through processes there is another matter, but specifically the 
way it's interacted with)
   
   It's been too long now to remember the details, but you can refer to my 
reply from July which addresses this pretty well I think: 
https://github.com/apache/airflow/pull/68403#discussion_r3531379953


-- 
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]

Reply via email to