Mailing-List: contact bigtop-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bigtop-dev@incubator.apache.org
Date: Thu, 12 Jul 2012 02:51:35 +0000 (UTC)
From: "Sujay Rau (JIRA)" <jira@apache.org>
To: bigtop-dev@incubator.apache.org
Message-ID: <1248889888.39865.1342061495598.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <184196185.27304.1340061102791.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (BIGTOP-635) Implement a cluster-abstraction,
 discovery and manipulation framework for iTest
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/BIGTOP-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13412471#comment-13412471 ] 

Sujay Rau commented on BIGTOP-635:
----------------------------------

Devaraj: I did look at that HBase patch while I was plotting out this design. I think the fact that the scopes of the HBase jira and this Bigtop jira are slightly different, accounts for the variances between the two posted patches, but at the core they share a lot of the same structure. ClusterManager is effectively the same, while HBASE-6241's HBaseCluster has the same functionality of HBaseShim. HBaseClusterManager is an example of an implementation for a particular distribution that uses service scripts as its way of communication with the cluster.

Eric: That's an interesting idea. In this JIRA I'm going to start with this simple implementation and try to solve the original problem created by BIGTOP-614, but other implementations like Ambari could definitely be used in the future.
                
> Implement a cluster-abstraction, discovery and manipulation framework for iTest
> -------------------------------------------------------------------------------
>
>                 Key: BIGTOP-635
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-635
>             Project: Bigtop
>          Issue Type: New Feature
>          Components: Tests
>    Affects Versions: 0.4.0
>            Reporter: Roman Shaposhnik
>            Assignee: Sujay Rau
>             Fix For: 0.5.0
>
>         Attachments: BigtopClusterManager.zip, ClusterManagerAPI.pdf
>
>
> We've come to a point where our tests need to have a uniform way of interfacing with the cluster under test. It is no longer ok to assume that the test can be executed on a particular node (and thus have access to services running on it). It is also less than ideal for tests to assume a particular type of interaction with the services since it tends to break in different deployment scenarios. 
> A framework that needs to be put in place has to be capable of (regardless of where a test using it is executed on):
>   # representing the abstract configuration of the cluster
>   # representing the abstract topology of the entire cluster (services running on a cluster, nodes hosting the daemons, racks, etc).
>   # giving tests an ability to query this topology
>   # giving tests an ability to affect the nodes in that topology in a particular way (refreshing configuration, restarting services, etc.)
> Of course, the ideal solution here would be to give Bigtop tests a programmatic access to a Hadoop cluster management framework such as Cloudera's CM or Apache Ambari. 
> As with any ideal solutions I don't think it is realistic though. Hence we have to cook something up. At this point I'm really focused on getting the API right and I'm totally fine with an implementation of that API to be something as silly as a bunch of ssh-based scripts or something.
> This JIRA is primarily focused on coming up with such an API. Anybody who's willing to help is welcome to.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira