"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 <apurt...@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 <apurt...@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 <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)
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Thanks,
Michael Antonov
