Mailing-List: contact issues-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Thu, 11 Aug 2016 09:09:20 +0000 (UTC)
From: "Nate Cole (JIRA)" <jira@apache.org>
To: issues@ambari.apache.org
Message-ID: <JIRA.12980018.1466116629000.281177.1470906560568@Atlassian.JIRA>
In-Reply-To: <JIRA.12980018.1466116629000@Atlassian.JIRA>
References: <JIRA.12980018.1466116629000@Atlassian.JIRA> <JIRA.12980018.1466116629076@arcas>
Subject: [jira] [Commented] (AMBARI-17285) Custom service repos in
 repoinfo.xml got overwritten by public VDFs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 11 Aug 2016 09:09:22 -0000


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

Nate Cole commented on AMBARI-17285:
------------------------------------

I have been able to use a custom repoinfo.xml defined for Ambari.  Can you see the additional repos if you pick the {{\[Version\] (Default Version Definition)}} from the dropdown?

> 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)