[
https://issues.apache.org/jira/browse/AMBARI-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543644#comment-14543644
]
Hadoop QA commented on AMBARI-10931:
------------------------------------
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12732815/AMBARI-10931_02.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 1 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:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/2721//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/2721//console
This message is automatically generated.
> Blueprints processor needs stronger validation of Blueprint JSON structure
> --------------------------------------------------------------------------
>
> Key: AMBARI-10931
> URL: https://issues.apache.org/jira/browse/AMBARI-10931
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: 2.0.0
> Reporter: Emil Anca
> Assignee: Emil Anca
> Labels: blueprints
> Fix For: 2.1.0
>
> Attachments: AMBARI-10931_01.patch, AMBARI-10931_02.patch
>
>
> The Blueprints processor needs to have stronger validation during the process
> of handling a POST for a newly-submitted Blueprint from a REST client.
> The Blueprints structure requires that the "configurations" element be an
> array of Maps, with each Map representing a given configuration type
> ("core-site", "storm-site", etc).
> Typically, the configurations structure should look like:
> ""configurations": [
> {
> "mapred-env": {
> "properties":
> { "mapreduce_log_dir_prefix": "/grid/0/log/hadoop-mapreduce" }
> }
> },
> { "mapred-site": {
> "properties":
> { "install-test-mapred-site": "install-test-mapred-site-VALUE" }
> }
> },
> { "yarn-env": {
> "properties":
> { "yarn_log_dir_prefix": "/grid/0/log/hadoop" }
> }
> }
> ]"
> The snippet above is just an example to illustrate the expected format.
> Recent changes to the Blueprint's structure to handle "properties_attributes"
> (such as "final") have modified the structure of a Blueprint, so that
> configuration properties are now contained in a "properties" map, internal to
> each configuration type. Creating new Blueprints using this newer format (the
> older format is still acceptable to the processor) require that the
> configuration types are still enclosed in a map, even though an internal map
> is also present, which may be a source of confusion.
> An example of an incorrect format would be:
> ""configurations": [
> {
> "mapred-env": {
> "properties":
> { "mapreduce_log_dir_prefix": "/grid/0/log/hadoop-mapreduce" }
> },
> "mapred-site": {
> "properties":
> { "install-test-mapred-site": "install-test-mapred-site-VALUE" }
> },
> "yarn-env": {
> "properties":
> { "yarn_log_dir_prefix": "/grid/0/log/hadoop" }
> }
> ]
> "
> Please note that in the example above a single map is created, with all
> configuration elements being added to that entry's configuration type. This
> causes a corrupted Blueprint to be stored and used for deployments, since all
> configuration elements added in the original Blueprint will be registered
> under one of the config types used in the original Blueprint. This will cause
> many types of cluster startup failures, as the configuration elements will be
> added to incorrect locations.
> When the Blueprint processor receives a POST submission with a new Blueprint
> that includes this incorrect format for "configurations", the processor must
> reject this submission, and send back a relevant error code/message, so that
> the user can resolve this problem prior to attempting a cluster deployment.
> This issue will not affect the older format for Blueprints, and so any
> backwards-compatible Blueprints used should work fine. This issue will only
> occur when new Blueprints are submitted that use the newer syntax/format for
> defining configuration properties (with support for properties_attributes) as
> well.
> This JIRA is being created to track this issue, as it could potentially be a
> user experience issue going forward, and should probably be resolved in
> Ambari 2.1, if possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
