[ 
https://issues.apache.org/jira/browse/KNOX-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182980#comment-16182980
 ] 

Phil Zampino edited comment on KNOX-1014 at 9/27/17 7:10 PM:
-------------------------------------------------------------

{quote}
1. hive protocol scheme
2. deployment fail for missing services or no?
3. .yaml extension in addition to .yml
4. service level params

1. It was unclear to me whether hive proxying through Knox is supported if the 
transport mode is NOT http. If it is unsupported, then the resolution of the 
second item in your list comes into play...
2. Prior to supporting service discovery, a topology would deploy just fine 
with incorrect/invalid service URLs. However, I could be persuaded that failure 
to dynamically determine a URL for a service declared in a descriptor should 
cause topology generation to fail (since discovery knows it would be generating 
an incorrect topology whereas a human does not necessarily know this). I don't 
know if we want to generate/deploy something that the descriptor author did not 
intend.
3. This is literally a one-line change; Consider it done.
{quote}

# KNOX-1064 includes changes to address this
# KNOX-1064 includes changes to address this
# KNOX-1063 will address this
# KNOX-1062 will address this




was (Author: pzampino):
{quote}
1. hive protocol scheme
2. deployment fail for missing services or no?
3. .yaml extension in addition to .yml

1. It was unclear to me whether hive proxying through Knox is supported if the 
transport mode is NOT http. If it is unsupported, then the resolution of the 
second item in your list comes into play...
2. Prior to supporting service discovery, a topology would deploy just fine 
with incorrect/invalid service URLs. However, I could be persuaded that failure 
to dynamically determine a URL for a service declared in a descriptor should 
cause topology generation to fail (since discovery knows it would be generating 
an incorrect topology whereas a human does not necessarily know this). I don't 
know if we want to generate/deploy something that the descriptor author did not 
intend.
3. This is literally a one-line change; Consider it done.
{quote}

# KNOX-1064 includes changes to address this
# KNOX-1064 includes changes to address this
# KNOX-1063 will address this




> Service Discovery and Topology Generation Framework
> ---------------------------------------------------
>
>                 Key: KNOX-1014
>                 URL: https://issues.apache.org/jira/browse/KNOX-1014
>             Project: Apache Knox
>          Issue Type: Sub-task
>          Components: Server
>            Reporter: Phil Zampino
>            Assignee: Phil Zampino
>              Labels: kip-8
>             Fix For: 0.14.0
>
>         Attachments: KNOX-1014-002.patch, KNOX-1014.patch
>
>
> Implement the foundation for Service Discovery and Topology Generation.
> * Define simple descriptor format (YAML, JSON, etc...)
> * Local simple descriptor and shared provider configuration discovery
> ** Monitor conf/shared-providers, conf/descriptors similar to the way 
> conf/topologies is currently monitored.
> * Ambari service discovery (REST API interactions and model construction)
> ** Configuration
> *** How to plug-in discovery implementations
> *** How to configure authentication (credentials/trust) with the service 
> registries
> * Topology assembly from simple descriptor and discovery details
> * Topology deployment



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to