Mirror of Apache Bigtop
Java Shell Groovy Puppet Scala Makefile Other
Latest commit 4e97c40 Jul 17, 2016 @oflebbe oflebbe BIGTOP-2494: Use systemd within bigtop/deploy docker image for debian…
…-8, centos-7, fix centos-7 provisioner
Failed to load latest commit information.
bigtop-bigpetstore BIGTOP-2136: A comment about parameter substitution in BPS_analytics.… Feb 11, 2016
bigtop-ci/jenkins BIGTOP-2414. Rename Tachyon to Alluxio May 16, 2016
bigtop-data-generators BIGTOP-1991. Add BigTop Weatherman Sep 15, 2015
bigtop-deploy BIGTOP-2494: Use systemd within bigtop/deploy docker image for debian… Jul 19, 2016
bigtop-packages/src BIGTOP-2495. hive-hbase package is broken Jul 18, 2016
bigtop-test-framework BIGTOP-2289. Set master version to 1.2.0-SNAPSHOT Jan 27, 2016
bigtop-tests BIGTOP-2429. Add Solr to gradle smokes Jul 10, 2016
bigtop_toolchain BIGTOP-2471: qfs does not build on opensuse:42.1 Jun 5, 2016
buildSrc/src BIGTOP-1494. Introduce Groovy DSL to replace bigtop.mk Sep 10, 2015
docker BIGTOP-2494: Use systemd within bigtop/deploy docker image for debian… Jul 19, 2016
docs BIGTOP-1 - initial code import. Jul 19, 2011
gradle/wrapper BIGTOP-2027. Bump gradle version, the wrapper to 2.7 Sep 15, 2015
src BIGTOP-2403. Remove affiliation column in the team list Apr 19, 2016
test BIGTOP-1000. Remove remaining references to the Incubator Jun 7, 2013
.dockerignore BIGTOP-2223. .dockerignore doesn't have ASL header Jan 7, 2016
.gitignore BIGTOP-2359. Add .DS_Store to .gitignore Mar 18, 2016
BUILDING.txt BIGTOP-1580: Improve Bigtop Toolchain: Versioning of Packages May 1, 2015
CHANGES.txt Merge branch 'branch-1.1' Jan 30, 2016
LICENSE BIGTOP-1 - initial code import. Jul 19, 2011
MAINTAINERS.txt BIGTOP-2479: Update qfs maintainer to kstinson Jun 10, 2016
NOTICE BIGTOP-2435 Add Juju charms for hadoop component Jun 3, 2016
README.md BIGTOP-2358. Update the URL for Bigtop-trunk-packages job on README Mar 14, 2016
bigtop.bom BIGTOP-2456 Update Apache Apex version to 3.4.0 Jun 14, 2016
build.gradle BIGTOP-2474: Improve handling of gradle home Jun 8, 2016
gradlew BIGTOP-2027. Bump gradle version, the wrapper to 2.7 Sep 15, 2015
packages.gradle BIGTOP-2411. Add OS-neutral wrappers to build all native packages and… Apr 28, 2016
pom.xml BIGTOP-2469: Add cloud-weather-report test plan Jun 3, 2016
release.gradle BIGTOP-2278. Wrap separate maven release steps into convenient gradle… Jan 27, 2016
settings.gradle BIGTOP-2227. smoke-tests should be a part of the top-level project, n… Jan 12, 2016

README.md

Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Apache Bigtop

...is a project for the development of packaging and tests of the Apache Hadoop ecosystem.

The primary goal of Apache Bigtop is to build a community around the packaging and interoperability testing of Apache Hadoop-related projects. This includes testing at various levels (packaging, platform, runtime, upgrade, etc...) developed by a community with a focus on the system as a whole, rather than individual projects.

Immediately Get Started with Deployment and Smoke Testing of BigTop

The simplest way to get a feel for how bigtop works, is to just cd into bigtop-deploy/vm and try out the recipes under vagrant-puppet-vm, vagrant-puppet-docker, and so on. Each one rapidly spins up, and runs the bigtop smoke tests on, a local bigtop based big data distribution. Once you get the gist, you can hack around with the recipes to learn how the puppet/rpm/smoke-tests all work together, going deeper into the components you are interested in as described below.

Quick overview of source code directories

  • bigtop-deploy : deployment scripts, puppet stuff, VM utilities for Apache Bigtop.
  • bigtop-packages : RPM/DEB specifications for Apache Bigtop subcomponents
  • bigtop-test-framework : The source code for the iTest utilities (framework used by smoke tests).
  • bigtop-tests :
  • test-artifacts : source for tests.
  • test-execution : maven pom drivers for running the integration tests found in test-artifacts.
  • bigtop-toolchain : puppet scripts for setting up an instance which can build Apache Bigtop, sets up utils like jdk/maven/protobufs/...

Also, there is a new project underway, Apache Bigtop blueprints, which aims to create templates/examples that demonstrate/compare various Apache Hadoop ecosystem components with one another.

Contributing

There are lots of ways to contribute. People with different expertise can help with various subprojects:

  • puppet : Much of the Apache Bigtop deploy and pacakging tools use puppet to bootstrap and set up a cluster. But recipes for other tools are also welcome (ie. Chef, Ansible, etc.)
  • groovy : Primary language used to write the Apache Bigtop smokes and itest framework.
  • maven : Used to build Apache Bigtop smokes and also to define the high level Apache Bigtop project.
  • RPM/DEB : Used to package Apache Hadoop ecosystem related projects into GNU/Linux installable packages for most popular GNU/Linux distributions. So one could add a new project or improve existing packages.
  • hadoop : Apache Hadoop users can also contribute by using the Apache Bigtop smokes, improving them, and evaluating their breadth.
  • contributing your workloads : Contributing your workloads enable us to tests projects against real use cases and enable you to have people verifying the use cases you care about are always working.
  • documentation : We are always in need of a better documentation!
  • giving feedback : Tell us how you use Apache Bigtop, what was great and what was not so great. Also, what are you expecting from it and what would you like to see in the future?

Also, opening JIRA's and getting started by posting on the mailing list is helpful.

CTR model

Bigtop supports Commit-Then-Review model of development. The following rules will be used for the CTR process:

  • a committer can go ahead and commit the patch without mandatory review if felt confident in its quality (e.g. reasonable testing has been done locally; all compilations pass; RAT check is passed; the patch follows coding guidelines)
  • a committer is encouraged to seek peer-review and/or advice before hand if there're doubts in the approach taken, design decision, or implementation details
  • a committer should keep an eye on the official CI builds at https://ci.bigtop.apache.org/view/Packages/job/Bigtop-trunk-packages/ (Bigtop-trunk-packages builds) to make sure that committed changes haven't break anything. In which case the committer should take a timely effort to resolve the issues and unblock the others in the community
  • any non-document patch is required to be opened for at least 24 hours for community feedback before it gets committed unless it has an explicit +1 from another committer
  • any non-document patch needs to address all the comment and reach consensus before it gets committed without a +1 from other committers
  • there's no changes in the JIRA process, except as specified above

What do people use Apache Bigtop for?

You can go to the Apache Bigtop website for notes on how to do "common" tasks like:

  • Apache Hadoop App developers: Download an Apache Bigtop built Apache Hadoop 2.0 VM from the website, so you can have a running psuedodistributed Apache Hadoop cluster to test your code on.
  • Cluster administers or deployment gurus: Run the Apache Bigtop smoke tests to ensure that your cluster is working.
  • Vendors: Build your own Apache Hadoop distribution, customized from Apache Bigtop bits.

Getting Started

Below are some recipes for getting started with using Apache Bigtop. As Apache Bigtop has different subprojects, these recipes will continue to evolve.
For specific questions it's always a good idea to ping the mailing list at dev-subscribe@bigtop.apache.org to get some immediate feedback, or open a JIRA.

For Users: Running the smoke tests.

The simplest way to test bigtop is described in bigtop-tests/smoke-tests/README file

For integration (API level) testing with maven, read on.

For Users: Running the integration tests.

WARNING: since testing packages requires installing them on a live system it is highly recommended to use VMs for that. Testing Apache Bigtop is done using iTest framework. The tests are organized in maven submodules, with one submodule per Apache Bigtop component. The bigtop-tests/test-execution/smokes/pom.xml defines all submodules to be tested, and each submodule is in its own directory under smokes/, for example:

smokes/hadoop/pom.xml smokes/hive/pom.xml ... and so on.

  • New way (with Gradle build in place)

    • Step 1: install smoke tests for one or more components

      • Example 1:

        gradle installTestArtifacts

      • Example 2: Installing just Hadoop-specific smoke tests

        gradle install-hadoop

    • Step 2: Run the the smoke tests on your cluster (see Step 3 and/or Step 4 below)

    We are on the route of migrating subprojects under top-level gradle build. Currently converted projects could be listed by running

      gradle projects
    

    To see the list of tasks in a subproject, ie itest-common, you can run

      gradle itest-common:tasks
    
  • Old Way

    • Step 1: Build the smokes with snapshots. This ensures that all transitive dependencies etc.. are in your repo

      mvn clean install -DskipTests -DskipITs -DperformRelease -f ./bigtop-test-framework/pom.xml mvn clean install -DskipTests -DskipITs -DperformRelease -f ./test-artifacts/pom.xml

    • Step 2: Now, rebuild in "offline" mode. This will make sure that your local changes to bigtop are embeded in the changes.

      mvn clean install -DskipTests -DskipITs -DperformRelease -o -nsu -f ./bigtop-test-framework/pom.xml mvn clean install -DskipTests -DskipITs -DperformRelease -o -nsu -f ./bigtop-tests/test-artifacts/pom.xml

    • Step 3: Now, you can run the smoke tests on your cluster.

      • Example 1: Running all the smoke tests with TRACE level logging (shows std out from each mr job).

        mvn clean verify -Dorg.apache.bigtop.itest.log4j.level=TRACE -f ./bigtop/bigtop-tests/test-execution/smokes/pom.xml 
        
      • Just running hadoop examples, nothing else.

        mvn clean verify -D'org.apache.maven-failsafe-plugin.testInclude=**/*TestHadoopExamples*' -f bigtop-tests/test-execution/smokes/hadoop/pom.xml
        

      Note: A minor bug/issue: you need the "testInclude" regular expression above, even if you don't want to customize the tests, since existing test names don't follow the maven integration test naming convention of IT, but instead, follow the surefire (unit test) convention of Test.

For Users: Creating Your Own Apache Hadoop Environment

Another common use case for Apache Bigtop is creating / setting up your own Apache Hadoop distribution.
For details on this, check out the bigtop-deploy/README.md file, which describes how to use the puppet repos to create and setup your VMs.
There is a current effort underway to create vagrant/docker recipes as well, which will be contained in the bigtop-deploy/ package.

For Developers: Building the entire distribution from scratch

Packages have been built for CentOS/RHEL 5 and 6, Fedora 18, SuSE Linux Enterprise 11, OpenSUSE12.2, Ubuntu LTS Lucid and Precise, and Ubuntu Quantal. They can probably be built for other platforms as well. Some of the binary artifacts might be compatible with other closely related distributions.

On all systems, Building Apache Bigtop requires certain set of tools

To bootstrap the development environment from scratch execute

./gradlew toolchain

This build task expected Puppet 3.x to be installed; user has to have sudo permissions. The task will pull down and install all development dependencies, frameworks and SDKs, required to build the stack on your platform.

  • Building packages : gradle [component-name]-[rpm|deb]

    If -Dbuildwithdeps=true is set, the Gradle will follow the order of the build specified in the "dependencies" section of bigtop.bom file. Otherwise just a single component will get build (original behavior).

    To use an alternative definition of a stack composition (aka BOM), specify its name with -Dbomfile= system property in the build time.

    You can visualize all tasks dependencies by running gradle tasks --all

  • Building local YUM/APT repositories : gradle [component-name]-[yum|apt]

  • Recommended build environments

    Bigtop provides "development in the can" environments, using Docker containers. These have the build tools set by the toolchain, as well as the user and build environment configured and cached. All currently supported OSes could be pulled from official Bigtop repository at https://hub.docker.com/r/bigtop/slaves/tags/

    To build a component (bigtop-groovy) for a particular OS (ubuntu-14.04) you can run the following from a clone of Bigtop workspace (assuming your system has Docker engine setup and working) docker run --rm -u jenkins:jenkins -v `pwd`:/ws --workdir /ws bigtop/slaves:trunk-ubuntu-14.04 bash -l -c './gradlew allclean ; ./gradlew bigtop-groovy-pkg'

For Developers: Building and modifying the web site

The website can be built by running mvn site:site from the root directory of the project. The main page can be accessed from "project_root/target/site/index.html".

The source for the website is located in "project_root/src/site/".

For Developers: Building a component from Git repository

To fetch source from a Git repository you need to modify bigtop.mk and add the following fields to your package:

  • _GIT_REPO - SSH, HTTP or local path to Git repo.
  • _GIT_REF - branch, tag or commit hash to check out.

Some packages have different names for source directory and source tarball (hbase-0.98.5-src.tar.gz contains hbase-0.98.5 directory). By default source will be fetched in a directory named _TARBALL_SRC without .t* extension. To explicitly set directory name use the _GIT_DIR option.

Example for HBase:

HBASE_GIT_REPO=https://github.com/apache/hbase.git
HBASE_GIT_REF=$(HBASE_PKG_VERSION)
HBASE_GIT_DIR=hbase-$(HBASE_PKG_VERSION)

Contact us

You can get in touch with us on the Apache Bigtop mailing lists.