You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Nate Cole (JIRA)" <ji...@apache.org> on 2016/07/12 21:03:20 UTC

[jira] [Comment Edited] (AMBARI-17285) Custom service repos in repoinfo.xml got overwritten by public VDFs

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

Nate Cole edited comment on AMBARI-17285 at 7/12/16 9:02 PM:
-------------------------------------------------------------

I think that we should probably add a directive that will allow preserving of stack-defined repos when using VDF.

This directive would be used with the following logic:  If passing the directive (to be named) as {{true}}, check if there are any repos that do NOT match the ids within the VDF, and use them for the repo version.

As an example:
HDP/2.5 defines two repos, name/id'ed by HDP/HDP-2.5 and HDP-UTILS/HDP-UTILS-1.1.0.21.


||Directive||Stack||VDF||Repo Version||
|false (default)|HDP\\HDP-UTILS|HDP\\HDP-UTILS|HDP\\HDP-UTILS|
|true|HDP \\ HDP-UTILS\\SOME-REPO|HDP \\ HDP-UTILS|HDP \\ HDP-UTILS\\SOME-REPO|

We can default to either {{true}} or {{false}}, I'm not too picky on that point.  Thoughts welcome.


was (Author: ncole@hortonworks.com):
I think that we should probably add a directive that will allow preserving of stack-defined repos when using VDF.  As an example
HDP/2.5 defines two repos, name/id'ed by HDP/HDP-2.5 and HDP-UTILS/HDP-UTILS-1.1.0.20.

This directive would be used with the following logic:  If passing the directive (to be named) as {{true}}, check if there are any repos that do NOT match the ids within the VDF, and use them for the repo version.  Therefore:

||Directive||Stack||VDF||Repo Version||
|false (default)|HDP\\HDP-UTILS|HDP\\HDP-UTILS|HDP\\HDP-UTILS|
|true|HDP \\ HDP-UTILS\\SOME-REPO|HDP \\ HDP-UTILS|HDP \\ HDP-UTILS\\SOME-REPO|

We can default to either {{true}} or {{false}}, I'm not too picky on that point.  Thoughts welcome.

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