----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/29969/#review68648 -----------------------------------------------------------
ambari-server/src/main/java/org/apache/ambari/server/agent/HeartBeatHandler.java <https://reviews.apache.org/r/29969/#comment112995> Should perhaps also check for not empty ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java <https://reviews.apache.org/r/29969/#comment112996> I agree the logic of checking that findByCluster(...).isEmpty() is correct. However, why is the initial state UPGRADING instead of CURRENT? ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java <https://reviews.apache.org/r/29969/#comment113001> We should only allow creating a cluster_version in a CURRENT state. ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java <https://reviews.apache.org/r/29969/#comment113002> Why is this needed? I thought UPGRADED->CURRENT is the only transition that ends in CURRENT. ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java <https://reviews.apache.org/r/29969/#comment112999> We should allow initializing to a CURRENT state if the host has no other host_version records. We should only initialize in an UPGRADING state if we know that we are in the middle of an upgrade because the cluster has a version whose state is UPGRADING or UPGRADED. ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java <https://reviews.apache.org/r/29969/#comment113000> I will remove this logic that checks for ZKFC in a future patch. - Alejandro Fernandez On Jan. 17, 2015, 1:01 a.m., Yurii Shylov wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/29969/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2015, 1:01 a.m.) > > > Review request for Ambari, Alejandro Fernandez, Dmitro Lisnichenko, and Nate > Cole. > > > Bugs: AMBARI-9183 > https://issues.apache.org/jira/browse/AMBARI-9183 > > > Repository: ambari > > > Description > ------- > > Currently on clean install Ambari creates cluster entity and its repository > version with version taken from selected stack. I.e. for stack HDP-2.2, > version 2.2 is written to database, without any information about the actual > minor version of that stack. Besides that we can't assume that cluster has > some version until it has at least one of components of that version. > Repository version creation should be detached from cluster creation; instead > of that versions should be created after receiving the first actual version > from service responses during install. > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/agent/HeartBeatHandler.java > b5fda49 > > ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java > 6dabcbb > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java > befd014 > > ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostVersionDAO.java > ed9fa24 > ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java > fd0188c > > ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java > 19a5f9f > > ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClustersImpl.java > 9ec8c36 > > ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java > 31606ca > > ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterTest.java > 57c0223 > > Diff: https://reviews.apache.org/r/29969/diff/ > > > Testing > ------- > > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 55:35.812s > > > Tested clean install and rolling upgrade manually on 2-node cluster > > > Thanks, > > Yurii Shylov > >
