Hi Max, Joy and Everyone, Based on the discussion, I put up a work in progress pr ( https://github.com/apache/incubator-airflow/pull/3197/) with a doc( https://docs.google.com/document/d/1qs26lE9kAuCY0Qa0ga- 80EQ7d7m4s-590lhjtMBjmxw/edit#) for DAG level access. I would like to get some early feedbacks and see if I miss anything or am in the wrong direction as it touches the core part.
In the meantime, I will still continue improving the pr for couples of todos. Looking forward to your feedback. Thanks, -Tao On Mon, Apr 2, 2018 at 2:44 PM, Tao Feng <fengta...@gmail.com> wrote: > Hi everyone, > > Thanks a lot for all the great discussions. To summarize in brief, here > are the few approaches we discussed so far: > > 1. One permission per DAG. The user has homogenous rights on the dag. > The concerns: > > - not flexible to certain use cases(e.g the user has view only access > on certain dags and write access on certain other dags ); > - difficult to implement as it breaks the existing FAB security model. > > 2. Extend current model(ab_permission_view_role) with an additional > optional column (dag_id). > The concerns: > > - introduce a 3rd column to existing permission_view table. > - It requires us to handle db migration carefully from view only > access UI to dag level access UI. > > 3. Define a set of pre-defined dag-level permissions. Reuse the current > existing permission_view model and consider each individual dag as a new > view. > > It seems that the 3rd approach is a preferable approach which makes the > security model easy to extend without introducing additional complexity. If > no other concern, I will work with Max to create an initial proposal / PR > based on 3rd approach for the work(https://issues.apache.org > /jira/browse/AIRFLOW-2267). > > Thanks, > -Tao > > On Sat, Mar 31, 2018 at 12:09 AM, Joy Gao <j...@wepay.com> wrote: > >> +1! >> >> I was originally tempted to re-use existing perms and views for dag-level >> access control since dag-level perm/view is a subset of view-level >> perm/view, but your proposal of defining new dag-level perms/views >> independent from view-level perms/views is interesting. This actually >> makes >> a lot of sense, since even in the existing models, views can also be menu >> options, so we are simply extending the concept of views to include dags >> as >> well. >> >> On Fri, Mar 30, 2018 at 5:24 PM Maxime Beauchemin < >> maximebeauche...@gmail.com> wrote: >> >> > I'd suggest something else that avoids having to add a 3rd column. I >> think >> > we can fit our use case into the existing structure nicely. >> > >> > My idea is to mimic what FAB does with its own Models. >> > >> > When you create a Model and ModelView in FAB (say DagRun for example), >> it >> > creates a new view_menu (DagRun) and matches it with existing permission >> > (can_read, can_delete, can_edit, can_show, ...) to create a new set of >> > "permission_views" which are combinations of permission and view_menu >> as in >> > "DagRun - can_read", "DagRun - can_edit", ... It's not a cartesian >> product >> > of all perms and view_menus, it's a predetermined list of model-specific >> > perms that get combined with DagRun here. >> > >> > Similarly, when Airflow would detect a new DAG (example "my_dag"), it >> > would create a new view_menu `my_dag`, and match it with permissions >> that >> > are identified as "combinable" with DAG. To avoid potential conflicts >> I'd >> > create new permissions that are DAG-specific like "dag_clear", >> "dag_run", >> > "dag_view". >> > >> > I'm arguing about the how to use the FAB model here specifically. I >> think >> > this allows for all the flexibility we need without changing the model. >> I >> > care less about what exactly the atomicity of the per DAG perms should >> look >> > like. As far as I'm concerned, per-DAG read and write is probably >> granular >> > enough >> > >> > Also note that: >> > * we need an "_all_dags" logical DAG, meaning we'd have extra >> > permission_views "_all_dags - dag_view", "_all_dags - dag_run", >> "all_dags - >> > dag_clear" >> > * we probably want to derive FAB's SecurityManger and have an >> > AirflowSecurityManager that has an extra method "can_dag_action(user, >> > dag_id, action)". The SecurityManger class is neat because people can >> > provide their own if they want and override methods. That means that you >> > can defer any of the security-related checks to another system if you >> want >> > to. Many companies have some sort of company RBAC system and that can be >> > used to integrate with it. >> > >> > Max >> > >> > >> > >> > On Fri, Mar 30, 2018 at 4:54 PM, Joy Gao <j...@wepay.com> wrote: >> > >> >> Hi all, >> >> >> >> I also agree that having view-only access to some dags while write >> access >> >> to other dags is useful, so I prefer option 2. Although option 2 is >> more >> >> difficult to manage, it is cleaner and more consistent with the current >> >> security model. (On the other hand, even though option 1 may be may be >> >> easier to manage, it might be trickier to implement: with one perm per >> >> dag, it breaks the existing FAB security model since the existing, more >> >> granular permissions will have to be grouped for each dag). >> >> >> >> What Brian suggested in the other thread makes sense to me... >> >> >> >> The current security model in FAB looks like the following: >> >> >> >> --- permissions >> >> user --- role --- permission_view ---| >> >> --- views >> >> >> >> FAB generates a few relationship tables to manage the mappings, one of >> >> them is *ab_permission_view_role*, which has all the >> >> role-to-permission_view mapping. We can add a dag_id column to this >> >> relationship that expresses dag-level granularity, so the security >> model >> >> becomes: >> >> >> >> --- >> >> permissions >> >> | >> >> user --- role --- dag_permission_view --- --- views >> >> | >> >> --- >> dags >> >> >> >> We can make the dag_id field an optional field in the relationship, and >> >> only lazily add new dag-level mappings for DAGs that specify 'access >> >> control'. This way we don't have to create new permissions or views. >> (We >> >> will still have to introduce new dag-level roles on top of the 5 >> generic >> >> roles (public/viewer/user/op/admin)). >> >> >> >> (I think this is similar to what Arthur suggested earlier, but not sure >> >> if I interpreted correctly). >> >> >> >> Joy >> >> >> >> On Thu, Mar 29, 2018 at 10:01 AM, Arthur Wiedmer < >> >> arthur.wied...@gmail.com> wrote: >> >> >> >>> (Creating a new thread) >> >>> >> >>> Hi Max, >> >>> >> >>> I was just wondering about this. There are definite use cases for >> people >> >>> having only view access to some DAGs, mostly for monitoring. I want >> to know >> >>> what the upstream DAGs are doing, but maybe I don't need clear/run >> access. >> >>> >> >>> I feel like the granular operation permissions will start to become >> >>> unwieldy fast. It grows as (# users * # DAGs * # operations) but with >> >>> hopefully a small constant factor in front: most people should only >> have a >> >>> small number of DAGs they care about. The Ops team has a need to have >> >>> access to all on the other hand. >> >>> >> >>> I was wondering we could get by with something slightly more complex >> but >> >>> easier on the size of that permissions table : >> >>> 1) One toggle on the user level for broad access (ALL:ALL, >> >>> RUN/CLEAR:ALL, VIEW:ALL) default NULL >> >>> 2) More granular permissions at the DAG level. >> >>> >> >>> So in order, check the user's broad level permission first, then DAG >> >>> level. For large amounts of DAGs, this should help shave a little bit >> from >> >>> that table. >> >>> >> >>> Best, >> >>> Arthur >> >>> >> >>> >> >>> On Thu, Mar 29, 2018 at 8:27 AM, Maxime Beauchemin < >> >>> maximebeauche...@gmail.com> wrote: >> >>> >> >>>> Hijacking the thread further here, any thoughts on how to breakdown >> per >> >>>> DAG >> >>>> access? >> >>>> >> >>>> Tao & I are talking about introducing per-DAG permissions and one big >> >>>> question is whether we'll need to support different operation-types >> at a >> >>>> per-DAG level, which changes the way we need to model the perms. >> >>>> >> >>>> First [simpler] option is to introduce one perm per DAG. If you have >> >>>> access >> >>>> to 5 DAGs, and you have `can_clear` and `can_run`, you'll have >> >>>> homogenous >> >>>> rights on the DAGs you have access to. >> >>>> >> >>>> Second option is to have a breakdown per DAG. Meaning for each DAG we >> >>>> create a set of perms ({dag_id}_can_view, {dag_id}_can_modify, ...). >> So >> >>>> one >> >>>> user could have modify on some DAGs, view on others, and other DAGs >> >>>> would >> >>>> be invisible. This could be broken down further ({dag_id}_can_clear, >> >>>> ...) >> >>>> but it gets hard to manage. >> >>>> >> >>>> Thoughts? >> >>>> >> >>>> Max >> >>>> >> >>>> On Wed, Mar 28, 2018 at 10:02 PM, Tao Feng <fengta...@gmail.com> >> wrote: >> >>>> >> >>>> > Great work Joy. This is awesome! I am interested in helping out the >> >>>> per dag >> >>>> > level access. Just created a ticket to check(AIRFLOW-2267). Let me >> >>>> know if >> >>>> > you have any suggestions. I will share my proposal once I am ready. >> >>>> > >> >>>> > On Fri, Mar 23, 2018 at 6:45 PM, Joy Gao <j...@wepay.com> wrote: >> >>>> > >> >>>> > > Hey guys! >> >>>> > > >> >>>> > > The RBAC UI <https://github.com/apache/inc >> ubator-airflow/pull/3015> >> >>>> has >> >>>> > > been merged to master. I'm looking forward to early adopters' >> >>>> feedback >> >>>> > and >> >>>> > > bug reports. I also hope to have more folks helping out with the >> >>>> RBAC UI, >> >>>> > > especially with introducing DAG-Level access control, which is a >> >>>> feature >> >>>> > > that a lot of people have been asking. If you are interested in >> >>>> helping >> >>>> > out >> >>>> > > with this effort, let's talk more! >> >>>> > > >> >>>> > > This commit will be in the 1.10.0 release, and we are going to >> >>>> maintain >> >>>> > > both UIs simultaneously for a short period of time. Once RBAC UI >> is >> >>>> > stable >> >>>> > > and battle-tested, we will deprecate the old UI and eventually >> >>>> remove it >> >>>> > > from the repo (around Airflow 2.0.0 or 2.1.0 release). This is to >> >>>> prevent >> >>>> > > two UIs from forking into separate paths, as that would become >> very >> >>>> > > difficult to maintain. >> >>>> > > >> >>>> > > Going forward while both UIs are up, if you are making a change >> to >> >>>> any >> >>>> > > files in airflow/www/ (old UI), where applicable, please also >> make >> >>>> the >> >>>> > > change to the airflow/www_rbac/ (new UI). If you rather not make >> >>>> changes >> >>>> > in >> >>>> > > both UIs, it is recommended that you only make the changes to the >> >>>> RBAC >> >>>> > UI, >> >>>> > > since that is the one we are maintaining in the long term. >> >>>> > > >> >>>> > > I'm excited that the RBAC UI will be able to bring additional >> >>>> security to >> >>>> > > Airflow, and with FAB framework in place we can look into >> >>>> leveraging it >> >>>> > for >> >>>> > > a unified set of APIs used by both UI and CLI. >> >>>> > > >> >>>> > > Joy >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > On Thu, Feb 8, 2018 at 11:31 AM, Joy Gao <j...@wepay.com> wrote: >> >>>> > > >> >>>> > > > Hi folks, >> >>>> > > > >> >>>> > > > I have a PR <https://github.com/apache/ >> >>>> incubator-airflow/pull/3015> >> >>>> > out >> >>>> > > > for the new UI. I've included instructions on how to test it >> out >> >>>> in the >> >>>> > > PR >> >>>> > > > description. Looking forward to your feedbacks. >> >>>> > > > >> >>>> > > > Cheers, >> >>>> > > > Joy >> >>>> > > > >> >>>> > > > On Fri, Dec 1, 2017 at 6:18 PM, Joy Gao <j...@wepay.com> >> wrote: >> >>>> > > > >> >>>> > > >> Thanks for the background info. Would be really awesome for >> you >> >>>> to >> >>>> > have >> >>>> > > >> PyPi access :D I'll make the change to have Airflow >> Webserver's >> >>>> FAB >> >>>> > > >> dependency pointing to my fork for the mean time. >> >>>> > > >> >> >>>> > > >> For folks who are interested in RBAC, I will be giving a >> >>>> talk/demo at >> >>>> > > the Airflow >> >>>> > > >> Meet-Up >> >>>> > > >> <https://www.meetup.com/Bay-Area-Apache-Airflow-Incubating- >> >>>> > > Meetup/events/244525050/> >> >>>> > > >> next Monday. Happy to chat afterwards about it as well :) >> >>>> > > >> >> >>>> > > >> On Thu, Nov 30, 2017 at 8:36 AM, Maxime Beauchemin < >> >>>> > > >> maximebeauche...@gmail.com> wrote: >> >>>> > > >> >> >>>> > > >>> A bit of related history here: >> >>>> > > >>> https://github.com/dpgaspar/Flask-AppBuilder/issues/399 >> >>>> > > >>> >> >>>> > > >>> On Thu, Nov 30, 2017 at 8:33 AM, Maxime Beauchemin < >> >>>> > > >>> maximebeauche...@gmail.com> wrote: >> >>>> > > >>> >> >>>> > > >>> > Given I have merge rights on FAB I could probably do >> another >> >>>> round >> >>>> > of >> >>>> > > >>> > review and get your PRs through. I would really like to get >> >>>> the >> >>>> > main >> >>>> > > >>> > maintainer's input on things that touch the core >> >>>> (composite-key >> >>>> > > >>> support) as >> >>>> > > >>> > he might have concerns/intuitions that we can't know about. >> >>>> > > >>> > >> >>>> > > >>> > I do not have Pypi access though so I cannot push new >> releases >> >>>> > out. I >> >>>> > > >>> > could ask for that. >> >>>> > > >>> > >> >>>> > > >>> > I've threatened to fork the project before, that's always >> an >> >>>> > option. >> >>>> > > >>> I've >> >>>> > > >>> > noticed his involvement is sporadic and comes in bursts. >> >>>> > > >>> > >> >>>> > > >>> > In the meantime, you can have the dependency in Airflow >> >>>> Webserver >> >>>> > > >>> pointing >> >>>> > > >>> > straight to your fork. >> >>>> > > >>> > >> >>>> > > >>> > Max >> >>>> > > >>> > >> >>>> > > >>> > On Wed, Nov 29, 2017 at 7:02 PM, Joy Gao <j...@wepay.com> >> >>>> wrote: >> >>>> > > >>> > >> >>>> > > >>> >> I just created a new webserver instance if you haven't >> >>>> gotten a >> >>>> > > >>> chance to >> >>>> > > >>> >> fiddle around with the new web UI and the RBAC >> configurations >> >>>> > > (thanks >> >>>> > > >>> >> Maxime for getting started with this earlier!): >> >>>> > > >>> >> >> >>>> > > >>> >> http://104.209.38.171:8080/ >> >>>> > > >>> >> >> >>>> > > >>> >> Admin Account >> >>>> > > >>> >> username: admin >> >>>> > > >>> >> password: admin >> >>>> > > >>> >> >> >>>> > > >>> >> Read-Only Account >> >>>> > > >>> >> username: viewer >> >>>> > > >>> >> password: password >> >>>> > > >>> >> >> >>>> > > >>> >> >> >>>> > > >>> >> On Wed, Nov 29, 2017 at 2:58 PM, Joy Gao <j...@wepay.com> >> >>>> wrote: >> >>>> > > >>> >> >> >>>> > > >>> >> > Hi folks, >> >>>> > > >>> >> > >> >>>> > > >>> >> > Thanks for all the feedback regarding to the new Airflow >> >>>> > Webserver >> >>>> > > >>> UI >> >>>> > > >>> >> > <https://github.com/wepay/airflow-webserver/>! I've >> been >> >>>> > actively >> >>>> > > >>> >> > addressing all the bugs that were raised on Github. So I >> >>>> want to >> >>>> > > >>> take >> >>>> > > >>> >> this >> >>>> > > >>> >> > opportunity to discuss two issues coming up: >> >>>> > > >>> >> > >> >>>> > > >>> >> > The first issue is unaddressed PRs in FAB. If these PRs >> >>>> continue >> >>>> > > to >> >>>> > > >>> stay >> >>>> > > >>> >> > unaddressed, RBAC is blocked from making further >> progress. >> >>>> If >> >>>> > this >> >>>> > > >>> >> continue >> >>>> > > >>> >> > to be an issue, I'm inclined to fork FAB, even though >> it's >> >>>> not >> >>>> > > >>> >> idealistic. >> >>>> > > >>> >> > >> >>>> > > >>> >> > >> >>>> > > >>> >> > - PR/631 <https://github.com/dpgaspar/F >> >>>> > > lask-AppBuilder/pull/631> >> >>>> > > >>> >> Binary >> >>>> > > >>> >> > column support (merged, unreleased) >> >>>> > > >>> >> > <https://github.com/dpgaspar/F >> lask-AppBuilder/pull/631> >> >>>> > > >>> >> > - PR/639 <https://github.com/dpgaspar/F >> >>>> > > lask-AppBuilder/pull/639> >> >>>> > > >>> >> Composite >> >>>> > > >>> >> > primary key support (unmerged) >> >>>> > > >>> >> > - PR/655 <https://github.com/dpgaspar/F >> >>>> > > lask-AppBuilder/pull/655> >> >>>> > > >>> >> Form >> >>>> > > >>> >> > prefill support (unmerged) >> >>>> > > >>> >> > >> >>>> > > >>> >> > >> >>>> > > >>> >> > The second issue is an open question about the next >> step of >> >>>> > > Airflow >> >>>> > > >>> >> > Webserver itself. Here are the 3 potential directions we >> >>>> could >> >>>> > > >>> take, and >> >>>> > > >>> >> > I've added my thought on each. >> >>>> > > >>> >> > >> >>>> > > >>> >> > 1. Permanently keep Airflow Webserver as a separated >> >>>> package >> >>>> > from >> >>>> > > >>> >> Airflow, >> >>>> > > >>> >> > and treat it as another UI option. Keep `www` in >> Airflow. >> >>>> Allow >> >>>> > > >>> >> development >> >>>> > > >>> >> > on both UIs. >> >>>> > > >>> >> > *I'm not a fan of this. When there is an existing UI in >> >>>> Airflow, >> >>>> > > >>> most >> >>>> > > >>> >> > contributors would prefer to maintain the official >> version >> >>>> that >> >>>> > is >> >>>> > > >>> >> > installed out-of-the-box. **Having a second UI outside >> of >> >>>> > Airflow >> >>>> > > >>> will >> >>>> > > >>> >> > make maintaining it very difficult, leading to an >> eventual >> >>>> death >> >>>> > > of >> >>>> > > >>> the >> >>>> > > >>> >> new >> >>>> > > >>> >> > UI :(* >> >>>> > > >>> >> > >> >>>> > > >>> >> > 2. Permanently keep Airflow Webserver as a separated >> >>>> package >> >>>> > from >> >>>> > > >>> >> Airflow, >> >>>> > > >>> >> > but freeze all development on `www` and direct all >> future >> >>>> UI >> >>>> > > >>> >> development >> >>>> > > >>> >> > to Airflow Webserver, eventually removing `www` >> completely >> >>>> when >> >>>> > > >>> Airflow >> >>>> > > >>> >> > Webserver is stable. >> >>>> > > >>> >> > *I'm not a fan of this either. First of all, the views >> and >> >>>> > models >> >>>> > > >>> are >> >>>> > > >>> >> > tightly coupled in both old and new UI; until we have a >> >>>> > > full-fledged >> >>>> > > >>> >> REST >> >>>> > > >>> >> > API to build the UI (and cli) on top of it, separating >> >>>> them to a >> >>>> > > >>> >> separate >> >>>> > > >>> >> > package now will potentially cause dependency issues and >> >>>> add >> >>>> > > >>> >> complication >> >>>> > > >>> >> > to our release cycle. **Secondly, **majority of Airflow >> >>>> users >> >>>> > run >> >>>> > > >>> >> Airflow >> >>>> > > >>> >> > with the UI; it's one of Airflow's best features. >> >>>> Separating UI >> >>>> > > out >> >>>> > > >>> of >> >>>> > > >>> >> > Airflow core will complicate setup and configuration, >> while >> >>>> > making >> >>>> > > >>> >> Airflow >> >>>> > > >>> >> > core less complete.* >> >>>> > > >>> >> > >> >>>> > > >>> >> > 3. Merge Airflow Webserver back into Airflow as `www2`, >> >>>> freeze >> >>>> > all >> >>>> > > >>> >> > development on `www`, eventually removing `www` >> completely >> >>>> when >> >>>> > > >>> `www2` >> >>>> > > >>> >> is >> >>>> > > >>> >> > stable. >> >>>> > > >>> >> > *This makes the most sense to me. Airflow Webserver is >> >>>> developed >> >>>> > > >>> with >> >>>> > > >>> >> the >> >>>> > > >>> >> > goal of feature parity to the current UI, plus >> additional >> >>>> RBAC >> >>>> > > >>> >> capability, >> >>>> > > >>> >> > in hope to replace the old UI completely. Yes, this >> means >> >>>> there >> >>>> > > >>> will be >> >>>> > > >>> >> a >> >>>> > > >>> >> > short period of having to maintain two UIs, but once we >> >>>> freeze >> >>>> > > >>> >> development >> >>>> > > >>> >> > on www, it shouldn't be a concern for long.* >> >>>> > > >>> >> > >> >>>> > > >>> >> > I'd love to hear everyone's thoughts on this! I'm >> excited >> >>>> about >> >>>> > > >>> bringing >> >>>> > > >>> >> > RBAC to airflow and I hope it's something others will >> find >> >>>> > useful >> >>>> > > as >> >>>> > > >>> >> well! >> >>>> > > >>> >> > >> >>>> > > >>> >> > Cheers, >> >>>> > > >>> >> > Joy >> >>>> > > >>> >> > >> >>>> > > >>> >> > On Mon, Nov 20, 2017 at 11:24 AM, Joy Gao < >> j...@wepay.com> >> >>>> > wrote: >> >>>> > > >>> >> > >> >>>> > > >>> >> >> Thank you everyone for the active feedback so far, and >> >>>> thanks >> >>>> > for >> >>>> > > >>> >> setting >> >>>> > > >>> >> >> up the demo Maxime! >> >>>> > > >>> >> >> >> >>>> > > >>> >> >> Going to work on pruning through the issues in the >> >>>> upcoming >> >>>> > days. >> >>>> > > >>> >> >> >> >>>> > > >>> >> >> Fokko/Maxime, do you recall the SQLAlchemy Exception >> >>>> message >> >>>> > so I >> >>>> > > >>> can >> >>>> > > >>> >> >> look into it? Otherwise I'll wait until it's down >> again =P >> >>>> > > >>> >> >> >> >>>> > > >>> >> >> Cheers, >> >>>> > > >>> >> >> >> >>>> > > >>> >> >> Joy >> >>>> > > >>> >> >> >> >>>> > > >>> >> >> On Mon, Nov 20, 2017 at 9:35 AM, Maxime Beauchemin < >> >>>> > > >>> >> >> maximebeauche...@gmail.com> wrote: >> >>>> > > >>> >> >> >> >>>> > > >>> >> >>> I just restarted it, not sure how long it will take to >> >>>> get in >> >>>> > a >> >>>> > > >>> bad >> >>>> > > >>> >> state >> >>>> > > >>> >> >>> again... >> >>>> > > >>> >> >>> >> >>>> > > >>> >> >>> Max >> >>>> > > >>> >> >>> >> >>>> > > >>> >> >>> On Sun, Nov 19, 2017 at 11:55 PM, Driesprong, Fokko >> >>>> > > >>> >> <fo...@driesprong.frl >> >>>> > > >>> >> >>> > >> >>>> > > >>> >> >>> wrote: >> >>>> > > >>> >> >>> >> >>>> > > >>> >> >>> > Good morning, >> >>>> > > >>> >> >>> > >> >>>> > > >>> >> >>> > The demo provided by Max is down, it throws a >> >>>> > > >>> SQLAlchemyexception >> >>>> > > >>> >> :'( >> >>>> > > >>> >> >>> > >> >>>> > > >>> >> >>> > Cheers, Fokko >> >>>> > > >>> >> >>> > >> >>>> > > >>> >> >>> > 2017-11-18 19:14 GMT+01:00 Chris Riccomini < >> >>>> > > >>> criccom...@apache.org>: >> >>>> > > >>> >> >>> > >> >>>> > > >>> >> >>> > > @bolke, open issues on the Github repo, please. >> >>>> > > >>> >> >>> > > >> >>>> > > >>> >> >>> > > On Sat, Nov 18, 2017 at 10:13 AM, Bolke de Bruin < >> >>>> > > >>> >> bdbr...@gmail.com> >> >>>> > > >>> >> >>> > > wrote: >> >>>> > > >>> >> >>> > > >> >>>> > > >>> >> >>> > > > Chris, >> >>>> > > >>> >> >>> > > > >> >>>> > > >>> >> >>> > > > Do you want us to report bugs somewhere (I have >> >>>> > > encountered >> >>>> > > >>> a >> >>>> > > >>> >> >>> few)? Or >> >>>> > > >>> >> >>> > > > just generic user experiences posted here? >> >>>> > > >>> >> >>> > > > >> >>>> > > >>> >> >>> > > > Cheers >> >>>> > > >>> >> >>> > > > Bolke >> >>>> > > >>> >> >>> > > > >> >>>> > > >>> >> >>> > > > > On 18 Nov 2017, at 00:47, Chris Riccomini < >> >>>> > > >>> >> criccom...@apache.org >> >>>> > > >>> >> >>> > >> >>>> > > >>> >> >>> > > wrote: >> >>>> > > >>> >> >>> > > > > >> >>>> > > >>> >> >>> > > > > Hey all, >> >>>> > > >>> >> >>> > > > > >> >>>> > > >>> >> >>> > > > > I know the weekend is coming up, and for those >> >>>> of us >> >>>> > in >> >>>> > > >>> the >> >>>> > > >>> >> US, >> >>>> > > >>> >> >>> next >> >>>> > > >>> >> >>> > > week >> >>>> > > >>> >> >>> > > > > is a bit of a slow holiday week. Would love to >> >>>> get >> >>>> > some >> >>>> > > >>> >> feedback >> >>>> > > >>> >> >>> from >> >>>> > > >>> >> >>> > > > > everyone on this. The goal would ideally to >> be to >> >>>> > > >>> converge on >> >>>> > > >>> >> >>> this >> >>>> > > >>> >> >>> > and >> >>>> > > >>> >> >>> > > > > eventually replace the existing Airflow UI >> with >> >>>> this >> >>>> > > one. >> >>>> > > >>> >> >>> > > > > >> >>>> > > >>> >> >>> > > > > Cheers, >> >>>> > > >>> >> >>> > > > > Chris >> >>>> > > >>> >> >>> > > > > >> >>>> > > >>> >> >>> > > > > On Fri, Nov 17, 2017 at 1:44 PM, Joy Gao < >> >>>> > > j...@wepay.com> >> >>>> > > >>> >> wrote: >> >>>> > > >>> >> >>> > > > > >> >>>> > > >>> >> >>> > > > >> Hi guys. >> >>>> > > >>> >> >>> > > > >> >> >>>> > > >>> >> >>> > > > >> I've been working on moving airflow from >> >>>> Flask-Admin >> >>>> > to >> >>>> > > >>> >> >>> > > Flask-AppBuilder >> >>>> > > >>> >> >>> > > > >> for RBAC >> >>>> > > >>> >> >>> > > > >> <https://cwiki.apache.org/ >> >>>> > confluence/display/AIRFLOW/ >> >>>> > > >>> >> >>> > > > Airflow+RBAC+proposal >> >>>> > > >>> >> >>> > > > >>> , >> >>>> > > >>> >> >>> > > > >> check it out at >> https://github.com/wepay/airfl >> >>>> > > >>> ow-webserver. >> >>>> > > >>> >> >>> > > > >> >> >>>> > > >>> >> >>> > > > >> It's still a work-in-progress, but most >> >>>> features you >> >>>> > > see >> >>>> > > >>> in >> >>>> > > >>> >> the >> >>>> > > >>> >> >>> > > > webserver >> >>>> > > >>> >> >>> > > > >> UI today is available there. For those who >> are >> >>>> > > >>> interested in >> >>>> > > >>> >> >>> RBAC, >> >>>> > > >>> >> >>> > I'd >> >>>> > > >>> >> >>> > > > love >> >>>> > > >>> >> >>> > > > >> to get some early feedback in terms of the >> >>>> following: >> >>>> > > >>> >> >>> > > > >> >> >>>> > > >>> >> >>> > > > >> - New Flask-AppBuilder UI (any >> bugs/regressions) >> >>>> > > >>> >> >>> > > > >> - Setup issues >> >>>> > > >>> >> >>> > > > >> - Ease of integration with third party auth >> >>>> (i.e. >> >>>> > LDAP, >> >>>> > > >>> AD, >> >>>> > > >>> >> >>> OAuth, >> >>>> > > >>> >> >>> > > etc.) >> >>>> > > >>> >> >>> > > > >> - Any other thoughts/concerns >> >>>> > > >>> >> >>> > > > >> >> >>>> > > >>> >> >>> > > > >> Thanks a lot! >> >>>> > > >>> >> >>> > > > >> >> >>>> > > >>> >> >>> > > > >> Cheers, >> >>>> > > >>> >> >>> > > > >> Joy >> >>>> > > >>> >> >>> > > > >> >> >>>> > > >>> >> >>> > > > >> >>>> > > >>> >> >>> > > > >> >>>> > > >>> >> >>> > > >> >>>> > > >>> >> >>> > >> >>>> > > >>> >> >>> >> >>>> > > >>> >> >> >> >>>> > > >>> >> >> >> >>>> > > >>> >> > >> >>>> > > >>> >> >> >>>> > > >>> > >> >>>> > > >>> > >> >>>> > > >>> >> >>>> > > >> >> >>>> > > >> >> >>>> > > > >> >>>> > > >> >>>> > >> >>>> >> >>> >> >>> >> >> >> > >> > >
