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

Hadoop QA commented on AMBARI-10639:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12727121/AMBARI-10639.patch
  against trunk revision .

    {color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

    {color:green}+1 tests included{color}.  The patch appears to include 2 new 
or modified test files.

    {color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

    {color:red}-1 core tests{color}.  The test build failed in ambari-server 

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/2447//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/2447//console

This message is automatically generated.

> Configuration Versions Should Be Calculated By the Database
> -----------------------------------------------------------
>
>                 Key: AMBARI-10639
>                 URL: https://issues.apache.org/jira/browse/AMBARI-10639
>             Project: Ambari
>          Issue Type: Task
>          Components: ambari-server
>    Affects Versions: 2.1.0
>            Reporter: Jonathan Hurley
>            Assignee: Jonathan Hurley
>             Fix For: 2.1.0
>
>         Attachments: AMBARI-10639.patch
>
>
> {{ConfigVersionHelper}} is used by Ambari to determine the "next" version 
> when creating configuration versions and service configuration versions. This 
> presents two problems:
> - In a distributed system, have an in-memory atomic does not work. When 
> Ambari becomes HA aware, this will be problematic.
> - It does not support downgrading and removing the current maximum. There 
> would need to be code added in various places to always remember to decrement 
> this value. The decoupled nature is prone it error.
> Instead, this class should be removed in favor of calculate this from the 
> database using a max() function on the column. This will allow removal of 
> configurations during downgrade to properly revert to the prior configuration 
> version.



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

Reply via email to