You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Alejandro Abdelnur <tu...@cloudera.com> on 2011/10/12 18:07:45 UTC
0.23 & trunk tars, we'll we publishing 1 tar per component or a
single tar? What about source tar?
Currently common, hdfs and mapred create partial tars which are not usable
unless they are stitched together into a single tar.
With HADOOP-7642 the stitching happens as part of the build.
The build currently produces the following tars:
1* common TAR
2* hdfs (partial) TAR
3* mapreduce (partial) TAR
4* hadoop (full, the stitched one) TAR
#1 on its own does not run anything, #2 and #3 on their own don't run. #4
runs hdfs & mapreduce.
Questions:
Q1. Does it make sense to publish #1, #2 & #3? Or #4 is sufficient and you
start the services you want (i.e. Hbase would just use HDFS)?
Q2. And what about a source TAR, does it make sense to have source TAR per
component or a single TAR for the whole?
For simplicity (for the build system and for users) I'd prefer a single
binary TAR and a single source TAR.
Thanks.
Alejandro
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a
single tar? What about source tar?
Posted by Tom White <to...@cloudera.com>.
I think it's simplest to publish a single Hadoop tarball and users
start the services they want. This is the model we have always
followed up to now.
Cheers,
Tom
On Wed, Oct 12, 2011 at 9:07 AM, Alejandro Abdelnur <tu...@cloudera.com> wrote:
> Currently common, hdfs and mapred create partial tars which are not usable
> unless they are stitched together into a single tar.
>
> With HADOOP-7642 the stitching happens as part of the build.
>
> The build currently produces the following tars:
>
> 1* common TAR
> 2* hdfs (partial) TAR
> 3* mapreduce (partial) TAR
> 4* hadoop (full, the stitched one) TAR
>
> #1 on its own does not run anything, #2 and #3 on their own don't run. #4
> runs hdfs & mapreduce.
>
> Questions:
>
> Q1. Does it make sense to publish #1, #2 & #3? Or #4 is sufficient and you
> start the services you want (i.e. Hbase would just use HDFS)?
>
> Q2. And what about a source TAR, does it make sense to have source TAR per
> component or a single TAR for the whole?
>
>
> For simplicity (for the build system and for users) I'd prefer a single
> binary TAR and a single source TAR.
>
> Thanks.
>
> Alejandro
>
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or
a single tar? What about source tar?
Posted by Doug Cutting <cu...@apache.org>.
On 10/12/2011 09:07 AM, Alejandro Abdelnur wrote:
> For simplicity (for the build system and for users) I'd prefer a single
> binary TAR and a single source TAR.
All that is required for a release is a single source TAR. As an
open-source project our product is source code. We may also distribute
some derivative binary artifacts as conveniences, but those can be added
to the distribution directory by other committers after the release vote
as desired.
So it's fine if folks want to include, e.g., an HDFS-only binary package
for 64-bit linux that's convenient for sites that only wish to run HBase
and never run mapreduce jobs, but that's not what we should vote on.
Rather voters should evaluate sources.
I am +1 for creating a single source tarball for the entire release and
+0 for creating any number of binary tarballs for various subsets,
platforms, etc.
Doug
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a
single tar? What about source tar?
Posted by Uma Maheswara Rao G 72686 <ma...@huawei.com>.
+1 for option 4.
Let the User starts required services from it.
Regards,
Uma
----- Original Message -----
From: giridharan kesavan <gk...@hortonworks.com>
Date: Wednesday, October 12, 2011 11:24 pm
Subject: Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
To: hdfs-dev@hadoop.apache.org
Cc: Eric Yang <er...@gmail.com>, mapreduce-dev@hadoop.apache.org, common-dev@hadoop.apache.org
> +1 for option 4
>
>
> On 10/12/11 9:50 AM, Eric Yang wrote:
> > Option #4 is the most practical use case for making a release.
> For bleeding edge developers, they would prefer to mix and match
> different version of hdfs and mapreduce. Hence, it may be good to
> release the single tarball for release, but continue to support
> component tarballs for developers and rpm/deb packaging. In case,
> someone wants to run hdfs + hbase, but not mapreduce for
> specialized application. Component separation tarball should
> continue to work for rpm/deb packaging.
> >
> > regards,
> > Eric
> >
> > On Oct 12, 2011, at 9:30 AM, Prashant Sharma wrote:
> >
> >> I support the idea of having 4 as additional option.
> >>
> >> On Wed, Oct 12, 2011 at 9:37 PM, Alejandro
> Abdelnur<tu...@cloudera.com> wrote:
> >>> Currently common, hdfs and mapred create partial tars which
> are not usable
> >>> unless they are stitched together into a single tar.
> >>>
> >>> With HADOOP-7642 the stitching happens as part of the build.
> >>>
> >>> The build currently produces the following tars:
> >>>
> >>> 1* common TAR
> >>> 2* hdfs (partial) TAR
> >>> 3* mapreduce (partial) TAR
> >>> 4* hadoop (full, the stitched one) TAR
> >>>
> >>> #1 on its own does not run anything, #2 and #3 on their own
> don't run. #4
> >>> runs hdfs& mapreduce.
> >>>
> >>> Questions:
> >>>
> >>> Q1. Does it make sense to publish #1, #2& #3? Or #4 is
> sufficient and you
> >>> start the services you want (i.e. Hbase would just use HDFS)?
> >>>
> >>> Q2. And what about a source TAR, does it make sense to have
> source TAR per
> >>> component or a single TAR for the whole?
> >>>
> >>>
> >>> For simplicity (for the build system and for users) I'd prefer
> a single
> >>> binary TAR and a single source TAR.
> >>>
> >>> Thanks.
> >>>
> >>> Alejandro
> >>>
> >>
> >>
> >> --
> >>
> >> Prashant Sharma
> >> Pramati Technologies
> >> Begumpet, Hyderabad.
> >
>
>
> --
> -Giri
>
>
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a
single tar? What about source tar?
Posted by Uma Maheswara Rao G 72686 <ma...@huawei.com>.
+1 for option 4.
Let the User starts required services from it.
Regards,
Uma
----- Original Message -----
From: giridharan kesavan <gk...@hortonworks.com>
Date: Wednesday, October 12, 2011 11:24 pm
Subject: Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
To: hdfs-dev@hadoop.apache.org
Cc: Eric Yang <er...@gmail.com>, mapreduce-dev@hadoop.apache.org, common-dev@hadoop.apache.org
> +1 for option 4
>
>
> On 10/12/11 9:50 AM, Eric Yang wrote:
> > Option #4 is the most practical use case for making a release.
> For bleeding edge developers, they would prefer to mix and match
> different version of hdfs and mapreduce. Hence, it may be good to
> release the single tarball for release, but continue to support
> component tarballs for developers and rpm/deb packaging. In case,
> someone wants to run hdfs + hbase, but not mapreduce for
> specialized application. Component separation tarball should
> continue to work for rpm/deb packaging.
> >
> > regards,
> > Eric
> >
> > On Oct 12, 2011, at 9:30 AM, Prashant Sharma wrote:
> >
> >> I support the idea of having 4 as additional option.
> >>
> >> On Wed, Oct 12, 2011 at 9:37 PM, Alejandro
> Abdelnur<tu...@cloudera.com> wrote:
> >>> Currently common, hdfs and mapred create partial tars which
> are not usable
> >>> unless they are stitched together into a single tar.
> >>>
> >>> With HADOOP-7642 the stitching happens as part of the build.
> >>>
> >>> The build currently produces the following tars:
> >>>
> >>> 1* common TAR
> >>> 2* hdfs (partial) TAR
> >>> 3* mapreduce (partial) TAR
> >>> 4* hadoop (full, the stitched one) TAR
> >>>
> >>> #1 on its own does not run anything, #2 and #3 on their own
> don't run. #4
> >>> runs hdfs& mapreduce.
> >>>
> >>> Questions:
> >>>
> >>> Q1. Does it make sense to publish #1, #2& #3? Or #4 is
> sufficient and you
> >>> start the services you want (i.e. Hbase would just use HDFS)?
> >>>
> >>> Q2. And what about a source TAR, does it make sense to have
> source TAR per
> >>> component or a single TAR for the whole?
> >>>
> >>>
> >>> For simplicity (for the build system and for users) I'd prefer
> a single
> >>> binary TAR and a single source TAR.
> >>>
> >>> Thanks.
> >>>
> >>> Alejandro
> >>>
> >>
> >>
> >> --
> >>
> >> Prashant Sharma
> >> Pramati Technologies
> >> Begumpet, Hyderabad.
> >
>
>
> --
> -Giri
>
>
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a
single tar? What about source tar?
Posted by Uma Maheswara Rao G 72686 <ma...@huawei.com>.
+1 for option 4.
Let the User starts required services from it.
Regards,
Uma
----- Original Message -----
From: giridharan kesavan <gk...@hortonworks.com>
Date: Wednesday, October 12, 2011 11:24 pm
Subject: Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
To: hdfs-dev@hadoop.apache.org
Cc: Eric Yang <er...@gmail.com>, mapreduce-dev@hadoop.apache.org, common-dev@hadoop.apache.org
> +1 for option 4
>
>
> On 10/12/11 9:50 AM, Eric Yang wrote:
> > Option #4 is the most practical use case for making a release.
> For bleeding edge developers, they would prefer to mix and match
> different version of hdfs and mapreduce. Hence, it may be good to
> release the single tarball for release, but continue to support
> component tarballs for developers and rpm/deb packaging. In case,
> someone wants to run hdfs + hbase, but not mapreduce for
> specialized application. Component separation tarball should
> continue to work for rpm/deb packaging.
> >
> > regards,
> > Eric
> >
> > On Oct 12, 2011, at 9:30 AM, Prashant Sharma wrote:
> >
> >> I support the idea of having 4 as additional option.
> >>
> >> On Wed, Oct 12, 2011 at 9:37 PM, Alejandro
> Abdelnur<tu...@cloudera.com> wrote:
> >>> Currently common, hdfs and mapred create partial tars which
> are not usable
> >>> unless they are stitched together into a single tar.
> >>>
> >>> With HADOOP-7642 the stitching happens as part of the build.
> >>>
> >>> The build currently produces the following tars:
> >>>
> >>> 1* common TAR
> >>> 2* hdfs (partial) TAR
> >>> 3* mapreduce (partial) TAR
> >>> 4* hadoop (full, the stitched one) TAR
> >>>
> >>> #1 on its own does not run anything, #2 and #3 on their own
> don't run. #4
> >>> runs hdfs& mapreduce.
> >>>
> >>> Questions:
> >>>
> >>> Q1. Does it make sense to publish #1, #2& #3? Or #4 is
> sufficient and you
> >>> start the services you want (i.e. Hbase would just use HDFS)?
> >>>
> >>> Q2. And what about a source TAR, does it make sense to have
> source TAR per
> >>> component or a single TAR for the whole?
> >>>
> >>>
> >>> For simplicity (for the build system and for users) I'd prefer
> a single
> >>> binary TAR and a single source TAR.
> >>>
> >>> Thanks.
> >>>
> >>> Alejandro
> >>>
> >>
> >>
> >> --
> >>
> >> Prashant Sharma
> >> Pramati Technologies
> >> Begumpet, Hyderabad.
> >
>
>
> --
> -Giri
>
>
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or
a single tar? What about source tar?
Posted by giridharan kesavan <gk...@hortonworks.com>.
+1 for option 4
On 10/12/11 9:50 AM, Eric Yang wrote:
> Option #4 is the most practical use case for making a release. For bleeding edge developers, they would prefer to mix and match different version of hdfs and mapreduce. Hence, it may be good to release the single tarball for release, but continue to support component tarballs for developers and rpm/deb packaging. In case, someone wants to run hdfs + hbase, but not mapreduce for specialized application. Component separation tarball should continue to work for rpm/deb packaging.
>
> regards,
> Eric
>
> On Oct 12, 2011, at 9:30 AM, Prashant Sharma wrote:
>
>> I support the idea of having 4 as additional option.
>>
>> On Wed, Oct 12, 2011 at 9:37 PM, Alejandro Abdelnur<tu...@cloudera.com> wrote:
>>> Currently common, hdfs and mapred create partial tars which are not usable
>>> unless they are stitched together into a single tar.
>>>
>>> With HADOOP-7642 the stitching happens as part of the build.
>>>
>>> The build currently produces the following tars:
>>>
>>> 1* common TAR
>>> 2* hdfs (partial) TAR
>>> 3* mapreduce (partial) TAR
>>> 4* hadoop (full, the stitched one) TAR
>>>
>>> #1 on its own does not run anything, #2 and #3 on their own don't run. #4
>>> runs hdfs& mapreduce.
>>>
>>> Questions:
>>>
>>> Q1. Does it make sense to publish #1, #2& #3? Or #4 is sufficient and you
>>> start the services you want (i.e. Hbase would just use HDFS)?
>>>
>>> Q2. And what about a source TAR, does it make sense to have source TAR per
>>> component or a single TAR for the whole?
>>>
>>>
>>> For simplicity (for the build system and for users) I'd prefer a single
>>> binary TAR and a single source TAR.
>>>
>>> Thanks.
>>>
>>> Alejandro
>>>
>>
>>
>> --
>>
>> Prashant Sharma
>> Pramati Technologies
>> Begumpet, Hyderabad.
>
--
-Giri
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or
a single tar? What about source tar?
Posted by giridharan kesavan <gk...@hortonworks.com>.
+1 for option 4
On 10/12/11 9:50 AM, Eric Yang wrote:
> Option #4 is the most practical use case for making a release. For bleeding edge developers, they would prefer to mix and match different version of hdfs and mapreduce. Hence, it may be good to release the single tarball for release, but continue to support component tarballs for developers and rpm/deb packaging. In case, someone wants to run hdfs + hbase, but not mapreduce for specialized application. Component separation tarball should continue to work for rpm/deb packaging.
>
> regards,
> Eric
>
> On Oct 12, 2011, at 9:30 AM, Prashant Sharma wrote:
>
>> I support the idea of having 4 as additional option.
>>
>> On Wed, Oct 12, 2011 at 9:37 PM, Alejandro Abdelnur<tu...@cloudera.com> wrote:
>>> Currently common, hdfs and mapred create partial tars which are not usable
>>> unless they are stitched together into a single tar.
>>>
>>> With HADOOP-7642 the stitching happens as part of the build.
>>>
>>> The build currently produces the following tars:
>>>
>>> 1* common TAR
>>> 2* hdfs (partial) TAR
>>> 3* mapreduce (partial) TAR
>>> 4* hadoop (full, the stitched one) TAR
>>>
>>> #1 on its own does not run anything, #2 and #3 on their own don't run. #4
>>> runs hdfs& mapreduce.
>>>
>>> Questions:
>>>
>>> Q1. Does it make sense to publish #1, #2& #3? Or #4 is sufficient and you
>>> start the services you want (i.e. Hbase would just use HDFS)?
>>>
>>> Q2. And what about a source TAR, does it make sense to have source TAR per
>>> component or a single TAR for the whole?
>>>
>>>
>>> For simplicity (for the build system and for users) I'd prefer a single
>>> binary TAR and a single source TAR.
>>>
>>> Thanks.
>>>
>>> Alejandro
>>>
>>
>>
>> --
>>
>> Prashant Sharma
>> Pramati Technologies
>> Begumpet, Hyderabad.
>
--
-Giri
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or
a single tar? What about source tar?
Posted by giridharan kesavan <gk...@hortonworks.com>.
+1 for option 4
On 10/12/11 9:50 AM, Eric Yang wrote:
> Option #4 is the most practical use case for making a release. For bleeding edge developers, they would prefer to mix and match different version of hdfs and mapreduce. Hence, it may be good to release the single tarball for release, but continue to support component tarballs for developers and rpm/deb packaging. In case, someone wants to run hdfs + hbase, but not mapreduce for specialized application. Component separation tarball should continue to work for rpm/deb packaging.
>
> regards,
> Eric
>
> On Oct 12, 2011, at 9:30 AM, Prashant Sharma wrote:
>
>> I support the idea of having 4 as additional option.
>>
>> On Wed, Oct 12, 2011 at 9:37 PM, Alejandro Abdelnur<tu...@cloudera.com> wrote:
>>> Currently common, hdfs and mapred create partial tars which are not usable
>>> unless they are stitched together into a single tar.
>>>
>>> With HADOOP-7642 the stitching happens as part of the build.
>>>
>>> The build currently produces the following tars:
>>>
>>> 1* common TAR
>>> 2* hdfs (partial) TAR
>>> 3* mapreduce (partial) TAR
>>> 4* hadoop (full, the stitched one) TAR
>>>
>>> #1 on its own does not run anything, #2 and #3 on their own don't run. #4
>>> runs hdfs& mapreduce.
>>>
>>> Questions:
>>>
>>> Q1. Does it make sense to publish #1, #2& #3? Or #4 is sufficient and you
>>> start the services you want (i.e. Hbase would just use HDFS)?
>>>
>>> Q2. And what about a source TAR, does it make sense to have source TAR per
>>> component or a single TAR for the whole?
>>>
>>>
>>> For simplicity (for the build system and for users) I'd prefer a single
>>> binary TAR and a single source TAR.
>>>
>>> Thanks.
>>>
>>> Alejandro
>>>
>>
>>
>> --
>>
>> Prashant Sharma
>> Pramati Technologies
>> Begumpet, Hyderabad.
>
--
-Giri
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
Posted by Eric Yang <er...@gmail.com>.
Option #4 is the most practical use case for making a release. For bleeding edge developers, they would prefer to mix and match different version of hdfs and mapreduce. Hence, it may be good to release the single tarball for release, but continue to support component tarballs for developers and rpm/deb packaging. In case, someone wants to run hdfs + hbase, but not mapreduce for specialized application. Component separation tarball should continue to work for rpm/deb packaging.
regards,
Eric
On Oct 12, 2011, at 9:30 AM, Prashant Sharma wrote:
> I support the idea of having 4 as additional option.
>
> On Wed, Oct 12, 2011 at 9:37 PM, Alejandro Abdelnur <tu...@cloudera.com> wrote:
>> Currently common, hdfs and mapred create partial tars which are not usable
>> unless they are stitched together into a single tar.
>>
>> With HADOOP-7642 the stitching happens as part of the build.
>>
>> The build currently produces the following tars:
>>
>> 1* common TAR
>> 2* hdfs (partial) TAR
>> 3* mapreduce (partial) TAR
>> 4* hadoop (full, the stitched one) TAR
>>
>> #1 on its own does not run anything, #2 and #3 on their own don't run. #4
>> runs hdfs & mapreduce.
>>
>> Questions:
>>
>> Q1. Does it make sense to publish #1, #2 & #3? Or #4 is sufficient and you
>> start the services you want (i.e. Hbase would just use HDFS)?
>>
>> Q2. And what about a source TAR, does it make sense to have source TAR per
>> component or a single TAR for the whole?
>>
>>
>> For simplicity (for the build system and for users) I'd prefer a single
>> binary TAR and a single source TAR.
>>
>> Thanks.
>>
>> Alejandro
>>
>
>
>
> --
>
> Prashant Sharma
> Pramati Technologies
> Begumpet, Hyderabad.
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a
single tar? What about source tar?
Posted by Prashant Sharma <pr...@gmail.com>.
I support the idea of having 4 as additional option.
On Wed, Oct 12, 2011 at 9:37 PM, Alejandro Abdelnur <tu...@cloudera.com> wrote:
> Currently common, hdfs and mapred create partial tars which are not usable
> unless they are stitched together into a single tar.
>
> With HADOOP-7642 the stitching happens as part of the build.
>
> The build currently produces the following tars:
>
> 1* common TAR
> 2* hdfs (partial) TAR
> 3* mapreduce (partial) TAR
> 4* hadoop (full, the stitched one) TAR
>
> #1 on its own does not run anything, #2 and #3 on their own don't run. #4
> runs hdfs & mapreduce.
>
> Questions:
>
> Q1. Does it make sense to publish #1, #2 & #3? Or #4 is sufficient and you
> start the services you want (i.e. Hbase would just use HDFS)?
>
> Q2. And what about a source TAR, does it make sense to have source TAR per
> component or a single TAR for the whole?
>
>
> For simplicity (for the build system and for users) I'd prefer a single
> binary TAR and a single source TAR.
>
> Thanks.
>
> Alejandro
>
--
Prashant Sharma
Pramati Technologies
Begumpet, Hyderabad.
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
Posted by Bharath Mundlapudi <bh...@yahoo.com>.
Other approach would be asking which tar to build.
mapred-tar (mapred and common)
hdfs-tar (hdfs and common)
hadoop-tar (all)
In this case, hbase can just use hdfs-tar.
-Bharath
________________________________
From: Ravi Teja <ra...@huawei.com>
To: mapreduce-dev@hadoop.apache.org; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Sent: Wednesday, October 12, 2011 9:43 PM
Subject: RE: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
I feel #4 as a better option.
Regards,
Ravi Teja
-----Original Message-----
From: Alejandro Abdelnur [mailto:tucu@cloudera.com]
Sent: Wednesday, October 12, 2011 9:38 PM
To: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
hdfs-dev@hadoop.apache.org
Subject: 0.23 & trunk tars, we'll we publishing 1 tar per component or a
single tar? What about source tar?
Currently common, hdfs and mapred create partial tars which are not usable
unless they are stitched together into a single tar.
With HADOOP-7642 the stitching happens as part of the build.
The build currently produces the following tars:
1* common TAR
2* hdfs (partial) TAR
3* mapreduce (partial) TAR
4* hadoop (full, the stitched one) TAR
#1 on its own does not run anything, #2 and #3 on their own don't run. #4
runs hdfs & mapreduce.
Questions:
Q1. Does it make sense to publish #1, #2 & #3? Or #4 is sufficient and you
start the services you want (i.e. Hbase would just use HDFS)?
Q2. And what about a source TAR, does it make sense to have source TAR per
component or a single TAR for the whole?
For simplicity (for the build system and for users) I'd prefer a single
binary TAR and a single source TAR.
Thanks.
Alejandro
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
Posted by Bharath Mundlapudi <bh...@yahoo.com>.
Other approach would be asking which tar to build.
mapred-tar (mapred and common)
hdfs-tar (hdfs and common)
hadoop-tar (all)
In this case, hbase can just use hdfs-tar.
-Bharath
________________________________
From: Ravi Teja <ra...@huawei.com>
To: mapreduce-dev@hadoop.apache.org; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Sent: Wednesday, October 12, 2011 9:43 PM
Subject: RE: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
I feel #4 as a better option.
Regards,
Ravi Teja
-----Original Message-----
From: Alejandro Abdelnur [mailto:tucu@cloudera.com]
Sent: Wednesday, October 12, 2011 9:38 PM
To: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
hdfs-dev@hadoop.apache.org
Subject: 0.23 & trunk tars, we'll we publishing 1 tar per component or a
single tar? What about source tar?
Currently common, hdfs and mapred create partial tars which are not usable
unless they are stitched together into a single tar.
With HADOOP-7642 the stitching happens as part of the build.
The build currently produces the following tars:
1* common TAR
2* hdfs (partial) TAR
3* mapreduce (partial) TAR
4* hadoop (full, the stitched one) TAR
#1 on its own does not run anything, #2 and #3 on their own don't run. #4
runs hdfs & mapreduce.
Questions:
Q1. Does it make sense to publish #1, #2 & #3? Or #4 is sufficient and you
start the services you want (i.e. Hbase would just use HDFS)?
Q2. And what about a source TAR, does it make sense to have source TAR per
component or a single TAR for the whole?
For simplicity (for the build system and for users) I'd prefer a single
binary TAR and a single source TAR.
Thanks.
Alejandro
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
Posted by Bharath Mundlapudi <bh...@yahoo.com>.
Other approach would be asking which tar to build.
mapred-tar (mapred and common)
hdfs-tar (hdfs and common)
hadoop-tar (all)
In this case, hbase can just use hdfs-tar.
-Bharath
________________________________
From: Ravi Teja <ra...@huawei.com>
To: mapreduce-dev@hadoop.apache.org; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Sent: Wednesday, October 12, 2011 9:43 PM
Subject: RE: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
I feel #4 as a better option.
Regards,
Ravi Teja
-----Original Message-----
From: Alejandro Abdelnur [mailto:tucu@cloudera.com]
Sent: Wednesday, October 12, 2011 9:38 PM
To: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
hdfs-dev@hadoop.apache.org
Subject: 0.23 & trunk tars, we'll we publishing 1 tar per component or a
single tar? What about source tar?
Currently common, hdfs and mapred create partial tars which are not usable
unless they are stitched together into a single tar.
With HADOOP-7642 the stitching happens as part of the build.
The build currently produces the following tars:
1* common TAR
2* hdfs (partial) TAR
3* mapreduce (partial) TAR
4* hadoop (full, the stitched one) TAR
#1 on its own does not run anything, #2 and #3 on their own don't run. #4
runs hdfs & mapreduce.
Questions:
Q1. Does it make sense to publish #1, #2 & #3? Or #4 is sufficient and you
start the services you want (i.e. Hbase would just use HDFS)?
Q2. And what about a source TAR, does it make sense to have source TAR per
component or a single TAR for the whole?
For simplicity (for the build system and for users) I'd prefer a single
binary TAR and a single source TAR.
Thanks.
Alejandro