Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> Building RPMs


+
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
Copy link to this message
-
Re: Building RPMs
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.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
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
>>> http://gravatar.com/ctubbsii
>>>
>>>
>>> On Mon, Jan 27, 2014 at 5:55 PM, Michael Berman <[EMAIL PROTECTED]>
>>> wrote:
>>> > 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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB