[ 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