[ 
https://issues.apache.org/jira/browse/KNOX-2160?focusedWorklogId=371532&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-371532
 ]

ASF GitHub Bot logged work on KNOX-2160:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 14/Jan/20 11:05
            Start Date: 14/Jan/20 11:05
    Worklog Time Spent: 10m 
      Work Description: smolnar82 commented on pull request #236: KNOX-2160 - 
Introducing Hadoop XML type descriptor format
URL: https://github.com/apache/knox/pull/236#discussion_r366277631
 
 

 ##########
 File path: gateway-cm-integration/src/test/resources/testDescriptor.xml
 ##########
 @@ -0,0 +1,47 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+http://www.apache.org/licenses/LICENSE-2.0
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<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:admin-ui;
+        HIVE:url=http://localhost:456;
+        HIVE:version=1.0;
+        HIVE:httpclient.connectionTimeout=5m;
+        HIVE:httpclient.socketTimeout=100m
 
 Review comment:
   Nothing within a `<value>...</value>` should be interpreted as XML; it's 
only a string which happens to be a list of different key-value pair separated 
by a semicolon character.
   I do not wee why CDATA is needed here.
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 371532)
    Time Spent: 2.5h  (was: 2h 20m)

> 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: 2.5h
>  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)

Reply via email to