[
https://issues.apache.org/jira/browse/BIGTOP-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420846#comment-13420846
]
Stephen Chu commented on BIGTOP-635:
------------------------------------
Thanks, Sujay.
Some comments/questions:
* Where will this code live? In bigtop-test-framework? I think it'd be useful
to attach a patch with this code integrated into Bigtop source.
* In HBaseAdapter, you have start/stopRegionServer and start/stopHMaster. In
HDFSAdapter, I don't see start/stopNameNode or start/stopDataNode. Perhaps
they'd be useful? Same with the MRAdapter - start/stopTaskTracker and
start/stopJobTracker. However, for the purposes of supporting the HDFS HA
tests, maybe you don't have to worry about MR for now.
* Host has a serviceName. What will this eventually be used for? When I think
of a service name, I think of HDFS, MR, HBase, JobTracker, NameNode, etc. Will
a Host be tied to one of those service names?
* For ClusterManager's get/setConfiguration, do we have to restart services for
changes to be in effect?
> 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, BigtopClusterManagerv2.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
