Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-dev@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F328F5E.7090006@apache.org>
Date: Wed, 08 Feb 2012 15:06:06 +0000
From: Steve Loughran <stevel@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
MIME-Version: 1.0
To: hdfs-dev@hadoop.apache.org
Subject: Re: [PROPOSAL] Hadoop OSGi compliant and Apache Karaf features
References: <4F3285F1.2000704@nanthrax.net>
In-Reply-To: <4F3285F1.2000704@nanthrax.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 08/02/12 14:25, Jean-Baptiste Onofr� wrote:
> Hi folks,
>
> I'm working right now to turn Hadoop as an OSGi compliant set of modules.
>
> I've more or less achieved the first step:
> - turn all Hadoop modules (common, annotations, hdfs, mapreduce, etc) as
> OSGi bundle
> - provide a Karaf features descriptor to easily deploy it into Apache
> Karaf OSGi container
>
> I will upload the patches on the different Jira related to that.
>
> The second step that I propose is to introduce blueprint descriptor in
> order to expose some Hadoop features as OSGi services.
> It won't affect the "non-OSGi" users but give lot of fun and interest
> for OSGi users ;)
>

Zookeeper would be nice too, as you could bring up a very small cluster

As I mentioned in one of the JIRA comments

-there are a lot of calls to System.exit() in Hadoop when it isn't 
happy, you need a security manager to catch them and turn them into 
exceptions -and no, the code doesn't expect exceptions everywhere.

-There are a lot of assumptions that every service (namenode, datanode, 
etc) is running in its own VM, with its own singletons. They will all 
need their own classloaders, which implies separate OSGi bundles for 
each public service.

YARN is even more interesting, as it works by deploying the application 
master (such as the MR engine) on request, picking a suitable node and 
executing the entry point with a classpath (somehow) set up. If you are 
going to work with trunk you will need to address this, the simplest 
tactic being "don't try and run YARN-based services under OSGi, just the 
YARN Resource Manager and Node Managers itself";

A more advanced options "support OSGi-based YARN services specially", 
would also be good if it could start both Application Masters and their 
container applications themselves (Task Trackers &c), and aided the 
execution of things like actual tasks within the OSGi container (for 
speed).

If you are looking a production use of this stuff, you'll need to worry 
about loading of the native libraries too. Otherwise this becomes more 
restricted to experimental-small-machine setups.