On Thu, Jan 4, 2018 at 7:43 PM, Christopher <ctubb...@apache.org> wrote: > tl;dr : I would prefer not to add another tarball as part of our "official"
I am not opposed to replacing the current single tarball with client and server tarballs. What I find appealing about this is if the client tarball has less deps. However I think a lot of thought should be put into the scripts if this is done. For example the client tar and server tar should probably not both have accumulo commands that do different things. > releases, but I'd be in favor of a blog instructions, script, or build > profile, which users could read/execute/activate to create a client-centric > package. > > I've long believed that supporting different downstream packaging scenarios > should be prioritized over upstream binary packaging. I have argued in These "downstream" packaging could be done within the Apache Accumulo project also. Like accumulo-docker. Creating other packaging projects within Accumulo is something to consider. > favor of removing our current tarball entirely, while supporting efforts to Apache Accumulo needs some sort of tarball that makes it easy to run the code on a cluster, otherwise how can we test Accumulo on a cluster for releases? > enable downstream packaging by modularizing the server code, supporting a > client-API jar (future work), and decoupling code from launch scripts. I > think we should continue to do these kinds of improvements to support > different packaging scenarios downstream, but I'd prefer to avoid > additional "official" binary releases. I agree, I think if the Accumulo Java code made less assumptions about its runtime env it would result in code that is easier to maintain and package for different environments. In Fluo we have recently done a lot of work in order to support Docker, Mesos, and Kubernetes. This work has really cleaned up the core Fluo code making it easier to run in any environment. I suspect pulling the Accumuo tar ball into a separate git repo and out of the main repo may help highlight some of the assumptions Accumulo Java code makes about the environment. I think these clean up issues are related to what Josh is suggesting, but are not prerequisites. So it makes sense to discuss them at this point, but I don't think they should block work on two tarballs if that seems like a good idea. > > Rather than provide additional packages, I'd prefer to work with downstream > to make the source more "packagable" to suit the needs of these downstream > vendor/community packagers. One way we can do that here is by either > documenting what would be needed in a client-centric package, or by > providing a script or build profile to create it from source, so that your > $dayjob or any other downstream packager doesn't have to figure that out > from scratch. > > On Thu, Jan 4, 2018 at 7:17 PM Josh Elser <josh.el...@gmail.com> wrote: > >> Hi, >> >> $dayjob presented me with a request to break up the current tarball into >> two: one suitable for "users" and another for the Accumulo services. The >> ultimate goal is to make upgrade scenarios a bit easier by having client >> and server centric packaging. >> >> The "client" tarball would be something suitable for most users >> providing the ability to do things like: >> >> * Launch a java app against Accumulo >> * Launch a MapReduce job against Accumulo >> * Launch the Accumulo shell >> >> Essentially, the client tarball is just a pared down version of our >> "current" tarball and the server-tarball is likely equivalent to our >> "current" tarball (given that we have little code which would be >> considered client-only). >> >> Obviously, there are many ways to go about this. If there is buy-in from >> other folks, adding some new assembly descriptors and making it a part >> of the Maven build (perhaps, optionally generated) would be the easiest >> in terms of maintenance. However, I don't want to push for that if it's >> just going to be ignored by folks. I'll be creating something to support >> this one way or another. >> >> Any thoughts/opinions? Would this have any value to other folks? >> >> - Josh >>
