You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by Robert Nettleton <rn...@hortonworks.com> on 2015/05/14 22:50:14 UTC
Review Request 34233: Update Blueprint configuration processor to
filter out passwords that are not required from an exported Blueprint
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/34233/
-----------------------------------------------------------
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
Re: Review Request 34233: Update Blueprint configuration processor to
filter out passwords that are not required from an exported Blueprint
Posted by Robert Levas <rl...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/34233/#review83843
-----------------------------------------------------------
Ship it!
Ship It!
- Robert Levas
On May 14, 2015, 4: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, 4: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
>
>
Re: Review Request 34233: Update Blueprint configuration processor to
filter out passwords that are not required from an exported Blueprint
Posted by John Speidel <js...@hortonworks.com>.
-----------------------------------------------------------
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
>
>
Re: Review Request 34233: Update Blueprint configuration processor to
filter out passwords that are not required from an exported Blueprint
Posted by Mahadev Konar <ma...@apache.org>.
-----------------------------------------------------------
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
>
>