-1 (binding) for the moment, sorry. This is mostly because of the proposed permissions solution.
I am happy with the spec-first approach, and feel we can get there on the exact API methods, what IDs we expose or don't etc, but this permissions is a deal breaker for me as it stands. >From your last response I am still not sure 100% what you are proposing, and it feels like we are fighting against FAB rather than working with it. For example you say: > all we have to do is replace steps 4 and retrieve information from the > code, not the database. Do the permissions management screens in FAB still work -- i.e. can someone choose to give a user/role access to only a single API endpoint? If so how do we achieve that without having to re-write the Security screens from FAB. What is wrong with the FAB database approach that means we have to re-write or customize it's behavoiur? Yes our current permissions approach isn't great, but that is just how we've "chosen" to do it in Airflow, it's not a problem with the underlying permissions model. For example a different way of doing it: https://github.com/apache/airflow/pull/7251/files#diff-948e87b4f8f644b3ad8c7950958df033R2719-R2722 This added a (AJAX-style) method to DagModelView, and reuses the "can_list" permission to achive it - because the "action"/verb is about listing, it doesn't ever make sense to deny autocompletion if you can list. If I understand your proposal correctly, you are suggesting something like "can_edit_variable on APIView"? Why not "can_edit on Variable" (or VariableView), and then that one permission could apply to web UI and API. (Without the "on X" part I think a lot fo FAB won't work right.) So specific things I want to see addressed before I will +1 this. - How do we manage API permissions for custom roles? (i.e. do the existing screens work, how usable are they?) - What "ViewMenu" is the permission tied to? - What do these look like the Security screens? - How do we manage these API permissions on a per-DAG level? - Are we unifying the API permissions and the front end-permissions? I feel we are close on this AIP! Ash On Thu Mar 19, 2020 at 10:55 AM, Jarek Potiuk wrote: > +1 binding > > > On Thu, Mar 19, 2020 at 10:32 AM Tomasz Urbaszek < > tomasz.urbas...@polidea.com> wrote: > > > > +1 binding > > > > On Thu, Mar 19, 2020 at 10:29 AM Kamil Bregu=C5=82a <kamil.bregula@polide= > a.com> > > wrote: > > > > > Hello all, > > > > > > This email calls for a vote on the design proposed in AIP-32, found her= > e > > > > > > > > > > > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-32%3A+Airflow+RES= > T+API > > > > > > > > https://lists.apache.org/thread.html/r2a0d0fb3d4610432fa52148d7d9e59c7632= > dd8f2fa61a580430b814c%40%3Cdev.airflow.apache.org%3E > > > > > > A few notes: > > > > > > - The proposed in AIP is to use an the "Specs first" approach. > > > First, we make the change in the openapi.yaml file, and then > > > we change the code. > > > - This AIP allows for high granulation. Many people can work on > > > smaller independent tasks. Already the application from Outreachy > > > internships asked me how they can work on this AIP. > > > - Details of the API structure may still change until the first version > > > is released. > > > > > > This vote will last for 72 hours until 2020-03-22T10:30Z, and until at > > > least 3 votes have been cast. > > > > > > > > > > > https://www.timeanddate.com/worldclock/fixedtime.html?iso=3D20200322T1030= > &p1=3D262 > > > > > > This is my +1 vote. > > > > > > Thanks, > > > Kamil > > > > > > > > > -- > > > > Tomasz Urbaszek > > Polidea <https://www.polidea.com/> | Software Engineer > > > > M: +48 505 628 493 <+48505628493> > > E: tomasz.urbas...@polidea.com <tomasz.urbasz...@polidea.com> > > > > Unique Tech > > Check out our projects! <https://www.polidea.com/our-work> > > > > > > > --=20 > > > Jarek Potiuk > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > M: +48 660 796 129 <+48660796129> > [image: Polidea] <https://www.polidea.com/> > > > >
