[ 
https://issues.apache.org/jira/browse/HDDS-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prashant Pogde updated HDDS-2390:
---------------------------------
    Target Version/s: 1.2.0

I am managing the 1.1.0 release and we currently have more than 600 issues 
targeted for 1.1.0. I am moving the target field to 1.2.0. 

If you are actively working on this jira and believe this should be targeted to 
1.1.0 release, Please change the target field back to 1.1.0 before Feb 05, 
2021. 

> SCMSecurityClient and mixing of abstraction layers
> --------------------------------------------------
>
>                 Key: HDDS-2390
>                 URL: https://issues.apache.org/jira/browse/HDDS-2390
>             Project: Hadoop Distributed Data Store
>          Issue Type: Improvement
>            Reporter: István Fajth
>            Assignee: István Fajth
>            Priority: Major
>
> During the work on HDDS-2362, I ran into a bigger topic with Security and how 
> the code is organized around internal certificate handling.
> What I see is that we have two methods, HDDSUtils.getScmSecurityClient, and 
> HDDSClientUtils.getSCMSecurityClient, which are essentially doing the same, 
> the latter one without infinite retries, but used only from one test class, 
> besides this DefaultCertificateClient replicates the same logic also.
> Further evaluating the first one in HDDSUtils, I see that it is being used at 
> 3 places, ContainerOperationClient, HddsDataNodeService, and OzoneManager, 
> both of the two has its own DefaultCertificateClient descendants as well.
> ContainerOperationClient is using the client to get the CA certificate.
> HddsDataNodeService is using it to have a signed certificate for the DataNode.
> OzoneManager uses it for the same purpose to get a signed certificate.
> In the HddsDataNodeService, and OzoneManager class with this we effectively 
> tinkering with protobuf requests and responses, and protobuf related code, 
> which seems to be pretty high for the communication layer to buble up to.
> Based on the above, I would propose to have this logic encapsulated in a 
> client class that handles all the protobuf related things below 
> DefaultCertificateClient, and let all the code that is depending on 
> SCMSecurityProtocolClientSideTranslatorPB to depend on this new class or the 
> already exsisting DefaultCertificateClient methods and its descendants.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to