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 <apurt...@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 <bus...@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 <ndimi...@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)
>
