[ 
https://issues.apache.org/jira/browse/BIGTOP-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Chu reassigned BIGTOP-635:
----------------------------------

    Assignee: Stephen Chu  (was: Sujay Rau)
    
> 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: Stephen Chu
>             Fix For: 0.5.0
>
>         Attachments: bigtop-635.patch, bigtop-635.patch, 
> BigtopClusterManagerv2.zip, 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

        

Reply via email to