You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by Abhay Kulkarni <ak...@hortonworks.com> on 2021/09/17 21:45:25 UTC
Review Request 73588: RANGER-3419: compressDeltas method returns two
ranger
policy entries for policy create+update case when provided lastKnownVersion
is previous to create call
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73588/
-----------------------------------------------------------
Review request for ranger and Ramesh Mani.
Bugs: RANGER-3419
https://issues.apache.org/jira/browse/RANGER-3419
Repository: ranger
Description
-------
Problem Statement: compressDeltas method returns two ranger policy entries for policy create+update case when provided lastKnownVersion is previous to create policy operation. As per the design it should return only one last updated entry for the policy even if multiple update policy request is made after the create policy request.
Steps to reproduce:
1) call the policy download api and note the policy lastKnownVersion.
2) call create policy api
3) call update policy api for the policy created in step 2 above.
4) call the policy download api and provide the policy lastKnownVersion noted in step 1 above.
Proposed Solution:
At line 3013, we have already added the policy so in case of create+update operation first entry alone can be considered and all next update event can be skipped.
since x_policy table stores only latest entry of a policy, during delta calculation for both the change type(create/update) same policy text is fetched, hence received policy snapshot is same and there is no point of having two entries.
Diffs
-----
security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java a50a1f645
Diff: https://reviews.apache.org/r/73588/diff/1/
Testing
-------
Tested the patch for create+update sequence and tried various other combination also for create/update/delete policy call and now policy download api is returning results as per the design.
Passed all unit tests
Thanks,
Abhay Kulkarni
Re: Review Request 73588: RANGER-3419: compressDeltas method returns
two ranger policy entries for policy create+update case when provided
lastKnownVersion is previous to create call
Posted by Ramesh Mani <rm...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73588/#review223496
-----------------------------------------------------------
Ship it!
Ship It!
- Ramesh Mani
On Sept. 17, 2021, 9:45 p.m., Abhay Kulkarni wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73588/
> -----------------------------------------------------------
>
> (Updated Sept. 17, 2021, 9:45 p.m.)
>
>
> Review request for ranger and Ramesh Mani.
>
>
> Bugs: RANGER-3419
> https://issues.apache.org/jira/browse/RANGER-3419
>
>
> Repository: ranger
>
>
> Description
> -------
>
> Problem Statement: compressDeltas method returns two ranger policy entries for policy create+update case when provided lastKnownVersion is previous to create policy operation. As per the design it should return only one last updated entry for the policy even if multiple update policy request is made after the create policy request.
>
>
> Steps to reproduce:
> 1) call the policy download api and note the policy lastKnownVersion.
> 2) call create policy api
> 3) call update policy api for the policy created in step 2 above.
> 4) call the policy download api and provide the policy lastKnownVersion noted in step 1 above.
>
>
> Proposed Solution:
> At line 3013, we have already added the policy so in case of create+update operation first entry alone can be considered and all next update event can be skipped.
> since x_policy table stores only latest entry of a policy, during delta calculation for both the change type(create/update) same policy text is fetched, hence received policy snapshot is same and there is no point of having two entries.
>
>
> Diffs
> -----
>
> security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java a50a1f645
>
>
> Diff: https://reviews.apache.org/r/73588/diff/1/
>
>
> Testing
> -------
>
> Tested the patch for create+update sequence and tried various other combination also for create/update/delete policy call and now policy download api is returning results as per the design.
>
> Passed all unit tests
>
>
> Thanks,
>
> Abhay Kulkarni
>
>