[
https://issues.apache.org/jira/browse/HBASE-12721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407233#comment-15407233
]
Dima Spivak commented on HBASE-12721:
-------------------------------------
Since I last posted here, I've done a lot of thinking about the best way to
contribute this to HBase. I've always felt a bit funny about having the whole
{{clusterdock}} framework live in HBase proper, since only the {{apache_hbase}}
topology part has anything to do with HBase, so I think I've come up with a
better way to let us use this while not bloating {{dev-support}}. Long story
short, we've put up the {{clusterdock}} framework in [Cloudera's
GitHub|https://github.com/cloudera/clusterdock] and pushed images of the
framework into [Docker Hub|https://hub.docker.com/r/cloudera/clusterdock/]. The
framework now supports use of topologies that are not part of the actual
framework through Docker's data volume functionality. That is, instead of
needing to keep one copy of the framework for our Cloudera CDH stuff, and then
a duplicate copy in Apache HBase, I propose we let the framework live in our
Cloudera Docker registry, and then only commit the {{apache_hbase}} topology,
which can then be used with the framework.
Does that make sense? Would an example help anyone still following this?
> Create Docker container cluster infrastructure to enable better testing
> -----------------------------------------------------------------------
>
> Key: HBASE-12721
> URL: https://issues.apache.org/jira/browse/HBASE-12721
> Project: HBase
> Issue Type: New Feature
> Components: build, community, documentation, test
> Reporter: Dima Spivak
> Assignee: Dima Spivak
>
> Some simple work on using HBase with Docker was committed into /dev-support
> as "hbase_docker;" all this did was stand up a standalone cluster from source
> and start a shell. Now seems like a good time to extend this to be useful for
> applications that could actual benefit the community, especially around
> testing. Some ideas:
> - Integration testing would be much more accessible if people could stand up
> distributed HBase clusters on a single host machine in a couple minutes and
> run our awesome hbase-it suite against it.
> - Binary compatibility testing of an HBase client is easiest when standing up
> an HBase cluster can be done once and then different client source/binary
> permutations run against it.
> - Upgrade testing, and especially rolling upgrade testing, doesn't have any
> upstream automation on build.apache.org, in part because it's a pain to set
> up x-node clusters on Apache infrastructure.
> This proposal, whether it stays under /dev-support or moves out into it's own
> top-level module ("hbase-docker" would conveniently fit the existing schema
> :-)), strives to create a simple framework for deploying "distributed,"
> multi-container Apache HBase clusters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
