AIP-67 - Introduce team id to executor names and loader

[o-nikolas]

When multi team (AIP-67) is eventually in place, the scheduler will need to initialize a set of executors for each team. This change is a first step towards that which updates the ExecutorName data model and the executor loader to be "team aware".

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[o-nikolas]

CC @potiuk

[shahar1]

I assume that it is done as part of AIP-67 - I think that it's worth mentioning it in the title and contents, as well as creating a project for that so it will become easier to track.
Before merging, it would be nice to outline a roadmap (general guidelines) so it would be clearer to understand the broader context of this task :)

[o-nikolas]

I assume that it is done as part of AIP-67 - I think that it's worth mentioning it in the title and contents, as well as creating a project for that so it will become easier to track.

Yupp this is AIP-67. That's a fair call out, I'll update the description, title and add a tag.
I have a project plan document here which you can read if you're interested. I planned to also create a project board but am still working through the process of disambiguation and really feeling out how it will be pulled off. Once I have a few of the more foundational topics sorted and I have more clarity I will put a board together.

Before merging this one, it would be nice to have a roadmap so it would be clearer to understand the broaded context of this task 🙂

As I said above, I'll work on this, but it has never before been a requirement of merging PRs. And I don't think it's wise to add that barrier to our contribution process. So I don't think it should block this PR's merge.

[shahar1]

I assume that it is done as part of AIP-67 - I think that it's worth mentioning it in the title and contents, as well as creating a project for that so it will become easier to track.

Yupp this is AIP-67. That's a fair call out, I'll update the description, title and add a tag. I have a project plan document here which you can read if you're interested. I planned to also create a project board but am still working through the process of disambiguation and really feeling out how it will be pulled off. Once I have a few of the more foundational topics sorted and I have more clarity I will put a board together.

Before merging this one, it would be nice to have a roadmap so it would be clearer to understand the broaded context of this task 🙂

As I said above, I'll work on this, but it has never before been a requirement of merging PRs. And I don't think it's wise to add that barrier to our contribution process. So I don't think it should block this PR's merge.

I apologize if it was interpreted as a barrier/blocker - it wasn't my intention at all. The doc that you created is exactly what I was looking for, just to understand how it's going to work.