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