ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Speidel" <jspei...@hortonworks.com>
Subject Re: Review Request 34233: Update Blueprint configuration processor to filter out passwords that are not required from an exported Blueprint
Date Fri, 15 May 2015 13:46:34 GMT

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

Ship it!


Ship It!

- John Speidel


On May 14, 2015, 8:50 p.m., Robert Nettleton wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/34233/
> -----------------------------------------------------------
> 
> (Updated May 14, 2015, 8:50 p.m.)
> 
> 
> Review request for Ambari, John Speidel, Mahadev Konar, and Robert Levas.
> 
> 
> Bugs: AMBARI-9480
>     https://issues.apache.org/jira/browse/AMBARI-9480
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> This patch resolves AMBARI-9480. 
> 
> When a Blueprint was exported from a running cluster (typically any cluster using a Ranger-enabled
component), some Ranger-specific properties were being exported that are password fields.
 While these fields are marked as passwords in the metadata, they are not marked as requiring
input, which keeps the Blueprint processor from excluding them in the exported Blueprint,
since the Blueprint processor can only validate password properties at cluster creation time.
 
> 
> This patch addresses this problem by:
> 
> 1. Adding an internal list of filters that can be applied across all the configuration
being considered during a Blueprint export. This patch adds a single filter implementation
that can be used to exclude any properties with a name that ends with "PASSWORD".  This matching
is a case-insensitive match.  Any properties that match this filter are excluded from an exported
Blueprint. This will also simplify maintenance for issues like this in the future, since any
password properties that are named as such will be automatically excluded, without the BlueprintConfigurationProcessor
having to be aware of individual property names in this category.  New filters could also
be added over time in a generic fashion, to allow more fine-grained control over the output
of an exported Blueprint.  
> 2. Adding a new unit test to verify this change.
> 
> 
> Diffs
> -----
> 
>   ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
aef6664 
>   ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
390f73e 
> 
> Diff: https://reviews.apache.org/r/34233/diff/
> 
> 
> Testing
> -------
> 
> 1. Ran the ambari-server unit tests, which are all passing.
> 2. Deployed a single-node cluster in the Ambari UI, exported a Blueprint once the cluster
was running, and verified that no password properties exist in the exported Blueprint. 
> 3. Took the exported Blueprint from Step #2, and used this in a "round-trip" test, meaning
that I created a new cluster based on this Blueprint.  That cluster deployment succeeded.
> 
> 
> Thanks,
> 
> Robert Nettleton
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message