----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/34233/#review83885 -----------------------------------------------------------
Ship it! Ship It! - Mahadev Konar 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 > >
