[
https://issues.apache.org/jira/browse/BIGTOP-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411997#comment-13411997
]
Konstantin Boudnik commented on BIGTOP-635:
-------------------------------------------
bq. Ambari started with the BigTop puppet scripts, so it seems like it would be
natural to settle on a common framework. I'm sure we could wrestle up some
interested contributors form the AmbariVerse...
Great idea, Eric! And, of course, contributions are the most important part of
any vibrant open source community!
Bigtop providing a pre-built package for Ambari? Yes, why not! It won't be
included to 0.4 release, apparently. And I guess it won't be ready on time for
0.3.1 update either, but I am sure with the right amount of contribution it
can make into 0.5 (subject to the release vote, of course).
Here's a couple general ideas behind this work, as a headstart to potential
contributors:
BigTop needs an ability to control and monitor internal states of a cluster
from within the tests. This, basically, put a couple of requirements on any
cluster management framework that might be considered/developed:
- simplicity of Java APIs (after all, iTest is written in Groovy and it is
done for a very good reason).
- agility of the management framework: for the sake of validation's
efficiency and clean control-flow of the testing scenarios an API call
from a test to the framework should be synchronous
- and most importantly, I do want to have programming control without a need
to deal with Puppet recipes modification every time something needs to be
tweaked, nor with bringing up a separate Puppet master, because master-less
mode
won't work in this particular case.
Cos
> 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
