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)
