[ https://issues.apache.org/jira/browse/HDFS-11991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16056397#comment-16056397 ]
Anu Engineer edited comment on HDFS-11991 at 6/20/17 8:26 PM: -------------------------------------------------------------- [~cheersyang] Let us talk when you are back from vacation. There is a class of problems where reading information from the server leads to better decision on the client side. 1. Automatic Datanode Discovery - Problem: If we have a large cluster with many datanodes, the clients should be able to discover the various end-points that it can talk to, instead of talking to the same datanode all the time. This can be based on load or the block location. - Possible solutions : Rely on DNS to send this list of Datanodes, Virtual IP or the simplest one -- have KSM/SCM support an list of Datanodes and also support GetBlockLocation API over rest. 2. Discovery of Configs - Problem : There are times when a client can work more efficiently if it has access to the ozone-site.xml or the hadoop configs. - Solution : Support an API that returns configs -- There is an issue of security that we have solve though( avoiding man in the middle attacks) 3. Discovery of the Root user. - Problem : It is useful to know the name of the root user and group - Solution : Have an API return that from KSM/SCM. We might decide to build a discover API to get all these kinds of information from KSM/SCM. It will make it easy for the client to make more server friendly decision if we do that. In this specific case the discover API will start with the root user name. bq. OzoneConfigKeys#OZONE_ADMINISTRATORS to get a list of administrators When we use REST protocol we might not have access to config file, if we decide to do it this way, then get config over rest might be a good idea. was (Author: anu): [~cheersyang] Let us talk when you are back from vacation. There is a class of problems where reading information from the server leads to better decision on the client side. 1. Automatic Datanode Discovery - Problem: If we have a large cluster with many datanodes, the clients should be able to discover the various end-points that it can talk to, instead of talking to the same datanode all the time. This can be based on load or the block location. - Possible solutions : Rely on DNS to send this list of Datanodes, Virtual IP or the simplest one -- have KSM/SCM support an list of Datanodes and also support GetBlockLocation API over rest. 2. Discovery of Configs - Problem : There are times when a client can work more efficiently if it has access to the ozone-site.xml or the hadoop configs. - Solution : Support an API that returns configs -- There is an issue of security that we have solve though( avoiding man in the middle attacks) 3. Discovery of the Root user. - Problem : It is useful to know the name of the root user and group - Solution : Have an API return that from KSM/SCM. We might decide to build a discover API to get all these kinds of information from KSM/SCM. It will make it easy for the client to make more server friendly decision if we do that. In this specific case the discover API will start with the root user name. > Ozone: Ozone shell: the root is assumed to hdfs > ----------------------------------------------- > > Key: HDFS-11991 > URL: https://issues.apache.org/jira/browse/HDFS-11991 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ozone > Reporter: Anu Engineer > Assignee: Weiwei Yang > Fix For: HDFS-7240 > > > *hdfs oz* command, or ozone shell has a command like option to run some > commands as root easily by specifying _--root_ as a command line option. > But after HDFS-11655 that assumption is no longer true. We need to detect the > user that started the scm/ksm service and _root_ should be mapped to that > user. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org