You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Jian He (JIRA)" <ji...@apache.org> on 2016/06/03 22:59:59 UTC
[jira] [Comment Edited] (YARN-4757) [Umbrella] Simplified discovery
of services via DNS mechanisms
[ https://issues.apache.org/jira/browse/YARN-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315054#comment-15315054 ]
Jian He edited comment on YARN-4757 at 6/3/16 10:59 PM:
--------------------------------------------------------
Hi [~jmaron], thanks for working on this. I went through the patch and have a few questions:
- Here, it’s using the ‘description’ filed for constructing the DNS name. is this expected ? seems not mentioned in the doc
{code}
protected Name getContainerName()
throws PathNotFoundException, TextParseException {
String service = RegistryPathUtils.lastPathEntry(
RegistryPathUtils.parentOf(RegistryPathUtils.parentOf(getPath())));
String description = getRecord().description.toLowerCase();
String user = getUsername(getPath());
return Name.fromString(MessageFormat.format("{0}.{1}.{2}.{3}",
description,
service,
user,
domain));
{code}
- we can close the CuratorService#treeCache when stop the service?
- only readLock is being used. wondering whether these locks are needed.
{code}
private ReentrantReadWriteLock zoneLock = new ReentrantReadWriteLock();
private CloseableLock readLock = new CloseableLock(zoneLock.readLock());
private CloseableLock writeLock = new CloseableLock(zoneLock.writeLock());
{code}
- question about the dnsEnabled config, if the dnsEnabled is false, what else does the RegistryDNSServer do ? Asking this because I'm wondering whether this config is actually needed.
- RecordCreatorFactory: The RecordCreatroFactory#getRecordCreator is instantiating the creator instance every time this method gets called. May be singleton pattern could be useful to avoid creating a new instance every time.
- DNSManagementOperations class is not used anywhere , can be removed?
- a few unused methods in RegistryDNS, e.g. addDSRecord, signZones. is this intended ?
- what does the RegistryDNS#primaryDNS do ?
was (Author: jianhe):
Hi [~jmaron], thanks for working on this. I went through the patch and have a few questions:
- Here, it’s using the ‘description’ filed for constructing the DNS name. is this expected ? seems not mentioned in the doc
{code}
protected Name getContainerName()
throws PathNotFoundException, TextParseException {
String service = RegistryPathUtils.lastPathEntry(
RegistryPathUtils.parentOf(RegistryPathUtils.parentOf(getPath())));
String description = getRecord().description.toLowerCase();
String user = getUsername(getPath());
return Name.fromString(MessageFormat.format("{0}.{1}.{2}.{3}",
description,
service,
user,
domain));
{code}
- we can close the CuratorService#treeCache when stop the service?
- only readLock is being used. wondering whether these locks are needed.
{code}
private ReentrantReadWriteLock zoneLock = new ReentrantReadWriteLock();
private CloseableLock readLock = new CloseableLock(zoneLock.readLock());
private CloseableLock writeLock = new CloseableLock(zoneLock.writeLock());
{code}
- question about the dnsEnabled config, if the dnsEnabled is false, what else does the RegistryDNSServer do ?
- RecordCreatorFactory: The RecordCreatroFactory#getRecordCreator is instantiating the creator instance every time this method gets called. May be singleton pattern could be useful to avoid creating a new instance every time.
- DNSManagementOperations class is not used anywhere , can be removed?
- a few unused methods in RegistryDNS, e.g. addDSRecord, signZones. is this intended ?
- what does the RegistryDNS#primaryDNS do ?
> [Umbrella] Simplified discovery of services via DNS mechanisms
> --------------------------------------------------------------
>
> Key: YARN-4757
> URL: https://issues.apache.org/jira/browse/YARN-4757
> Project: Hadoop YARN
> Issue Type: New Feature
> Reporter: Vinod Kumar Vavilapalli
> Assignee: Jonathan Maron
> Attachments: 0001-YARN-4757-Initial-code-submission-for-DNS-Service.patch, YARN-4757- Simplified discovery of services via DNS mechanisms.pdf, YARN-4757-YARN-4757.001.patch, YARN-4757-YARN-4757.002.patch, YARN-4757-YARN-4757.003.patch
>
>
> [See overview doc at YARN-4692, copying the sub-section (3.2.10.2) to track all related efforts.]
> In addition to completing the present story of service-registry (YARN-913), we also need to simplify the access to the registry entries. The existing read mechanisms of the YARN Service Registry are currently limited to a registry specific (java) API and a REST interface. In practice, this makes it very difficult for wiring up existing clients and services. For e.g, dynamic configuration of dependent endpoints of a service is not easy to implement using the present registry-read mechanisms, *without* code-changes to existing services.
> A good solution to this is to expose the registry information through a more generic and widely used discovery mechanism: DNS. Service Discovery via DNS uses the well-known DNS interfaces to browse the network for services. YARN-913 in fact talked about such a DNS based mechanism but left it as a future task. (Task) Having the registry information exposed via DNS simplifies the life of services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org