[
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:21 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.
# 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.
# 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)
# 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.
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.
# 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.
# 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)
# 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: [email protected]
For additional commands, e-mail: [email protected]
