ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vineet Goel (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs
Date Fri, 12 Aug 2016 00:45:20 GMT

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

Vineet Goel commented on AMBARI-17285:
--------------------------------------

I'm putting myself in the users shoes and looking at these installation screens and versions
tabs, and I have to say that many of the Ambari users will likely never figure out where their
custom repo went, and how to install that service. For those who figure it out, they now have
an extra burden to decide whether to use the default stack repos presented or something else.
Ideally, the new functionality in Ambari 2.4 should present a consistent experience, not to
mention that the initial screens that come up don't even show the custom repos.

> Custom service repos in repoinfo.xml got overwritten by public VDFs
> -------------------------------------------------------------------
>
>                 Key: AMBARI-17285
>                 URL: https://issues.apache.org/jira/browse/AMBARI-17285
>             Project: Ambari
>          Issue Type: Bug
>            Reporter: Alexander Denissov
>            Assignee: Nate Cole
>            Priority: Critical
>             Fix For: 2.4.0
>
>
> Ambari 2.4 introduced Version Definition Files that break the functionality of adding
a custom service repo, since custom services do not have an entry in the public VDF.
> In the case of HAWQ, the plugin is installed on Ambari host and it adds the new repo
information to the repoinfo.xml of all available stacks on the file system. Once Ambari cluster
creation wizard queries the latest repo info from the public URLs, it will get the info for
all stack repos, but not the custom ones. 
> So, the logic should be:
> 1. Use default repoinfo (from file system) as the base
> 2. Query public VDF, if available
> 3. For each entry in public VDF overwrite values in the default repoinfo
> 4. Entries in default repoinfo that do not have corresponding entries in VDF should stay
intact
> This way custom services can be added via file edit and the latest information can still
be retrieved and applied for the standard stack.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message