[ 
https://issues.apache.org/jira/browse/HDDS-1927?focusedWorklogId=297593&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-297593
 ]

ASF GitHub Bot logged work on HDDS-1927:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 20/Aug/19 03:43
            Start Date: 20/Aug/19 03:43
    Worklog Time Spent: 10m 
      Work Description: xiaoyuyao commented on pull request #1263: HDDS-1927. 
Consolidate add/remove Acl into OzoneAclUtil class. Contri…
URL: https://github.com/apache/hadoop/pull/1263#discussion_r315495833
 
 

 ##########
 File path: 
hadoop-ozone/common/src/main/java/org/apache/hadoop/ozone/om/helpers/OmKeyInfo.java
 ##########
 @@ -235,123 +231,22 @@ public FileEncryptionInfo getFileEncryptionInfo() {
     return encInfo;
   }
 
-  public List<OzoneAclInfo> getAcls() {
+  public List<OzoneAcl> getAcls() {
 
 Review comment:
   bq. Raw protobuf class can't be extended easily for acl operations. We will 
have to to wrap the acl operations anyway.
   
   This is based on [protobuf 
doc](https://developers.google.com/protocol-buffers/docs/javatutorial) below. 
My understanding is that protobuf is only good for serialization/transport. Our 
acl operation specific logic should be wrapped without dependency on it so that 
it can be maintained easily for the long term.  
    
   "Protocol buffer classes are basically dumb data holders (like structs in 
C); they don't make good first class citizens in an object model. If you want 
to add richer behavior to a generated class, the best way to do this is to wrap 
the generated protocol buffer class in an application-specific class."
   
   bq. And also this will not only help acls But bucket/key creation also, as 
now Bucket/KeyInfo will have proto buf -> internal Ozone object. This also can 
be avoided. (So, when each key creation we don't need to convert acls set 
during the creation of key from proto to OzoneAcl Objects.)
   
   This requires a broader change in the interface itself, which is beyond the 
scope of this JIRA, i.e. consolidate the core acl ops.
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 297593)
    Time Spent: 4h 20m  (was: 4h 10m)

> Consolidate add/remove Acl into OzoneAclUtil class
> --------------------------------------------------
>
>                 Key: HDDS-1927
>                 URL: https://issues.apache.org/jira/browse/HDDS-1927
>             Project: Hadoop Distributed Data Store
>          Issue Type: Bug
>            Reporter: Bharat Viswanadham
>            Assignee: Xiaoyu Yao
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> This Jira is created based on @xiaoyu comment on HDDS-1884
> Can we abstract these add/remove logic into common AclUtil class as we can 
> see similar logic in both bucket manager and key manager? For example,
> public static boolean addAcl(List existingAcls, OzoneAcl newAcl)
> public static boolean removeAcl(List existingAcls, OzoneAcl newAcl)
>  
> But to do this, we need both OmKeyInfo and OMBucketInfo to use list of 
> OzoneAcl/OzoneAclInfo.
> This Jira is to do that refactor, and also address above comment to move 
> common logic to AclUtils.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to