[jira] [Commented] (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=15422205#comment-15422205 ] Jayush Luniya commented on AMBARI-17285: Thanks [~vineetgoel] Moving this from 2.4.0 to 2.4.1 > 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 >Affects Versions: 2.4.0 >Reporter: Alexander Denissov >Assignee: Nate Cole >Priority: Critical > Fix For: 2.4.1 > > > 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)
[jira] [Commented] (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=15421812#comment-15421812 ] Vineet Goel commented on AMBARI-17285: -- [~jluniya] I was hoping it would be resolved in 2.4.0 itself, but given the 2.4.0 status and timelines, deferring to the next Ambari 2.4.x release is acceptable. > 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)
[jira] [Commented] (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=15421536#comment-15421536 ] Jayush Luniya commented on AMBARI-17285: [~vVineet] I agree with you that we should fix it, but the question really is about when? Unfortunately, it is too late to fix in 2.4.0.0 and too risky at this stage given where we are. Hence we are recommending to fix this in a 2.4.X maintenance release. The reasoning being this is not a regression as the old behavior is maintained (i.e. the customer can still deploy a cluster using static repo definition) The dynamic VDFs which is a new feature for 2.4.0.0 is currently not supporting custom repos. Since it is not a blocker and there is a workaround it would be better off to push this to a maintenance release and avoid destabilizing 2.4.0.0 release. cc: [~mahadev] [~sumitmohanty] > 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)
[jira] [Commented] (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=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)
[jira] [Commented] (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=15417926#comment-15417926 ] Alexander Denissov commented on AMBARI-17285: - Correct, however requiring the user to switch between 2 different tabs and copy & paste URLs is not a good experience. Ambari is the tool to make installation easy and transparent, having the user to go through these operations violates this promise and introduces a potential for user errors and failed installations. > 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)
[jira] [Commented] (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=15417808#comment-15417808 ] Nate Cole commented on AMBARI-17285: You can change the URLs even if it comes from default. We have provided the identical functionality as the previous version of Ambari, so that aspect should be no different for your users. > 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)
[jira] [Commented] (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=15417782#comment-15417782 ] Alexander Denissov commented on AMBARI-17285: - Right. This means that without a fix users will only be able to install HAWQ if they choose the default VDF, which is usually obsolete and refers to the older maintenance versions. A user would have to choose between installing the most recent stack without HAWQ and installing HAWQ with the older stack. This is not a choice we want the users to make, we would like them to be able to install the latest stack with HAWQ right out of the box. > 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)
[jira] [Commented] (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=15417598#comment-15417598 ] Jayush Luniya commented on AMBARI-17285: Yes that is correct. The default static version definition should work. The dynamic version definition doesn't support add-on repos yet. > 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)
[jira] [Commented] (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=15417347#comment-15417347
]
Nate Cole commented on AMBARI-17285:
I have confirmed that using the {{Default Version Definition}} from the drop
down provides the same exact behavior as Ambari 2.2.2 did when registering
versions.
> 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)
[jira] [Commented] (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=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)
[jira] [Commented] (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=15416147#comment-15416147 ] Alexander Denissov commented on AMBARI-17285: - [~jluniya] -- I'm afraid we can not have this delayed as the fix is critical, otherwise HAWQ installation will not work with Ambari 2.4 > 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)
[jira] [Commented] (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=15415767#comment-15415767 ] Jayush Luniya commented on AMBARI-17285: [~adenissov] Can this be postponed to a maintenance release of Ambari 2.4? > 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)
[jira] [Commented] (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=15412598#comment-15412598 ] Alexander Denissov commented on AMBARI-17285: - [~nc...@hortonworks.com] [~jluniya] -- guys, any updates on the status of this issue ? > 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)
[jira] [Commented] (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=15373685#comment-15373685
]
Alexander Denissov commented on AMBARI-17285:
-
yes, guarding this logic via such a flag is fine, but where will it be defined
? For this to be useful for 3-rd party repos, such as HAWQ, the flag will need
to be set as to {{true}} for HDP stacks, so defaulting this to {{true}} makes
more sense.
> 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)
[jira] [Commented] (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 commented on AMBARI-17285:
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)
[jira] [Commented] (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=15371878#comment-15371878 ] Jayush Luniya commented on AMBARI-17285: [~adenisso] Yes this was part of a blanket move of JIRAs that are not blockers/critical to 2.5.0. I will move this JIRA back to 2.4.0. Also as we discussed during the meetup, I am following up on this with the team for a solution for this issue. Stay tuned :) > 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 > 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)
[jira] [Commented] (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=15371864#comment-15371864 ] Yusaku Sako commented on AMBARI-17285: -- [~adenisso], I think the move to 2.5.0 was a result of bulk move that [~jluniya] did. Let's discuss and come up with an acceptable solution that would work for non HDP stacks. > 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 > 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)
[jira] [Commented] (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=15371844#comment-15371844 ] Alexander Denissov commented on AMBARI-17285: - [~jluniya] -- I noticed this issue has been moved out of 2.4 release, which presents a problem for HAWQ / PXF services. Was there a specific reason for this decision ? This is a functional regression from the previous releases and without this feature the user experience of new cluster installation with HAWQ / PXF becomes very cumbersome, because: - if we add HDB repo to stack's repoinfo.xml as before, it will only show up in the "default" configuration and users will not be able to get the latest stack maintenance release without manually overriding the URL there. - if the user chooses "latest" version, there is no way to specify a custom repo there, so they are not able to install HAWQ / PXF. If we create our own VDF file, we can only do this statically before Ambari release, in which case the stack version will not be the latest by the time users are installing their stacks, correct ? In custom VDFs, does Ambari go check for the latest stack updates ? Asking users to generate VDFs dynamically before cluster installation would introduce complexity and is error-prone. We are out of user-friendly options without this issue being fixed and I don't know how a statically defined custom VDF would allow users to install the latest HDP stack at the time of install. > 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 > Fix For: 2.5.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)
[jira] [Commented] (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=15365429#comment-15365429
]
Nate Cole commented on AMBARI-17285:
The VDF contains the "minimum" repos to satisfy, so the VDF can be customized
with any other repos you need. There is a script in
{{contrib/version-builder}} that contains examples of how to make a VDF.
The stack defaults should be left as-is, and the specific versions can contain
whatever you wish. We are trying to move away from the confusion of merging
stack info with version info.
> 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
> 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)
[jira] [Commented] (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=15365345#comment-15365345 ] Zhe (Joe) Wang commented on AMBARI-17285: - [~bhuvnesh2703], let me reach out to [~ncole] tomorrow and get back to you tomorrow. Thank you. > 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 > 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)
[jira] [Commented] (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=15365339#comment-15365339 ] bhuvnesh chaudhary commented on AMBARI-17285: - [~jluniya][~ncole] [~jwang] Jayush, during the meetup we spoke about it for a moment, and you suggested that you will followup with your team internally. Any updates on this ? > 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 > 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)
[jira] [Commented] (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=15351575#comment-15351575 ] Zhe (Joe) Wang commented on AMBARI-17285: - Hi [~ncole], I believe for adding custom service to repo, users should provide their own VDF file with added services and urls. We should not do that in Repoinfo.xml any more. Am I right? If so, can you provide [~adenissov] instructions on how to create own VDF file? Thank you. > 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 > 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)
[jira] [Commented] (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=15351479#comment-15351479 ] Alexander Denissov commented on AMBARI-17285: - [~jwang] -- Joe, I think you worked on related functionality -- do you have any comments on this ? This is a blocker for HAWQ as the custom repo we setup in repoinfo.xml get ovewritten by the "latest" VDF, which is a regression from the previous release. cc: [~jluniya] > 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 > 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)
