You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2020/01/15 15:50:00 UTC
[jira] [Commented] (KNOX-2160) Introduce a Hadoop XML type
descriptor format
[ https://issues.apache.org/jira/browse/KNOX-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016103#comment-17016103 ]
ASF subversion and git services commented on KNOX-2160:
-------------------------------------------------------
Commit 56726b4f58b8ca96c7756f5b08eab52a28facc86 in knox's branch refs/heads/master from Sandor Molnar
[ https://gitbox.apache.org/repos/asf?p=knox.git;h=56726b4 ]
KNOX-2160 - Introducing Hadoop XML type descriptor format (#236)
> Introduce a Hadoop XML type descriptor format
> ---------------------------------------------
>
> Key: KNOX-2160
> URL: https://issues.apache.org/jira/browse/KNOX-2160
> Project: Apache Knox
> Issue Type: New Feature
> Components: Server
> Affects Versions: 1.1.0, 1.2.0, 1.3.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Major
> Fix For: 1.4.0
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> To support topology management in Cloudera Manager it'd be beneficial if Knox was able to process a descriptor that CM can generate natively. As of now, CM's CSD framework is capable of producing a file of its parameters in the following [formats|https://github.com/cloudera/cm_ext/wiki/Service-Descriptor-Language-Reference#configWriterFormat]:
> * Hadoop XML
> * properties
> * gflags
> As the {{gateway-site.xml}} is a Hadoop XML it's quite obvious that the first option is the one that fits the most.
> One XML type descriptor file may contain one or more Knox descriptors using the following structure:
> * the configuration name would indicate the descriptor (topology) name
> * the configuration value would list all properties of a Knox descriptor
> ** service discovery related information (type, address, cluster, user/password alias)
> ** services
> *** name
> *** url
> *** version (optional)
> *** parameters (optional)
> ** applications (optional)
> *** name
> *** parameters (optional)
> A sample descriptor file would look like this:
> {code:xml}
> <configuration>
> <property>
> <name>topology1</name>
> <value>
> discoveryType=ClouderaManager;
> discoveryAddress=http://host:123;
> discoveryUser=user;
> discoveryPasswordAlias=alias;
> cluster=Cluster 1;
> providerConfigRef=topology1-provider;
> app:knoxauth:param1.name=param1.value;
> app:KNOX;
> HIVE:url=http://localhost:389;
> HIVE:version=1.0;
> HIVE:httpclient.connectionTimeout=5m;
> HIVE:httpclient.socketTimeout=100m
> </value>
> </property>
> <property>
> <name>topology2</name>
> <value>
> discoveryType=ClouderaManager;
> discoveryAddress=http://host:123;
> discoveryUser=user;
> discoveryPasswordAlias=alias;
> cluster=Cluster 1;
> providerConfigRef=topology2-provider;
> app:KNOX;
> HDFS.url=https://localhost:443;
> HDFS:httpclient.connectionTimeout=5m;
> HDFS:httpclient.socketTimeout=100m
> </value>
> </property>
> </configuration>
> {code}
>
> Workflow:
> # this kind of descriptor should also be placed in Knox's descriptor directory
> # once it's added or modified Knox's existing descriptor monitor should parse the XML and build one or more instance sof {{org.apache.knox.gateway.topology.simple.SimpleDescriptor}}
> # after the Java object(s) got created it (they) should be saved in the Knox descriptor directory in JSON format. As a result, the same monitor should parse the new/modified JSON descriptor(s) and re-deploys it (them) using the already existing mechanism
--
This message was sent by Atlassian Jira
(v8.3.4#803005)