You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Nick Dimiduk <nd...@gmail.com> on 2016/06/03 00:30:17 UTC
[DISCUSS] Include Deb and RPM packages in releases
Heya folks,
Per the title, what do you think about generating more easily consumed
artifacts in our releases? We already do all the hard parts of generating
binary packages and signing them. Seems like a simple extension to add some
additional convenience artifacts. Other Apache projects do this, including
hosting release repositories.
Our story is made a little more complex due to dependencies on ZK and HDFS,
but I think we could make a strong argument for helping those projects
produce the same for their users.
IMHO, by not building these (and not providing init scripts, and so on),
we're basically telling our users they shouldn't use Apache releases in
prod.
For reference:
- https://github.com/tcurdt/jdeb#debian-packages-in-java
- https://github.com/OpenTSDB/opentsdb/tree/master/build-aux
- https://github.com/OpenTSDB/tcollector/tree/master/debian
- http://wiki.apache.org/cassandra/DebianPackaging
-n
Re: [DISCUSS] Include Deb and RPM packages in releases
Posted by Andrew Purtell <ap...@apache.org>.
> That sounds like a custom version of Bigtop to me?
Not quite, I think. More like a make-your-own HBase "convenience" artifact
script, producing tarballs instead of rpm/deb, only dealing with HBase
runtime matters, none of the additional cognitive load that Bigtop would
bring.
On Mon, Jun 6, 2016 at 12:28 PM, Mikhail Antonov <ol...@gmail.com>
wrote:
> "It might be more useful to produce a script that, given a set of versions
> for { Hadoop, HBase, ZK } downloads the respective tarballs and stitches
> together a HBase deployment tarball with all necessary jar substitutions
> made, and perhaps the copy of Hadoop native library artifacts into the
> expected location under HBase's lib, etc. If that still seems like too much
> work for someone, I don't have a good answer for that."
>
> That sounds like a custom version of Bigtop to me? Might if we want to
> actively encourage more people to use
> Apache distribution of HBase making a specialized "HBase-centric" (?)
> Puppet recipe in Bigtop or something similar is the proper way to address
> it.
>
> -Mikhail
>
> On Mon, Jun 6, 2016 at 12:03 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I forgot to mention that, IMHO, Dima's work with Docker is more likely to
> > produce useful artifacts for folks looking to kick the tires. Related,
> > perhaps the creation of a Vagrant box would be useful.
> >
> >
> > On Mon, Jun 6, 2016 at 11:38 AM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > >> IMHO, by not building these (and not providing init scripts, and so
> > on),
> > > >> we're basically telling our users they shouldn't use Apache releases
> > in
> > > >> prod.
> > > > I do agree with this sentiment, FWIW. not providing good
> > > > last-mile-to-deployment tools is a recurring issue we have.
> > >
> > > I agree with Sean's way of stating the problem. The "telling our users
> > > they shouldn't use Apache releases in prod" is an exaggeration at best
> > and
> > > definitely something I do not agree with at all. There is nowhere in
> our
> > > documentation we make this statement. A whole constellation of Apache
> > > projects release software as source - some source-only - and binary
> > > "convenience" tarballs and as far as I know none have ever made this
> > claim
> > > anywhere ever, except when releasing "developer preview" or "alpha" or
> > > "beta" versions and such, as you would expect.
> > >
> > > That said, I put 'convenience' in scare quotes because the bundled
> binary
> > > artifacts are of varying utility depending on what constellation of
> > > software versions you want to comprise your runtime. Those may be
> > different
> > > than the choices we made when building the "convenience" artifact. So,
> > this
> > > is open source, build it yourself to the specifications you need. All
> > > Apache projects produce source as the primary, and often only, user
> > > consumable. This is where Apache Bigtop's build harness can provide
> value
> > > for the DIY crowd, or where a vendor can provide value - if the
> would-be
> > > user simply can't be bothered to learn how to consume open source
> > artifacts
> > > from a volunteer open source project. I personally take a dim view of
> > such
> > > "users": very unlikely to contribute anything back, and likely to be
> > > entitled assholes and a parasitic drain on volunteer time if they do
> make
> > > an appearance.
> > >
> > > I'm not saying not to invest time and energy in maven targets for
> > rpm/deb,
> > > if that's an itch someone wants to scratch, but user mileage will vary
> > with
> > > those in just the same way as our tarballs, unless we produce a number
> of
> > > RPMs using a matrix of Hadoop (and possibly ZK) versions.
> > >
> > > It might be more useful to produce a script that, given a set of
> versions
> > > for { Hadoop, HBase, ZK } downloads the respective tarballs and
> stitches
> > > together a HBase deployment tarball with all necessary jar
> substitutions
> > > made, and perhaps the copy of Hadoop native library artifacts into the
> > > expected location under HBase's lib, etc. If that still seems like too
> > much
> > > work for someone, I don't have a good answer for that.
> > >
> > >
> > >
> > > On Mon, Jun 6, 2016 at 11:03 AM, Sean Busbey <bu...@cloudera.com>
> > wrote:
> > >
> > >> In my experience properly maintaining any distribution packages is a
> > >> large undertaking. I haven't seen an individual component project like
> > >> ours do a good job of maintaining proper rpm/deb packages for itself.
> > >> I don't know that I'd -1 someone wanting to do the work in our
> > >> community, but I'd be surprised if there was a net benefit over e.g.
> > >> BigTop.
> > >>
> > >> The problem with BigTop is that the version of HBase provided there
> > >> will only keep up so long as our community is investing the time there
> > >> for it to happen, naturally.
> > >>
> > >> > IMHO, by not building these (and not providing init scripts, and so
> > on),
> > >> > we're basically telling our users they shouldn't use Apache releases
> > in
> > >> > prod.
> > >>
> > >> I do agree with this sentiment, FWIW. not providing good
> > >> last-mile-to-deployment tools is a recurring issue we have.
> > >>
> > >> On Thu, Jun 2, 2016 at 5:30 PM, Nick Dimiduk <nd...@gmail.com>
> > wrote:
> > >> > Heya folks,
> > >> >
> > >> > Per the title, what do you think about generating more easily
> consumed
> > >> > artifacts in our releases? We already do all the hard parts of
> > >> generating
> > >> > binary packages and signing them. Seems like a simple extension to
> add
> > >> some
> > >> > additional convenience artifacts. Other Apache projects do this,
> > >> including
> > >> > hosting release repositories.
> > >> >
> > >> > Our story is made a little more complex due to dependencies on ZK
> and
> > >> HDFS,
> > >> > but I think we could make a strong argument for helping those
> projects
> > >> > produce the same for their users.
> > >> >
> > >> > IMHO, by not building these (and not providing init scripts, and so
> > on),
> > >> > we're basically telling our users they shouldn't use Apache releases
> > in
> > >> > prod.
> > >> >
> > >> > For reference:
> > >> > - https://github.com/tcurdt/jdeb#debian-packages-in-java
> > >> > - https://github.com/OpenTSDB/opentsdb/tree/master/build-aux
> > >> > - https://github.com/OpenTSDB/tcollector/tree/master/debian
> > >> > - http://wiki.apache.org/cassandra/DebianPackaging
> > >> >
> > >> > -n
> > >>
> > >>
> > >>
> > >> --
> > >> busbey
> > >>
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
> --
> Thanks,
> Michael Antonov
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: [DISCUSS] Include Deb and RPM packages in releases
Posted by Mikhail Antonov <ol...@gmail.com>.
"It might be more useful to produce a script that, given a set of versions
for { Hadoop, HBase, ZK } downloads the respective tarballs and stitches
together a HBase deployment tarball with all necessary jar substitutions
made, and perhaps the copy of Hadoop native library artifacts into the
expected location under HBase's lib, etc. If that still seems like too much
work for someone, I don't have a good answer for that."
That sounds like a custom version of Bigtop to me? Might if we want to
actively encourage more people to use
Apache distribution of HBase making a specialized "HBase-centric" (?)
Puppet recipe in Bigtop or something similar is the proper way to address
it.
-Mikhail
On Mon, Jun 6, 2016 at 12:03 PM, Andrew Purtell <ap...@apache.org> wrote:
> I forgot to mention that, IMHO, Dima's work with Docker is more likely to
> produce useful artifacts for folks looking to kick the tires. Related,
> perhaps the creation of a Vagrant box would be useful.
>
>
> On Mon, Jun 6, 2016 at 11:38 AM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > >> IMHO, by not building these (and not providing init scripts, and so
> on),
> > >> we're basically telling our users they shouldn't use Apache releases
> in
> > >> prod.
> > > I do agree with this sentiment, FWIW. not providing good
> > > last-mile-to-deployment tools is a recurring issue we have.
> >
> > I agree with Sean's way of stating the problem. The "telling our users
> > they shouldn't use Apache releases in prod" is an exaggeration at best
> and
> > definitely something I do not agree with at all. There is nowhere in our
> > documentation we make this statement. A whole constellation of Apache
> > projects release software as source - some source-only - and binary
> > "convenience" tarballs and as far as I know none have ever made this
> claim
> > anywhere ever, except when releasing "developer preview" or "alpha" or
> > "beta" versions and such, as you would expect.
> >
> > That said, I put 'convenience' in scare quotes because the bundled binary
> > artifacts are of varying utility depending on what constellation of
> > software versions you want to comprise your runtime. Those may be
> different
> > than the choices we made when building the "convenience" artifact. So,
> this
> > is open source, build it yourself to the specifications you need. All
> > Apache projects produce source as the primary, and often only, user
> > consumable. This is where Apache Bigtop's build harness can provide value
> > for the DIY crowd, or where a vendor can provide value - if the would-be
> > user simply can't be bothered to learn how to consume open source
> artifacts
> > from a volunteer open source project. I personally take a dim view of
> such
> > "users": very unlikely to contribute anything back, and likely to be
> > entitled assholes and a parasitic drain on volunteer time if they do make
> > an appearance.
> >
> > I'm not saying not to invest time and energy in maven targets for
> rpm/deb,
> > if that's an itch someone wants to scratch, but user mileage will vary
> with
> > those in just the same way as our tarballs, unless we produce a number of
> > RPMs using a matrix of Hadoop (and possibly ZK) versions.
> >
> > It might be more useful to produce a script that, given a set of versions
> > for { Hadoop, HBase, ZK } downloads the respective tarballs and stitches
> > together a HBase deployment tarball with all necessary jar substitutions
> > made, and perhaps the copy of Hadoop native library artifacts into the
> > expected location under HBase's lib, etc. If that still seems like too
> much
> > work for someone, I don't have a good answer for that.
> >
> >
> >
> > On Mon, Jun 6, 2016 at 11:03 AM, Sean Busbey <bu...@cloudera.com>
> wrote:
> >
> >> In my experience properly maintaining any distribution packages is a
> >> large undertaking. I haven't seen an individual component project like
> >> ours do a good job of maintaining proper rpm/deb packages for itself.
> >> I don't know that I'd -1 someone wanting to do the work in our
> >> community, but I'd be surprised if there was a net benefit over e.g.
> >> BigTop.
> >>
> >> The problem with BigTop is that the version of HBase provided there
> >> will only keep up so long as our community is investing the time there
> >> for it to happen, naturally.
> >>
> >> > IMHO, by not building these (and not providing init scripts, and so
> on),
> >> > we're basically telling our users they shouldn't use Apache releases
> in
> >> > prod.
> >>
> >> I do agree with this sentiment, FWIW. not providing good
> >> last-mile-to-deployment tools is a recurring issue we have.
> >>
> >> On Thu, Jun 2, 2016 at 5:30 PM, Nick Dimiduk <nd...@gmail.com>
> wrote:
> >> > Heya folks,
> >> >
> >> > Per the title, what do you think about generating more easily consumed
> >> > artifacts in our releases? We already do all the hard parts of
> >> generating
> >> > binary packages and signing them. Seems like a simple extension to add
> >> some
> >> > additional convenience artifacts. Other Apache projects do this,
> >> including
> >> > hosting release repositories.
> >> >
> >> > Our story is made a little more complex due to dependencies on ZK and
> >> HDFS,
> >> > but I think we could make a strong argument for helping those projects
> >> > produce the same for their users.
> >> >
> >> > IMHO, by not building these (and not providing init scripts, and so
> on),
> >> > we're basically telling our users they shouldn't use Apache releases
> in
> >> > prod.
> >> >
> >> > For reference:
> >> > - https://github.com/tcurdt/jdeb#debian-packages-in-java
> >> > - https://github.com/OpenTSDB/opentsdb/tree/master/build-aux
> >> > - https://github.com/OpenTSDB/tcollector/tree/master/debian
> >> > - http://wiki.apache.org/cassandra/DebianPackaging
> >> >
> >> > -n
> >>
> >>
> >>
> >> --
> >> busbey
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Thanks,
Michael Antonov
Re: [DISCUSS] Include Deb and RPM packages in releases
Posted by Andrew Purtell <ap...@apache.org>.
I forgot to mention that, IMHO, Dima's work with Docker is more likely to
produce useful artifacts for folks looking to kick the tires. Related,
perhaps the creation of a Vagrant box would be useful.
On Mon, Jun 6, 2016 at 11:38 AM, Andrew Purtell <ap...@apache.org> wrote:
> >> IMHO, by not building these (and not providing init scripts, and so on),
> >> we're basically telling our users they shouldn't use Apache releases in
> >> prod.
> > I do agree with this sentiment, FWIW. not providing good
> > last-mile-to-deployment tools is a recurring issue we have.
>
> I agree with Sean's way of stating the problem. The "telling our users
> they shouldn't use Apache releases in prod" is an exaggeration at best and
> definitely something I do not agree with at all. There is nowhere in our
> documentation we make this statement. A whole constellation of Apache
> projects release software as source - some source-only - and binary
> "convenience" tarballs and as far as I know none have ever made this claim
> anywhere ever, except when releasing "developer preview" or "alpha" or
> "beta" versions and such, as you would expect.
>
> That said, I put 'convenience' in scare quotes because the bundled binary
> artifacts are of varying utility depending on what constellation of
> software versions you want to comprise your runtime. Those may be different
> than the choices we made when building the "convenience" artifact. So, this
> is open source, build it yourself to the specifications you need. All
> Apache projects produce source as the primary, and often only, user
> consumable. This is where Apache Bigtop's build harness can provide value
> for the DIY crowd, or where a vendor can provide value - if the would-be
> user simply can't be bothered to learn how to consume open source artifacts
> from a volunteer open source project. I personally take a dim view of such
> "users": very unlikely to contribute anything back, and likely to be
> entitled assholes and a parasitic drain on volunteer time if they do make
> an appearance.
>
> I'm not saying not to invest time and energy in maven targets for rpm/deb,
> if that's an itch someone wants to scratch, but user mileage will vary with
> those in just the same way as our tarballs, unless we produce a number of
> RPMs using a matrix of Hadoop (and possibly ZK) versions.
>
> It might be more useful to produce a script that, given a set of versions
> for { Hadoop, HBase, ZK } downloads the respective tarballs and stitches
> together a HBase deployment tarball with all necessary jar substitutions
> made, and perhaps the copy of Hadoop native library artifacts into the
> expected location under HBase's lib, etc. If that still seems like too much
> work for someone, I don't have a good answer for that.
>
>
>
> On Mon, Jun 6, 2016 at 11:03 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> In my experience properly maintaining any distribution packages is a
>> large undertaking. I haven't seen an individual component project like
>> ours do a good job of maintaining proper rpm/deb packages for itself.
>> I don't know that I'd -1 someone wanting to do the work in our
>> community, but I'd be surprised if there was a net benefit over e.g.
>> BigTop.
>>
>> The problem with BigTop is that the version of HBase provided there
>> will only keep up so long as our community is investing the time there
>> for it to happen, naturally.
>>
>> > IMHO, by not building these (and not providing init scripts, and so on),
>> > we're basically telling our users they shouldn't use Apache releases in
>> > prod.
>>
>> I do agree with this sentiment, FWIW. not providing good
>> last-mile-to-deployment tools is a recurring issue we have.
>>
>> On Thu, Jun 2, 2016 at 5:30 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>> > Heya folks,
>> >
>> > Per the title, what do you think about generating more easily consumed
>> > artifacts in our releases? We already do all the hard parts of
>> generating
>> > binary packages and signing them. Seems like a simple extension to add
>> some
>> > additional convenience artifacts. Other Apache projects do this,
>> including
>> > hosting release repositories.
>> >
>> > Our story is made a little more complex due to dependencies on ZK and
>> HDFS,
>> > but I think we could make a strong argument for helping those projects
>> > produce the same for their users.
>> >
>> > IMHO, by not building these (and not providing init scripts, and so on),
>> > we're basically telling our users they shouldn't use Apache releases in
>> > prod.
>> >
>> > For reference:
>> > - https://github.com/tcurdt/jdeb#debian-packages-in-java
>> > - https://github.com/OpenTSDB/opentsdb/tree/master/build-aux
>> > - https://github.com/OpenTSDB/tcollector/tree/master/debian
>> > - http://wiki.apache.org/cassandra/DebianPackaging
>> >
>> > -n
>>
>>
>>
>> --
>> busbey
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: [DISCUSS] Include Deb and RPM packages in releases
Posted by Jean-Marc Spaggiari <je...@spaggiari.org>.
Just to share my experience here.
I had to build and deploy HBase+Hadoop+ZK+etc. using BigTop (builds RPMs)
and it went very well...
So If they are looking for RPMs or DEBs I think it might be fair to
redirect people to BigTop...
JMs
2016-06-06 14:38 GMT-04:00 Andrew Purtell <ap...@apache.org>:
> >> IMHO, by not building these (and not providing init scripts, and so on),
> >> we're basically telling our users they shouldn't use Apache releases in
> >> prod.
> > I do agree with this sentiment, FWIW. not providing good
> > last-mile-to-deployment tools is a recurring issue we have.
>
> I agree with Sean's way of stating the problem. The "telling our users they
> shouldn't use Apache releases in prod" is an exaggeration at best and
> definitely something I do not agree with at all. There is nowhere in our
> documentation we make this statement. A whole constellation of Apache
> projects release software as source - some source-only - and binary
> "convenience" tarballs and as far as I know none have ever made this claim
> anywhere ever, except when releasing "developer preview" or "alpha" or
> "beta" versions and such, as you would expect.
>
> That said, I put 'convenience' in scare quotes because the bundled binary
> artifacts are of varying utility depending on what constellation of
> software versions you want to comprise your runtime. Those may be different
> than the choices we made when building the "convenience" artifact. So, this
> is open source, build it yourself to the specifications you need. All
> Apache projects produce source as the primary, and often only, user
> consumable. This is where Apache Bigtop's build harness can provide value
> for the DIY crowd, or where a vendor can provide value - if the would-be
> user simply can't be bothered to learn how to consume open source artifacts
> from a volunteer open source project. I personally take a dim view of such
> "users": very unlikely to contribute anything back, and likely to be
> entitled assholes and a parasitic drain on volunteer time if they do make
> an appearance.
>
> I'm not saying not to invest time and energy in maven targets for rpm/deb,
> if that's an itch someone wants to scratch, but user mileage will vary with
> those in just the same way as our tarballs, unless we produce a number of
> RPMs using a matrix of Hadoop (and possibly ZK) versions.
>
> It might be more useful to produce a script that, given a set of versions
> for { Hadoop, HBase, ZK } downloads the respective tarballs and stitches
> together a HBase deployment tarball with all necessary jar substitutions
> made, and perhaps the copy of Hadoop native library artifacts into the
> expected location under HBase's lib, etc. If that still seems like too much
> work for someone, I don't have a good answer for that.
>
>
>
> On Mon, Jun 6, 2016 at 11:03 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > In my experience properly maintaining any distribution packages is a
> > large undertaking. I haven't seen an individual component project like
> > ours do a good job of maintaining proper rpm/deb packages for itself.
> > I don't know that I'd -1 someone wanting to do the work in our
> > community, but I'd be surprised if there was a net benefit over e.g.
> > BigTop.
> >
> > The problem with BigTop is that the version of HBase provided there
> > will only keep up so long as our community is investing the time there
> > for it to happen, naturally.
> >
> > > IMHO, by not building these (and not providing init scripts, and so
> on),
> > > we're basically telling our users they shouldn't use Apache releases in
> > > prod.
> >
> > I do agree with this sentiment, FWIW. not providing good
> > last-mile-to-deployment tools is a recurring issue we have.
> >
> > On Thu, Jun 2, 2016 at 5:30 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> > > Heya folks,
> > >
> > > Per the title, what do you think about generating more easily consumed
> > > artifacts in our releases? We already do all the hard parts of
> generating
> > > binary packages and signing them. Seems like a simple extension to add
> > some
> > > additional convenience artifacts. Other Apache projects do this,
> > including
> > > hosting release repositories.
> > >
> > > Our story is made a little more complex due to dependencies on ZK and
> > HDFS,
> > > but I think we could make a strong argument for helping those projects
> > > produce the same for their users.
> > >
> > > IMHO, by not building these (and not providing init scripts, and so
> on),
> > > we're basically telling our users they shouldn't use Apache releases in
> > > prod.
> > >
> > > For reference:
> > > - https://github.com/tcurdt/jdeb#debian-packages-in-java
> > > - https://github.com/OpenTSDB/opentsdb/tree/master/build-aux
> > > - https://github.com/OpenTSDB/tcollector/tree/master/debian
> > > - http://wiki.apache.org/cassandra/DebianPackaging
> > >
> > > -n
> >
> >
> >
> > --
> > busbey
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: [DISCUSS] Include Deb and RPM packages in releases
Posted by Andrew Purtell <ap...@apache.org>.
>> IMHO, by not building these (and not providing init scripts, and so on),
>> we're basically telling our users they shouldn't use Apache releases in
>> prod.
> I do agree with this sentiment, FWIW. not providing good
> last-mile-to-deployment tools is a recurring issue we have.
I agree with Sean's way of stating the problem. The "telling our users they
shouldn't use Apache releases in prod" is an exaggeration at best and
definitely something I do not agree with at all. There is nowhere in our
documentation we make this statement. A whole constellation of Apache
projects release software as source - some source-only - and binary
"convenience" tarballs and as far as I know none have ever made this claim
anywhere ever, except when releasing "developer preview" or "alpha" or
"beta" versions and such, as you would expect.
That said, I put 'convenience' in scare quotes because the bundled binary
artifacts are of varying utility depending on what constellation of
software versions you want to comprise your runtime. Those may be different
than the choices we made when building the "convenience" artifact. So, this
is open source, build it yourself to the specifications you need. All
Apache projects produce source as the primary, and often only, user
consumable. This is where Apache Bigtop's build harness can provide value
for the DIY crowd, or where a vendor can provide value - if the would-be
user simply can't be bothered to learn how to consume open source artifacts
from a volunteer open source project. I personally take a dim view of such
"users": very unlikely to contribute anything back, and likely to be
entitled assholes and a parasitic drain on volunteer time if they do make
an appearance.
I'm not saying not to invest time and energy in maven targets for rpm/deb,
if that's an itch someone wants to scratch, but user mileage will vary with
those in just the same way as our tarballs, unless we produce a number of
RPMs using a matrix of Hadoop (and possibly ZK) versions.
It might be more useful to produce a script that, given a set of versions
for { Hadoop, HBase, ZK } downloads the respective tarballs and stitches
together a HBase deployment tarball with all necessary jar substitutions
made, and perhaps the copy of Hadoop native library artifacts into the
expected location under HBase's lib, etc. If that still seems like too much
work for someone, I don't have a good answer for that.
On Mon, Jun 6, 2016 at 11:03 AM, Sean Busbey <bu...@cloudera.com> wrote:
> In my experience properly maintaining any distribution packages is a
> large undertaking. I haven't seen an individual component project like
> ours do a good job of maintaining proper rpm/deb packages for itself.
> I don't know that I'd -1 someone wanting to do the work in our
> community, but I'd be surprised if there was a net benefit over e.g.
> BigTop.
>
> The problem with BigTop is that the version of HBase provided there
> will only keep up so long as our community is investing the time there
> for it to happen, naturally.
>
> > IMHO, by not building these (and not providing init scripts, and so on),
> > we're basically telling our users they shouldn't use Apache releases in
> > prod.
>
> I do agree with this sentiment, FWIW. not providing good
> last-mile-to-deployment tools is a recurring issue we have.
>
> On Thu, Jun 2, 2016 at 5:30 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> > Heya folks,
> >
> > Per the title, what do you think about generating more easily consumed
> > artifacts in our releases? We already do all the hard parts of generating
> > binary packages and signing them. Seems like a simple extension to add
> some
> > additional convenience artifacts. Other Apache projects do this,
> including
> > hosting release repositories.
> >
> > Our story is made a little more complex due to dependencies on ZK and
> HDFS,
> > but I think we could make a strong argument for helping those projects
> > produce the same for their users.
> >
> > IMHO, by not building these (and not providing init scripts, and so on),
> > we're basically telling our users they shouldn't use Apache releases in
> > prod.
> >
> > For reference:
> > - https://github.com/tcurdt/jdeb#debian-packages-in-java
> > - https://github.com/OpenTSDB/opentsdb/tree/master/build-aux
> > - https://github.com/OpenTSDB/tcollector/tree/master/debian
> > - http://wiki.apache.org/cassandra/DebianPackaging
> >
> > -n
>
>
>
> --
> busbey
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: [DISCUSS] Include Deb and RPM packages in releases
Posted by Sean Busbey <bu...@cloudera.com>.
In my experience properly maintaining any distribution packages is a
large undertaking. I haven't seen an individual component project like
ours do a good job of maintaining proper rpm/deb packages for itself.
I don't know that I'd -1 someone wanting to do the work in our
community, but I'd be surprised if there was a net benefit over e.g.
BigTop.
The problem with BigTop is that the version of HBase provided there
will only keep up so long as our community is investing the time there
for it to happen, naturally.
> IMHO, by not building these (and not providing init scripts, and so on),
> we're basically telling our users they shouldn't use Apache releases in
> prod.
I do agree with this sentiment, FWIW. not providing good
last-mile-to-deployment tools is a recurring issue we have.
On Thu, Jun 2, 2016 at 5:30 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> Heya folks,
>
> Per the title, what do you think about generating more easily consumed
> artifacts in our releases? We already do all the hard parts of generating
> binary packages and signing them. Seems like a simple extension to add some
> additional convenience artifacts. Other Apache projects do this, including
> hosting release repositories.
>
> Our story is made a little more complex due to dependencies on ZK and HDFS,
> but I think we could make a strong argument for helping those projects
> produce the same for their users.
>
> IMHO, by not building these (and not providing init scripts, and so on),
> we're basically telling our users they shouldn't use Apache releases in
> prod.
>
> For reference:
> - https://github.com/tcurdt/jdeb#debian-packages-in-java
> - https://github.com/OpenTSDB/opentsdb/tree/master/build-aux
> - https://github.com/OpenTSDB/tcollector/tree/master/debian
> - http://wiki.apache.org/cassandra/DebianPackaging
>
> -n
--
busbey
Re: [DISCUSS] Include Deb and RPM packages in releases
Posted by Nick Dimiduk <nd...@gmail.com>.
On Thu, Jun 2, 2016 at 5:52 PM, Andrew Purtell <ap...@apache.org> wrote:
> > Our story is made a little more complex due to dependencies on ZK and
> HDFS
>
> More than a little complex because those dependencies in our lib/ need to
> be replaced with the local versions in use as installed.
>
Sure, but complexity shouldn't deter us from implementing some feature
that's helpful to users.
Solutions like Apache Bigtop already address this. Use Bigtop?
>
Maybe? Should we document using a Bigtop release in our getting started
docs, call it a day? Are we content with pointing users at Bigtop releases?
On Thu, Jun 2, 2016 at 5:30 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>
> > Heya folks,
> >
> > Per the title, what do you think about generating more easily consumed
> > artifacts in our releases? We already do all the hard parts of generating
> > binary packages and signing them. Seems like a simple extension to add
> some
> > additional convenience artifacts. Other Apache projects do this,
> including
> > hosting release repositories.
> >
> > Our story is made a little more complex due to dependencies on ZK and
> HDFS,
> > but I think we could make a strong argument for helping those projects
> > produce the same for their users.
> >
> > IMHO, by not building these (and not providing init scripts, and so on),
> > we're basically telling our users they shouldn't use Apache releases in
> > prod.
> >
> > For reference:
> > - https://github.com/tcurdt/jdeb#debian-packages-in-java
> > - https://github.com/OpenTSDB/opentsdb/tree/master/build-aux
> > - https://github.com/OpenTSDB/tcollector/tree/master/debian
> > - http://wiki.apache.org/cassandra/DebianPackaging
> >
> > -n
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: [DISCUSS] Include Deb and RPM packages in releases
Posted by Andrew Purtell <ap...@apache.org>.
> Our story is made a little more complex due to dependencies on ZK and HDFS
More than a little complex because those dependencies in our lib/ need to
be replaced with the local versions in use as installed.
Solutions like Apache Bigtop already address this. Use Bigtop?
On Thu, Jun 2, 2016 at 5:30 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> Heya folks,
>
> Per the title, what do you think about generating more easily consumed
> artifacts in our releases? We already do all the hard parts of generating
> binary packages and signing them. Seems like a simple extension to add some
> additional convenience artifacts. Other Apache projects do this, including
> hosting release repositories.
>
> Our story is made a little more complex due to dependencies on ZK and HDFS,
> but I think we could make a strong argument for helping those projects
> produce the same for their users.
>
> IMHO, by not building these (and not providing init scripts, and so on),
> we're basically telling our users they shouldn't use Apache releases in
> prod.
>
> For reference:
> - https://github.com/tcurdt/jdeb#debian-packages-in-java
> - https://github.com/OpenTSDB/opentsdb/tree/master/build-aux
> - https://github.com/OpenTSDB/tcollector/tree/master/debian
> - http://wiki.apache.org/cassandra/DebianPackaging
>
> -n
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)