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