>> 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)
