Hi Bolke, Thanks for your feedbacks! Here are my points:
> I think the name “User Manager” is a misnomer and it should just be called > “Security Manager”. I am very open to change the name of "User Manager" but I do not think we should call it "Security Manager". "Security Manager" is the current name and I think this is a very bad name because: it is very generic and does not say much about what it is actually doing. By reading "Security Manager" I would not think this is where users and roles are managed. The main goal of AIP-56 is removing the whole user management part from core Airflow to providers. Keeping the name "Security Manager" would, I think, leave a legacy for all future user managers (or whatever name we use) on Flask-AppBuilder (FAB) and that's exactly what I want to avoid. I chose the name “User Manager” but I think it is simple, the main goal of this new module is to manage users and access for them. > is_authorized should include context so that it becomes possible the > determine whether a user has access to a resource based on for example the > location the user is at. Or in which environment. It is also useful for > auditing. Non implementing security managers can ignore it. I agree, that can be indeed a good improvement. Although I have to say I am pretty confident the AIPs I defined in the API will change while implementing them and over time. Thus, another option would be to add this context when needed. I do not think (I might be wrong) features such as " determine whether a user has access to a resource based on for example the location the user is at. Or in which environment" currently exist in Airflow. The goal of the AIP is not to implement new features but to have the same features as we have today with this separation from core Airflow to providers. Again, I am not saying this is a wrong idea (and I actually think this is a good one), I just think if this feature does not exist in Airflow today, we should add that later. > What is the need of post_login? Why would you want to store the access token? > The security manager should, imho, do this on its own: it executes the login > flow. The access token is needed to call any API from the user manager to the third party backend (KeyCloak, ...). How would you call is_authorized() without it? > Why is get_tab_configuration special? We have this possibility in standard > “plugins”. I suggest using that framework I am not familiar with plugins. I'll take a look at it, thanks for bringing it up. > What is the need for “get_user_name”? Are we going to invent our own > Framework? Otherwise Flask might work? get_user_name is needed for the UI. On the top right corner of Airflow console, you can see your name. This is why it is needed. The only goal of this API is to retrieve your user name from the user manager. That's it. Flask will then use this API to get the user name and display it in the UI. My experience in Flask is pretty limited so I might miss something but the way I see it is, you need a way to retrieve your user name from whatever user manager you are using. This is the way. I hope that helps, Vincent On 2023-05-15, 5:30 PM, "Bolke de Bruin" <bdbr...@gmail.com <mailto:bdbr...@gmail.com>> wrote: I think think the name “User Manager” is a misnomer and it should just be called “Security Manager”. It was confusing the hell out of me when reading the AIP and I was convinced you wanted to fully manage e.g. keycloak provided users inside Airflow (CRUD). What you are doing but aren’t exactly saying: 1 - Define API that a Security Plugin should adhere to (AuthZ/AuthN) 2 - Have a default Security Plugin based on FAB Points of improvement: * is_authorized should include context so that it becomes possible the determine whether a user has access to a resource based on for example the location the user is at. Or in which environment. It is also useful for auditing. Non implementing security managers can ignore it. * I’d prefer some kind of ’standards’ based API. Like using Flask’s way of registering endpoints or something along those lines. See also questions below. Questions: * What is the need of post_login? Why would you want to store the access token? The security manager should, imho, do this on its own: it executes the login flow. * Why is get_tab_configuration special? We have this possibility in standard “plugins”. I suggest using that framework * What is the need for “get_user_name”? Are we going to invent our own Framework? Otherwise Flask might work? Cheers Bolke On 9 May 2023 at 19:55:32, Beck, Vincent (vincb...@amazon.com.inva <mailto:vincb...@amazon.com.inva>lid) wrote: Hello all, I would like to start voting on this one so please add your comments on the API or by replying here if you're interested, you still have time to do it :) AIP: https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management> Vincent On 2023-05-03, 8:03 AM, "Jarek Potiuk" <ja...@potiuk.com <mailto:ja...@potiuk.com> <mailto: ja...@potiuk.com <mailto:ja...@potiuk.com>>> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Alsoo to add (and make more concrete) to what it could mean at the implementation level. It means the for our API endpoints and views is that instead of @auth.hasaccess (for example here https://github.com/apache/airflow/blob/main/airflow/www/views.py#L680 <https://github.com/apache/airflow/blob/main/airflow/www/views.py#L680> < https://github.com/apache/airflow/blob/main/airflow/www/views.py#L680> <https://github.com/apache/airflow/blob/main/airflow/www/views.py#L680>>) where it check for permissions assigned to current role, airflow would entirely delegate the decision to the 'user management plugin'. We would simply delegate the decision to whatever plugin we have configured. In case FAB pługin is used, it would do exactly the same checks as today (and FAB pługin would contribute the 'Security' menu the same way other plugins can contribute their own (as well as CLI commands and user/role APIs - we would have to add a mechanism where plugins could contribute CLIs and APIs on their own, but that should be easy). So if you have FAB pługin chosen as default, nothing changes for the users comparing to today. It would not require bumping Airflow Major version because it would be backwards compatible. However similarly as providers it would move the code of FAB plugins and roles out of the core of Airflow. We could have keycloak 'reference' implementation where we would come up with very opinionated approach where we have simple admin/user roles (matching roughly default set of roles and permissions we currently have with FAB). The big difference here will be that the user/role APIs, views, CLIs will be gone entirely. And we could add there the concept of 'tenants' or rather 'teams' giving access to 'dag groups' and implement decisions ob authorisation based on 'group' assignment for dag and user. This is the main goal of this change to make it possible and easy without having to mess with FAB permission and Role model which is completely not suitable to manage 'groups of resources of the same type' with separate set of permissions (think having few separate teams or tenants - each of them wanting access to separate set of DAGs). Currently if an SSO/enterprise user wants to plug in their authn/authz with group access - they have to deal with all that including cumbersome syncing of permissions for individual DAGs matching them to users separately - just to satisfy FAB permission model lacking this feature and flexibility. No more need for that if we go the direction described here. And that's basically it for what we would implement in Airflow out-of-the-box: FAB minimal implementation + be keycloak opinionated reference implementation with simple teams/tenant support This also makes it super flexible for those who want more flexibility and do not want to use our opinionated keycloak plugin. They will be entirely free to implement their own ways - as flexible or as opinionated they want - without having to messwith permission syncing and the role model of FAB. Nor keycloak integration. They could go with their own. And with that - sky is the limit. The decision to access particular dag could be made based on folder where the dag is from, id of dag, or dag label or whatever other parameter (as long as we pass all that information to the plugin). You could even - if you really want - make a decision to allow certain users (and only them) to be able to clear individual tasks, or tasks where specific operator types are used. For example you could decide if you really want to only allow th google cloud admin users to clear tasks that are operators coming from Google Provider (why not?). Or only allow to that in certain time windows, or .... whatever. It's extremely flexible and powerful - but we will not have to deal with all the complexity in the community - we could delegate it to those who mange the deployment or manage deployment of Airflow as a service and decide they want to integrate it with the service authorisation that is already there - think direct integratio with IAM ON AWS or GCP. And if we just provide a reference, opinionated implementation for keycloak with tenant support and legacy/minimal FAB as optional plugins, that should also 'good enough' for those who do not want to implement their own plugin implementation. J. śr., 3 maj 2023, 12:34 użytkownik Jarek Potiuk <ja...@potiuk.com <mailto:ja...@potiuk.com> <mailto: ja...@potiuk.com <mailto:ja...@potiuk.com>>> napisał: > > I don't think we can do that: we still need to consider users when they > are just getting started out with Airflow -- if we only cater to giant > enterprises with SSO and a central directory we remove our ability for > individual or small teams/companies to get started with Airflow. > > Let me clarify this because I think we are talking about the same thing. > > I **think** having the "minimal FAB user manager implementation" as the > "default" option when you install Airflow serves the purpose you mention > Ash - if we do it the way that User/Role management is coming together with > FAB implementation (enabled by default for the initial installation). What > I am saying is that it should not be part of the "core airflow" in the > sense that one could live without it (specifically in those big SSO/Central > directory case). > In my vision those two cases are separated, but the "minimal > implementation" when enabled should act and behave "as if" nothing changed > compared to the current way it looks and behaves. > > J. > > > On Wed, May 3, 2023 at 12:06 PM Ash Berlin-Taylor <a...@apache.org > <mailto:a...@apache.org> <mailto: a...@apache.org <mailto:a...@apache.org>>> wrote: > >> > - I am fine with (and actually I like it better) removing User and Role >> related Rest APIs and CLI commands from Airflow. That will indeed make the >> AIP way simpler and shorter >> >> I don't think we can do that: we still need to consider users when they >> are just getting started out with Airflow -- if we only cater to giant >> enterprises with SSO and a central directory we remove our ability for >> individual or small teams/companies to get started with Airflow. >> On May 2 2023, at 8:23 pm, Beck, Vincent <vincb...@amazon.com.inva >> <mailto:vincb...@amazon.com.inva> <mailto:vincb...@amazon.com.inva <mailto:vincb...@amazon.com.inva>>LID> >> wrote: >> > Thank you Jarek and Bolke for taking time to read and provide feedback >> to the AIP, much appreciated! Multiple points here: >> > >> > - I am fine with (and actually I like it better) removing User and Role >> related Rest APIs and CLI commands from Airflow. That will indeed make the >> AIP way simpler and shorter. As I explained in the AIP comments, I am >> suggesting though to leave an option to user managers to define additional >> REST APIs and CLI commands if they need. By default no additional REST API >> and CLI command would be defined but user managers would have the option to >> override it. FAB user manager would be an example of user manager >> overriding such methods. In any case, if additional Rest API or CLI command >> is defined, this would be done in user managers (as opposed to core >> Airflow). >> > - "the whole "Security" menu should be GONE completely". >> > > I agree with this when the user manager is not the FAB one, however >> we need to introduce a new one so Admins can easily go the external user >> manager console (e.g. KeyCloak, ...). This new tab would only be a >> link/redirect to the external console. >> > >> > - "All those components (and code related to those) should be moved to >> FAB minimalistic user manager (and removed from Airflow Core)". >> > > 100%. This is the main principle of this AIP, anything related to >> user management will be moved to user managers. >> > >> > - "AuthN and AuthZ should be completely removed from Airflow". >> > > 100%. >> > >> > - "So for a nice out-of-the-box experience (pip install apache-airflow) >> a lightweight User Manager could exist as a side project and have some >> menus via the plugin system until something better comes along.". >> > > I agree with you on the long term. Though, as a first iteration I >> think it is better to define a user manager using FAB as default user >> manager. The benefit of doing so is to have a backward compatible >> transition between before AIP and after AIP. This also simplifies the AIP >> since it is easier to move files from core Airflow to user managers than >> creating something new. Creating a new security model would be a challenge >> too. However, once the AIP implemented and merged, we can easily replace >> this out-of-the-box FAB user manager by something "better" if the communty >> thinks this is the right way to go. >> > >> > As always, feel free to give me your thoughts. >> > Vincent >> > On 2023-04-25, 2:00 PM, "Bolke de Bruin" <bdbr...@gmail.com >> > <mailto:bdbr...@gmail.com> <mailto: bdbr...@gmail.com <mailto:bdbr...@gmail.com>> <mailto: >> bdbr...@gmail.com <mailto:bdbr...@gmail.com> <mailto:bdbr...@gmail.com >> <mailto:bdbr...@gmail.com>>>> wrote: >> > I'm not sure if I read the AIP correctly. I think I concur with Jarek >> here. >> > >> > AuthN and AuthZ should be completely removed from Airflow. Access >> > management should be outsourced to something like Open Policy Agent. In >> > other words there should be no user management at all within Airflow. >> This >> > removes the need to "sync" users (and thus become outdated) and reduces >> the >> > attack surface drastically. So for a nice out-of-the-box experience (pip >> > install apache-airflow) a lightweight User Manager could exist as a side >> > project and have some menus via the plugin system until something better >> > comes along. Keycloak is great, a bit heavy for us to package >> > unfortunately. >> > >> > >> > FAB's security model is very non-standard and requires 'unnatural' >> mappings >> > in an enterprise context. It has served us well, but I would say good >> > riddance. >> > >> > >> > Bolke >> > >> > >> > >> > >> > >> > Op ma 24 apr 2023 om 08:39 schreef Jarek Potiuk <ja...@potiuk.com >> > <mailto:ja...@potiuk.com> <mailto:ja...@potiuk.com <mailto:ja...@potiuk.com>> >> <mailto:ja...@potiuk.com <mailto:ja...@potiuk.com> <mailto:ja...@potiuk.com >> <mailto:ja...@potiuk.com>>>>: >> > >> > > I had a look and I liked what I saw for how we should integrate the >> new >> > > user manager for getting and checking the access :). >> > > >> > > But I think the AIP proposal is not bold enough when it comes to the >> user >> > > management part. This is one big comment - we should simplify it even >> > > further and cut more deeply. >> > > >> > > One of the big changes I think is super important with extensible user >> > > management is that we should delegate even more to the external >> systems >> > > managing users. The AIP attempts to map the current API/CLI/UI for >> managing >> > > the users and roles to the new external user management services - >> but it >> > > is IMHO absolutely not needed. >> > > >> > > As I see the extensible user management is that when you choose >> something >> > > else than the legacy FAB minimalist user management. Airflow should >> become >> > > just "user" of that user/role information managed elsewhere. It >> should not >> > > provide ANY option to see and manage the users or roles, it should >> merely >> > > read the information and give access to the users for appropriate >> actions, >> > > but then all the role/user management should happen outside of >> Airflow - in >> > > the system that is dedicated to manage those. >> > > >> > > IMHO - when other than the "non FAB minimalistic user manager" system >> is >> > > used. Airflow should just not have a number of functionalities at all: >> > > >> > > * not have "users" or "roles" CLI groups at all - they should be >> missing >> > > * the >> > > >> > > >> https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/User <https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/User> < https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/User> <https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/User>> >> < >> https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/User <https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/User> < https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/User> <https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/User>> >> > >> > > and >> > > >> > > >> https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/Role <https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/Role> < https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/Role> <https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/Role>> >> < >> https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/Role <https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/Role> < https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/Role> <https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#tag/Role>> >> > >> > > should return 404 NOT FOUND >> > > * the whole "Security" menu should be GONE completely. >> > > >> > > All those components (and code related to those) should be moved to >> FAB >> > > minimalistic user manager (and removed from Airflow Core). Eventually >> maybe >> > > even moved out of the Airflow repo altogether and moved to a FAB user >> > > manager add-on to airflow. >> > > >> > > This might seem a drastic change, but in fact - it's not drastic at >> all. It >> > > reflects what many of the Airflow users are doing now - they never >> access >> > > Security/Admin/Roles. Once they integrate with their LDAP or other >> > > corporate directory, the Security UI, CLI and REST API are essentially >> > > useless (and not used). >> > > >> > > And it is precisely what we want to achieve - we want to delegate the >> > > user/role management completely out of Airflow. In fact - getting rid >> of >> > > those is the only reason we want to implement the change. If we >> **just** >> > > replace the current FAB and keep all the complexity of managing the >> users >> > > /roles in Airflow, I'd say we have not achieved anything but adding >> > > complexity. >> > > >> > > And - eventually - it makes the AIP-56 way *smaller*. We just need to >> make >> > > sure that all the stuff for user management (including REST API, CLI >> and >> > > the UI) is moved to the "FAB minimalistic user manager" (and add ways >> to >> > > plug-it in the core - possibly using existing plugins mechanisms where >> > > needed). We do not need to define new API for user/role management. >> We only >> > > need to describe the way how to check if the user has permission to do >> > > stuff. >> > > >> > > J. >> > > >> > > >> > > >> > > >> > > On Mon, Apr 17, 2023 at 12:34 PM Jarek Potiuk <ja...@potiuk.com >> > > <mailto:ja...@potiuk.com> <mailto:ja...@potiuk.com <mailto:ja...@potiuk.com>> >> <mailto:ja...@potiuk.com <mailto:ja...@potiuk.com> <mailto:ja...@potiuk.com >> <mailto:ja...@potiuk.com>>>> wrote: >> > > >> > > > I promise to provide my feedback by the end of the week, sorry for >> > > > delaying it, but we had some 2.6 preparation, branching, feature >> flags >> > > etc. >> > > > also for AIP-44 and I am getting back on track with that one soon. >> > > > >> > > > On Fri, Mar 31, 2023 at 9:35 AM Mehta, Shubham >> <shu...@amazon.com.inva <mailto:shu...@amazon.com.inva> >> <mailto:shu...@amazon.com.inva <mailto:shu...@amazon.com.inva>> <mailto: shu...@amazon.com.inva <mailto:shu...@amazon.com.inva> <mailto:shu...@amazon.com.inva <mailto:shu...@amazon.com.inva>>>lid >> > > > >> > > > wrote: >> > > > >> > > >> Bumping this up for feedback! >> > > >> >> > > >> @Vikram, @Kaxil, et al. - I understand that you're quite busy, but >> we >> > > >> would greatly appreciate your feedback here. Your inputs could >> help us >> > > >> improve the proposal and move forward with multi-tenancy work. >> > > >> >> > > >> Cheers, >> > > >> Shubham >> > > >> >> > > >> >> > > >> On 2023-03-28, 2:05 PM, "Beck, Vincent" <vincb...@amazon.com.inva >> > > >> <mailto:vincb...@amazon.com.inva> <mailto:vincb...@amazon.com.inva <mailto:vincb...@amazon.com.inva>> >> <mailto:vincb...@amazon.com.inva <mailto:vincb...@amazon.com.inva> >> <mailto:vincb...@amazon.com.inva <mailto:vincb...@amazon.com.inva>>> >> > > >> <mailto:vincb...@amazon.com.inva <mailto:vincb...@amazon.com.inva> >> > > >> <mailto:vincb...@amazon.com.inva <mailto:vincb...@amazon.com.inva>> <mailto:vincb...@amazon.com.inva <mailto:vincb...@amazon.com.inva> <mailto:vincb...@amazon.com.inva <mailto:vincb...@amazon.com.inva>>>>LID> >> wrote: >> > > >> >> > > >> >> > > >> CAUTION: This email originated from outside of the organization. >> Do not >> > > >> click links or open attachments unless you can confirm the sender >> and >> > > know >> > > >> the content is safe. >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> Hi all, >> > > >> >> > > >> >> > > >> I would like to get your feedback on an AIP I wrote: "Extensible >> user >> > > >> management". This AIP is a follow-up on a discussion we had in this >> > > email >> > > >> list on the multi tenancy topic. I decided to create a new email >> thread >> > > >> because I feel the topic had diverged a bit from the original topic >> > > (multi >> > > >> tenancy). >> > > >> >> > > >> >> > > >> As a summary, the purpose of this AIP is to extract the user >> management >> > > >> from core Airflow by introducing a user manager interface in the >> core >> > > >> Airflow that can be extended by any provider package who want to >> support >> > > >> user management natively. As a result, if this AIP gets approved >> and go >> > > >> through, the multi tenancy feature will be implemented as a second >> step >> > > in >> > > >> a new user manager and not in Airflow directly. >> > > >> >> > > >> >> > > >> As always, feel very free to give your opinion on this email >> thread or >> > > on >> > > >> the AIP by adding comments. >> > > >> >> > > >> >> > > >> References: >> > > >> - AIP: >> > > >> >> > > >> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management> < https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management> <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management>> >> < >> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management> < https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management> <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management>> >> > >> > > >> < >> > > >> >> > > >> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management> < https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management> <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management>> >> < >> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management> < https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management> <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management>> >> > >> > > >> > >> > > >> - Initial email list discussion: >> > > >> https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61 >> > > >> <https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61> < https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61> <https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61>> < >> https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61> >> <https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61>> < https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61>> <https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61&gt;>> < >> > > >> https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61> >> > > >> <https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61>> <https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61>> <https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61&gt;>> >> <https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61>> >> <https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61&gt;>> >> < https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61&gt;>> <https://lists.apache.org/thread/lf585xvvxpqtzhfyc6drzrf3rmg37w61&amp;gt;&gt;>> >> > > >> >> > > >> >> > > >> Vincent >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> > >> > >> > >> > >> > -- >> > >> > -- >> > Bolke de Bruin >> > bdbr...@gmail.com <mailto:bdbr...@gmail.com> <mailto:bdbr...@gmail.com >> > <mailto:bdbr...@gmail.com>> <mailto:bdbr...@gmail.com >> > <mailto:bdbr...@gmail.com> <mailto:bdbr...@gmail.com <mailto:bdbr...@gmail.com>>> >> > >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org >> > <mailto:dev-unsubscr...@airflow.apache.org> <mailto: dev-unsubscr...@airflow.apache.org <mailto:dev-unsubscr...@airflow.apache.org>> >> > For additional commands, e-mail: dev-h...@airflow.apache.org >> > <mailto:dev-h...@airflow.apache.org> <mailto: dev-h...@airflow.apache.org <mailto:dev-h...@airflow.apache.org>> >> > >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org <mailto:dev-unsubscr...@airflow.apache.org> For additional commands, e-mail: dev-h...@airflow.apache.org <mailto:dev-h...@airflow.apache.org>
