Michael Berman 2014-01-27, 16:44
Josh Elser 2014-01-27, 16:54
Michael Berman 2014-01-27, 22:05
Josh Elser 2014-01-27, 22:40
Michael Berman 2014-01-27, 22:56
Christopher 2014-01-28, 01:09
Michael Berman 2014-01-28, 02:20
Michael Berman 2014-01-28, 19:11
JIRA is being reindexed right now, so I can't view the ticket yet...
will do tomorrow. I don't know that start-all.sh and stop-all.sh needs
to be removed from the RPM... because it's not exactly redundant and
they still have utility (albeit less, because you can/should probably
just rely on chkconfig/service/systemctl/<whatever upstart uses>) to
start them... the start-all.sh and stop-all.sh scripts are really
cluster management tools, whereas the init scripts are service
management local to the machine on which they are installed.
Ideally, I think the cluster management stuff needs to be a separate
thing entirely... (contrib tools?).
Either way, for now, they should probably both work. It might require
setting adding a new environment variable
("ACCUMULO_BOOTSTRAP_CLASSPATH"?) or something we can override in
accumulo-env.sh and that defaults to the start jar and whatever else
we minimally need in lib/. I don't know if that's the best solution,
Christopher L Tubbs II
On Tue, Jan 28, 2014 at 2:10 PM, Michael Berman <[EMAIL PROTECTED]> wrote:
> Since the init scripts just call the start-server script, the problems I
> was seeing there also apply to the init scripts. I opened ACCUMULO-2267 to
> start tracking the issues.
> ctubbs, since the new RPM deployment was your project, I'd love your input
> on how to proceed. I'm interested in helping getting it working however I
> can, but I'm not sure how to balance RPM conventions against getting
> something that actually works.
> On Mon, Jan 27, 2014 at 9:19 PM, Michael Berman <[EMAIL PROTECTED]> wrote:
>> I didn't actually try to run it from the init.d scripts; I was using the
>> bin/start-* scripts. I'll try again with the init scripts. If the scripts
>> in bin aren't expected to work in an rpm deployment, should we remove them
>> from the package?
>> On Mon, Jan 27, 2014 at 8:08 PM, Christopher <[EMAIL PROTECTED]> wrote:
>>> I did automate setting up a yum repo in the assemble module's target
>>> directory, to make testing easier.
>>> I'm not entirely surprised the services fail to start... there's not
>>> been much attempt to update the SysVInit scripts. I had hoped that
>>> would be ironed out more thoroughly in testing. I think the idea is
>>> that the init script needs to add the start jar and any minimal
>>> dependencies to the classpath, and the default accumulo-site.xml
>>> configuration file should have the general.classpaths property set to
>>> include the correct locations. I did some testing of this, but have
>>> not yet had a chance to push them up, and they may still need more
>>> work. I would say to file bugs for anything that's not working (init
>>> script can't find start jar, default config can't find jars) and let's
>>> fix it.
>>> As for the reason these jars are in /usr/share/java, well, that's the
>>> de-facto standard for jars in RHEL/CentOS (esp. EPEL) packages, and is
>>> the explicit standard in Fedora (the most popular RPM-based community
>>> distribution, and the same community that maintains EPEL). The goal
>>> for making RPMs that go there was to standardize in a way that would
>>> make it easy to transition to a state where we could push RPMs to
>>> Fedora/EPEL, as Hadoop, Thrift, and ZooKeeper already have.
>>> Eventually, I'd prefer to stop packaging RPMs entirely... and just
>>> make it easier for downstream package maintainers in
>>> BigTop/Fedora/EPEL/whatever to package Accumulo, so we can focus less
>>> on packaging *and* development. This change to standard locations was
>>> one step towards that. Unfortunately, the init scripts and config were
>>> simply overlooked and you were the first to notice.
>>> Christopher L Tubbs II
>>> On Mon, Jan 27, 2014 at 5:55 PM, Michael Berman <[EMAIL PROTECTED]>
>>> > It looks like you can't just install, say, the tserver RPM to get the
>>> > tserver. It depends on server-base, core, start, etc. So this means I
Christopher 2014-01-28, 00:56
Michael Berman 2014-01-28, 19:41