> On March 14, 2014, 12: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?
> 
> John Speidel wrote:
>     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.
>

Thanks - I see what's happening much more clearly now.


- Nate


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19209/#review37218
-----------------------------------------------------------


On March 13, 2014, 8:01 p.m., John Speidel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19209/
> -----------------------------------------------------------
> 
> (Updated March 13, 2014, 8:01 p.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
> 
>

Reply via email to