On Fri, Jan 5, 2018 at 10:30 AM Keith Turner <ke...@deenlo.com> wrote:
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.
Agreed on Keith's point about the scripts and it requiring some
consideration.
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.
+1; When I say "downstream", it's a role, not an entity. The point is that
it's a distinct activity. accumulo-docker is a perfect example of a
"downstream packaging" project maintained by the upstream community. I find
it frustrating sometimes when supporting users that they can't tell the
difference between what is "Accumulo" and what is "this specific
packaging/configuration/deployment of Accumulo", because we don't make
those lines clear. I think we can draw these lines a bit more clearly.
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?
A binary tarball may be the best for this, but it's little more than the
jars in Maven Central and a few text files. It could be trivially replaced
with a simple script and manifest; it could also be replaced with an RPM, a
docker image, or any number of things. A tarball is just one type of
packaging for Accumulo's binaries.
In any case, I wasn't talking about removing the ability to produce a
binary tarball from source. Only removing it from our release artifacts and
downloads. It is not a popular opinion, but I still think it's reasonable,
with both pros and cons.
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.
This is basically what the assemble module is now. It's why I moved the bin
and conf directories into it, and have made its dependencies optional so
they wouldn't be resolved transitively, and why I made the assembly plugin
gather up the libs instead of the dependency plugin which used to drop them
in a lib directory at the root of the source checkout. This module is the
"downstream packaging" for the current "all-in-one" binary tarball package.
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.
Agreed. That discussion can be deferred. Much depends on how it is to be
split up.
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
