----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24153/#review49250 -----------------------------------------------------------
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java <https://reviews.apache.org/r/24153/#comment86196> not thrown ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java <https://reviews.apache.org/r/24153/#comment86191> not thrown ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java <https://reviews.apache.org/r/24153/#comment86188> Question about need to do conversion of globals here. I see that this is also handled in AmbariManagementControllerImpl.createConfiguration(). I didn't trace through all of the configuration creation code but assume that the AMCI.createConfiguration() is called when we set configurations on the cluster. To me, it makes more sense to do this global conversion at a lower level than the BP processing code as you are doing in AMCI. Why do we also need to do this here in the BP processing code. Ideally, it would be all done where the configuration is actually being processed at a lower level. In addition to configurations being created in BP processing, some clients are still using the underlying REST API calls to provision clusters until they switch over to blueprints. If the global migration logic wasn't handled at a lower common level, these API calls would also need to do the conversion. Also, the BP global conversion isn't being called for host group scoped configurations, only cluster scoped. So to summarize, why do we need to handle global conversion in the BP processing code as opposed to doing it at a lower level where the configuration are processed. ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java <https://reviews.apache.org/r/24153/#comment86152> The setting of these 3 properties associated with AMBARI-4921 should be removed as user_group and smokeuser have been added to the stack and nagios_contact is a required input for the user. - John Speidel On July 31, 2014, 4:09 p.m., Andrew Onischuk wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/24153/ > ----------------------------------------------------------- > > (Updated July 31, 2014, 4:09 p.m.) > > > Review request for Ambari, John Speidel, Nate Cole, and Vitalyi Brodetskyi. > > > Bugs: AMBARI-6695 > https://issues.apache.org/jira/browse/AMBARI-6695 > > > Repository: ambari > > > Description > ------- > > How to handle support for blueprints + configs API where global configs are > set, since global config_type is being eliminated. > > * warn that global is deprecated > * map global to whatever-the-new-config-type automatically > > jspeidel this affects blueprints and the configs API > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java > 7f53ded > > ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java > 906cba4 > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BaseBlueprintProcessor.java > b3a8019 > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java > b72beb6 > > ambari-server/src/main/java/org/apache/ambari/server/state/ConfigHelper.java > 81c3c38 > > ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog170.java > 5f67a30 > > ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ClusterResourceProviderTest.java > d8f7fbc > > Diff: https://reviews.apache.org/r/24153/diff/ > > > Testing > ------- > > mvn clean test > > > Thanks, > > Andrew Onischuk > >
