> On June 9, 2015, 1:42 p.m., Robert Nettleton wrote: > > I don't think this patch should be merged. > > > > The current BlueprintConfigurationProcessor could simply be updated by > > registering a new PropertyUpdater for the "oozie_heapsize" property. > > > > While I applaud the concern for making something more general, its not > > clear to me that all configuration properties across the stack require the > > "m" suffix appended. There may be other properties that require a MB unit > > of measure, but don't have the same requirements that the heapsize > > properties do. > > > > At this stage in the release, I don't think this is an appropriate change > > to make. > > > > I request that this change be modified to simply register a heapsize > > PropertyUpdater for the required properties. > > > > A more general solution should be implemented in the next release, likely > > with major changes to the stack definitions to support this.
+1 on all of Bob's comments and issues. We have been pushing to generalize the resolution of configuration properties and it keeps getting deferred. Like Bob, I also appreciate your effor to handle this case in a general manner but am in agreement that just because a property has MB specified for units of measure doesn't guarantee that it should have 'm' appended to it. At this time I would like to see the property registered with the current updater. - John ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/35251/#review87170 ----------------------------------------------------------- On June 9, 2015, 1:01 p.m., Andrew Onischuk wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/35251/ > ----------------------------------------------------------- > > (Updated June 9, 2015, 1:01 p.m.) > > > Review request for Ambari and Vitalyi Brodetskyi. > > > Bugs: AMBARI-11811 > https://issues.apache.org/jira/browse/AMBARI-11811 > > > Repository: ambari > > > Description > ------- > > This happens because some properties which show capacity don't have 'm' > appended when installing via blueprints (via UI installs it is done by UI) > this results in Oozie thinking that heapsize is in kb and failing with too low > heapsize. > > Also there are some other properties which don't have 'm' appended, but should > have, which results in missconfiguration issues (instead on megabytes > kilobytes are set) > > The proposal on how to fix it is to dynamically find the properties with > unit=MB and append 'm' to them, rather than hardcode that properties like it > is done now. > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java > ca7b2b1 > > ambari-server/src/main/java/org/apache/ambari/server/state/ValueAttributesInfo.java > 8054c54 > > ambari-server/src/main/java/org/apache/ambari/server/topology/ClusterConfigurationRequest.java > eb583fd > > ambari-server/src/main/java/org/apache/ambari/server/topology/TopologyManager.java > a75cccb > > ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/configuration/oozie-env.xml > 6439bc6 > > ambari-server/src/main/resources/common-services/OOZIE/5.0.0.2.3/configuration/oozie-env.xml > fe80bf5 > > ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/metainfo.xml > ca82d46 > > ambari-server/src/test/java/org/apache/ambari/server/api/query/render/ClusterBlueprintRendererTest.java > 96abb8c > > ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java > b049fd3 > > ambari-server/src/test/java/org/apache/ambari/server/topology/TopologyManagerTest.java > 64dfb28 > > Diff: https://reviews.apache.org/r/35251/diff/ > > > Testing > ------- > > mvn clean test > > > Thanks, > > Andrew Onischuk > >
