> On March 14, 2014, 4:47 p.m., Nate Cole wrote: > > ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java, > > lines 1444-1447 > > <https://reviews.apache.org/r/19209/diff/1/?file=519426#file519426line1444> > > > > How is projected state INSTALLED different from oldSchState == INIT? > > This block also implies that if the old state is in a bad place (UNKNOWN or > > NSTALL_FAILED) that a command is going to be generated anyway. How can > > something expected to be INSTALLED when this is code path says we want it > > to be STARTED?
Nate, Thanks for the good question. Because we are actually doing 2 state transitions for a cluster create from a blueprint, INIT->INSTALLED->STARTED, the old state will always be INIT when we get to this point in a cluster create from blueprint since both stages (INIT->INSTALLED and INSTALLED->STARTED) are still queued and haven't executed. To be clear, because we are doing 2 state transitions, we will hit this code twice; once for INIT->INSTALLED and once for INSTALLED->STARTED and oldSchState will be INIT in both cases so we need to check the projected state of the request up to that point to see if the new state transition is valid. You make a good point that I should check for the INIT state prior to looking at the projected state: oldSchState == State.INIT && requestStages.getProjectedState(scHost.getHostName(),scHost.getServiceComponentName()) == State.INSTALLED Since cluster create from blueprint is the only place we are currently doing multiple state transitions in a request, it will be ok to check for INIT and then the projected state. If we make multiple state transitions more generic in the future, checking for INIT may not be valid since the initial state may not be INIT for the request, but we can tackle that when/if that happens. If my explanation is not clear, ping me and we can discuss. - John ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19209/#review37218 ----------------------------------------------------------- On March 14, 2014, 12:01 a.m., John Speidel wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/19209/ > ----------------------------------------------------------- > > (Updated March 14, 2014, 12:01 a.m.) > > > Review request for Ambari, Nate Cole, Sid Wagle, and Tom Beerbower. > > > Bugs: AMBARI-5077 > https://issues.apache.org/jira/browse/AMBARI-5077 > > > Repository: ambari > > > Description > ------- > > Provision a cluster from an Ambari Blueprint. > Allow a cluster to be fully provisioned via the Ambari REST API with a single > REST API call by specifying a blueprint name. This means that from a single, > simple asynchronous REST API call, a cluster can now be provisioned from INIT > to STARTED. > > For more see the corresponding Jira: > https://issues.apache.org/jira/browse/AMBARI-5077 > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementController.java > 03ddaa6 > > ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java > 5f85d83 > > ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java > 5e2e47c > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterControllerImpl.java > 707c66a > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java > 3d55871 > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ComponentResourceProvider.java > 59a52e5 > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RequestStages.java > PRE-CREATION > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ServiceResourceProvider.java > 76a17d2 > > ambari-server/src/main/java/org/apache/ambari/server/controller/spi/SystemException.java > 0426657 > > ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java > c877ac0 > > ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ClusterResourceProviderTest.java > 96a9814 > > ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ComponentResourceProviderTest.java > 76c6ae3 > > ambari-server/src/test/java/org/apache/ambari/server/controller/internal/RequestStagesTest.java > PRE-CREATION > > ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ServiceResourceProviderTest.java > 8bc97cd > > Diff: https://reviews.apache.org/r/19209/diff/ > > > Testing > ------- > > Functional tests with a single host group and HDFS, OOZIE, NAGIOS and GANGLIA > services. > > Unit tests added. > Ran all existing unit tests: > OK > ---------------------------------------------------------------------- > Total run:507 > Total errors:0 > Total failures:0 > ... > [INFO] Executed tasks > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 18:37.734s > [INFO] Finished at: Thu Mar 13 19:13:12 EDT 2014 > [INFO] Final Memory: 28M/123M > [INFO] > ------------------------------------------------------------------------ > > > Thanks, > > John Speidel > >
