Re: Review Request 49912: Blueprint registration step uses wrong format for property-attributes in Configuration
> On July 13, 2016, 4:53 p.m., Di Li wrote:
> > Ship It!
>
> Di Li wrote:
> committed, please close the record.
Thank you Di!
- Keta
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/49912/#review142077
---
On July 11, 2016, 6:43 p.m., Keta Patel wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/49912/
> ---
>
> (Updated July 11, 2016, 6:43 p.m.)
>
>
> Review request for Ambari, Di Li and Robert Nettleton.
>
>
> Bugs: AMBARI-17626
> https://issues.apache.org/jira/browse/AMBARI-17626
>
>
> Repository: ambari
>
>
> Description
> ---
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
>
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
>
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
>
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
>
>
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
>
>
> Diffs
> -
>
>
> ambari-server/src/main/java/org/apache/ambari/server/topology/ConfigurationFactory.java
> f4dc879
>
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ProvisionClusterRequestTest.java
> 0610d10
>
> ambari-server/src/test/java/org/apache/ambari/server/topology/ConfigurationFactoryTest.java
> 1c2b177
>
> Diff: https://reviews.apache.org/r/49912/diff/
>
>
> Testing
> ---
>
> Fixed the following tests to include the strategy changes for configuration
> attributes:
> ConfigurationFactoryTest.java
> ProvisionClusterRequestTest.java
>
>
> Thanks,
>
> Keta Patel
>
>
Re: Review Request 49912: Blueprint registration step uses wrong format for property-attributes in Configuration
> On July 13, 2016, 4:53 p.m., Di Li wrote:
> > Ship It!
committed, please close the record.
- Di
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/49912/#review142077
---
On July 11, 2016, 6:43 p.m., Keta Patel wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/49912/
> ---
>
> (Updated July 11, 2016, 6:43 p.m.)
>
>
> Review request for Ambari, Di Li and Robert Nettleton.
>
>
> Bugs: AMBARI-17626
> https://issues.apache.org/jira/browse/AMBARI-17626
>
>
> Repository: ambari
>
>
> Description
> ---
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
>
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
>
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
>
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
>
>
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
>
>
> Diffs
> -
>
>
> ambari-server/src/main/java/org/apache/ambari/server/topology/ConfigurationFactory.java
> f4dc879
>
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ProvisionClusterRequestTest.java
> 0610d10
>
> ambari-server/src/test/java/org/apache/ambari/server/topology/ConfigurationFactoryTest.java
> 1c2b177
>
> Diff: https://reviews.apache.org/r/49912/diff/
>
>
> Testing
> ---
>
> Fixed the following tests to include the strategy changes for configuration
> attributes:
> ConfigurationFactoryTest.java
> ProvisionClusterRequestTest.java
>
>
> Thanks,
>
> Keta Patel
>
>
Re: Review Request 49912: Blueprint registration step uses wrong format for property-attributes in Configuration
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/49912/#review142077
---
Ship it!
Ship It!
- Di Li
On July 11, 2016, 6:43 p.m., Keta Patel wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/49912/
> ---
>
> (Updated July 11, 2016, 6:43 p.m.)
>
>
> Review request for Ambari, Di Li and Robert Nettleton.
>
>
> Bugs: AMBARI-17626
> https://issues.apache.org/jira/browse/AMBARI-17626
>
>
> Repository: ambari
>
>
> Description
> ---
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
>
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
>
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
>
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
>
>
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
>
>
> Diffs
> -
>
>
> ambari-server/src/main/java/org/apache/ambari/server/topology/ConfigurationFactory.java
> f4dc879
>
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ProvisionClusterRequestTest.java
> 0610d10
>
> ambari-server/src/test/java/org/apache/ambari/server/topology/ConfigurationFactoryTest.java
> 1c2b177
>
> Diff: https://reviews.apache.org/r/49912/diff/
>
>
> Testing
> ---
>
> Fixed the following tests to include the strategy changes for configuration
> attributes:
> ConfigurationFactoryTest.java
> ProvisionClusterRequestTest.java
>
>
> Thanks,
>
> Keta Patel
>
>
