hadoop-common-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: debian package of hadoop
Date Thu, 07 Jan 2010 23:41:09 GMT
As for your
2) to deploy small clusters
I think that is outside the scope of packaging. Take mysql for
example. you could configure mysql to be master/slave or even
master/master. That is all done through the configuration not through
the package.

The hadoop configuration is very dependent on hostnames nn,jt,snn,(dn)
disks mounted outside of root. So I don't think you should package up
the logic to auto deploy a cluster of any size, if that was what you
were implying.


On Thu, Jan 7, 2010 at 6:30 PM, Jordà Polo <jorda@ettin.org> wrote:
> On Mon, Jan 04, 2010 at 12:37:48PM +0000, Steve Loughran wrote:
>> If you want "official" as in can say "Apache Hadoop" on it, then it
>> will need to be managed and released as an apache project. That
>> means somewhere in ASF SVN. If you want to cut your own, please give
>> it a different name to avoid problems later.
> I actually meant "official" as in "Debian official", that is, a package
> that is compatible with the Debian policies and follows the standard
> best practices, and thus is able to be included in the official Debian
> distribution. (Note that I come from the Debian side where I maintain a
> few packages. Sorry about the misunderstanding, I took that for
> granted.)
>> Well, we'll just have to ignore the debian autobuilding process
>> then, won't we?
>> There are some hooks in Ivy and Ant to give local machine artifacts
>> priority over other stuff, but it's not ideal. Let's just say there
>> are differences in opinion between some of the linux packaging
>> people and others as to what is the correct way to manage
>> dependencies. I'm in the "everything is specified under SCM" camp;
>> others are in the "build against what you find" world.
> Well, if you want an official Debian package, you can't really ignore
> the autobuilding process, but that's not necessarily a problem. I mean,
> you only need to take it into account when building the official
> package, not your customized packages.
> So, for the initial versions of this "official Debian package" I was
> thinking of the following use cases: 1) developers that need the
> libraries and maybe even to test applications locally, 2) to deploy
> small clusters, and 3) as a base _source_ package that can be customized
> and rebuilt for larger environments. IMHO, an official Debian package
> would be worth it even if it only provides 1 and 2.
>> >(Anyway, I'm interested in the package, so let me know if you need some
>> >help and want to set up a group on alioth or something.)
>> A lot of the fun here is not going to be setting up the package files (
> Hmm, I'm not sure what you mean, but I'm don't think my sentence was
> correctly understood either, so I'll try to put it into context: Debian
> packages can be either maintained by a single maintainer or by a group
> of them. Alioth[1] is a project-management service used mostly for
> Debian-related projects (such as packages). An Alioth project could be
> useful to create a mailing list and deal with Debian-specific bug
> reports and packaging issues (which are off-topic here).
>  1. http://alioth.debian.org/

View raw message