ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nate Cole" <nc...@hortonworks.com>
Subject Re: Review Request 19209: Provision a cluster from an Ambari Blueprint
Date Fri, 14 Mar 2014 17:59:05 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message