Several committers/contributors in the community joined a call in
Slack on Wednesday, at 1130-1230, New York (Eastern) time. Here are my
notes of the call. Please feel free to add to them.

I shared the overall philosophy and backstory to some of the script
improvements in 2.x to help guide current/future work on the scripts.

* bin/accumulo is inspired by old jpackage.org standards which are
still in use in RPM macros for Java packaging in Fedora/RHEL/etc. The
key idea is that scripts are simple... set up environment (class path,
etc.), locate java, and exec a single process with the provided args.
* bin/accumulo-service is inspired by old SysVInit scripts for
start/stop/restart/status of a single service
* behavior of bin/accumulo and bin/accumulo-service can be manipulated
through launch environment
* bin/accumulo-cluster uses bin/accumulo-service, and is provided as a
simple, out-of-the-box cluster management tool
* bin/accumulo-cluster and bin/accumulo-service are replaceable; they
are useful for out-of-the-box, but one would expect them to be
unnecessary if using systemd, or a vendor-provided cluster management
system
* we discussed possibly moving bin/accumulo-cluster and
bin/accumulo-service to contrib/ in the tarball, or some subdir of
bin/, but it was suggested to not make too many disruptive changes
there
* we discussed the possibility of adding a config file for
bin/accumulo-cluster (also mentioned on
https://github.com/apache/accumulo/pull/1568)
* we discussed the need to document the intent/purpose/scope of the
scripts in comments inside the scripts themselves
* Ed Coleman asked if it'd be good to document a systemd example; I
suggested it might make for a good blog post (perhaps by the person
who wrote the systemd unit files for Fluo Muchos)

Keith Turner discussed his development efforts with regard to enabling
more controls over compactions.

* one main idea was to keep configuration/API for data separate from
that for execution
* data is concerns to application owners, whereas execution involves
system admins (resource contention, etc.)
* he will submit a PR for review when ready
* he also suggested another call to go over the PR

Billie Rinaldi discussed better support for Azure Data Lake Storage
Gen2 (ADLSv2).

* maintaining a fork for experimenting, and working on reliably
testing issues involving WALs
* did not recommend using ADLSv2 with WALs, but that we should still support it
* might need to implement a custom log closer to better support it

Mike Miller brought up the idea of eliminating more static internal state.

* ServerConfigurationFactory might be improved in this regard, with
some additional ZK cleanup
* Other ZK cleanup might help elsewhere (such as ZooCache)
* I suggested tablet location cache might also benefit from being
bound to an AccumuloClient lifecycle (or a dedicated opaque object
that could be shared across AccumuloClient instances with its own
user-managed lifecycle)

Please add anything I might have missed (or got wrong) in response to this post.

Reply via email to