Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Content-Type: multipart/alternative;
 boundary="===============7792221090303680680=="
MIME-Version: 1.0
Subject: Review Request 27250: Proper handling exporting of 0.0.0.0 addresses
 with Blueprints
From: "Robert Nettleton" <rnettleton@hortonworks.com>
To: "John Speidel" <jspeidel@hortonworks.com>,
 "Nate Cole" <ncole@hortonworks.com>
Cc: "Ambari" <dev@ambari.apache.org>,
 "Robert Nettleton" <rnettleton@hortonworks.com>
Date: Mon, 27 Oct 2014 21:58:42 -0000
Message-ID: <20141027215842.7137.86292@reviews.apache.org>
Auto-Submitted: auto-generated
Sender: "Robert Nettleton" <noreply@reviews.apache.org>
Reply-To: "Robert Nettleton" <rnettleton@hortonworks.com>

--===============7792221090303680680==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27250/
-----------------------------------------------------------

Review request for Ambari, John Speidel and Nate Cole.


Repository: ambari


Description
-------

This patch implements a fix for AMBARI-7988.

The Blueprints config processor does not currently allow service
  config properties with the IP address of "0.0.0.0" to be
  included in an exported Blueprint.

The following properties:

yarn.timeline-service.address,
yarn.timeline-service.webapp.address,
yarn.timeline-service.webapp.https.address

are not included in an exported Blueprint after a successful
  cluster deployment the Yarn Application Timeline Service
  enabled.

The problem occurs because the default values for these
  properties is typically "0.0.0.0:portNumber".  This is
  a special IP address that the current Blueprints processor
  does no recognize as a valid service address.  Currently,
  the processor will remove any properties that require
  host topology information, but don't have any valid hostname
  included in the property.

This patch resolves the problem by adding some handling
  code to the Blueprint export processing.  If a property, such
  as the ones listed above, uses the default "0.0.0.0" address, then
  this property is now allowed in the exported blueprint, as this
  is a valid server address, but is not directly tied to the specific
  server topology of a given cluster.  If the user overrides these
  properties, then the hostname substitution process/export process
  will work as before.

This patch also implements a new unit test to verify this change.


Diffs
-----

  ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java 4183b9d 
  ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java 04c75a1 

Diff: https://reviews.apache.org/r/27250/diff/


Testing
-------

1. Ran the ambari-server unit tests with this patch applied (both trunk and 1.7.0), and all unit tests are passing with this change.
2. Manually verified the fix on 1.7.0. 
3. Manually verified the fix on trunk.


Thanks,

Robert Nettleton


--===============7792221090303680680==--