I'm trying to do some testing on the 1.6 RPM. What maven switches are our official builds built with? Is just -Prpm enough, or do I need assemble, apache-release, etc., too? Is this stuff documented anywhere?
Ok, so I've successfully build my RPMs, and I have a whole pile of them. Is there one that will install all the services? Or should I install the tserver, master, gc, etc from their own poms just on the machines I want to run those on? Or do I need to install them all? On Mon, Jan 27, 2014 at 11:53 AM, Josh Elser <[EMAIL PROTECTED]> wrote:
I believe the point of breaking them up the way they are is that you can run just what you need on each host. Installing them all would certainly give you the runtime flexibility while you can just chkconfig on the processes you actually want to start.
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 either need to figure out the dependencies and put them all on the rpm -i command, or configure a directory as a local yum repo. Does anyone know a convenient way to do that? It seems like this could use some documentation, since it's seems like a pretty nonstandard way to distribute RPMs.
Independent of all that, having just installed all the packages, I'm not sure how to get it to actually work. It looks like the accumulo jars are installed in /usr/share/java/accumulo rather than $ACCUMULO_HOME/lib, and all services are failing to start, missing the class org.apache.accumulo.start.Main. After I've installed the RPMs, am I supposed to edit accumulo-env.sh to stick all the jar locations on the classpath or something? It's not obvious to me where a good place to do that would be, or if there are other paths I need. What was the reasoning behind having the rpm create such a different installation tree from other deployments?
Thanks again, Michael On Mon, Jan 27, 2014 at 5:40 PM, Josh Elser <[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.
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:
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:
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, though.