Hi Everybody,
I am reviving this old thread, to talk about builds specifically
on RHEL and CentOS. I am not sure how to ensure reliably that
Mesos finds libjvm.so while allowing flexibility in the choice
of JDK.
On Debian and Ubuntu, one can depend on an abstract package for
Java and even depend on one or another package. So for the
builds I do at present, the Deb package depends on:
java7-runtime-headless | java6-runtime-headless
On Debian and Ubuntu, as long as the default-jre-headless is
installed, then Mesos finds libjvm.so without any problems; and
it's indifferent to whether it's a Java 7 JRE or Java 6 JRE.
But on RedHat and CentOS, there does not seem to be any way to
specify an "abstract" Java dependency and alternatives are not
part of the RedHat dependency specification language. Two
suggestions I've seen online are:
* Create ones own abstract Java package (not sure how this
would work) and depend on that.
* Just don't depend on Java and allow the user to install it
(seems to be what CDH does).
I've taken the latter approach.
So now we come to the problem of libjvm.so -- Mesos doesn't find
it. The only reliable thing I've got going is using `locate' and
symlinking the version from the server JRE in to /usr/lib. But
one hesitates to do this from a package post-install script.
It is also notable that the Java library paths aren't set up
right for many of the packages, so one can't simply query Java
for the location of libjvm.so:
https://bugzilla.redhat.com/show_bug.cgi?id=740762
Has anyone else encountered difficulty with discovery of
libjvm.so on RedHat and CentOS when running internal RPMs? I'd
like to find a way to ensure the packages work without any
fiddling. It may be that the ultimate solution is to provide
separate JDK 1.6 and JDK 1.7 versions of the Mesos package for
these distros and modify LD_LIBRARY_PATH from the init scripts.
--
Jason Dusek
--
Jason Dusek
pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B
2013/7/12 Bernardo Gomez Palacio <[email protected]>:
> At least in master, 0.14.0, file based configuration with the `--conf`
> options is not supported. That said imho we could follow the approach stated
> bellow.
>
> Within the execution of the init.d script source a default env shell. (
> extracted from mesos-profile-env.sh )
>
> # Source the default environment variables.
> DEFAULT_ENV="$PRGDIR/mesos-profile-env.sh"
> if [ -f "$DEFAULT_ENV"]
> source $DEFAULT_ENV
> fi
>
> And also source a profile.d shell if available
>
> # Source the profile environment variables if available.
> PROFILE_ENV="/etc/profile.d/mesos-profile-env.sh"
> if [ -f "$PROFILE_ENV" ]; then
> source "$PROFILE_ENV"
> fi
>
> Then support a configuration file, which basically defines what can be set as
> options, such that you can again have a default or override for a specific
> package (local, master, slave)
>
> # Setup Configuration Directory
> if [ -f "/etc/mesos/mesos-master.conf" ]; then
> CONFIGFILE="/etc/mesos/mesos-master.conf"
> else
> CONFIGFILE="/etc/mesos/mesos.conf"
> fi
>
> Apply the conf file elements as arguments/options to either the master,
> slave, or local.
>
> # Initialize the _Command_ options.
> OPTIONS="--log_dir=$LOG_DIR"
> if [ -n "$CONFIGFILE" ]; then
> OPTIONS=`paste -d " " <(cat /etc/mesos/master-master.conf | grep -e
> "^[--]" )`
> fi
>
>
> Example references.
> 1. "mesos-profile-env.sh"
> https://github.com/Guavus/incubator-mesos/blob/support/guavus-master/src/deploy/mesos-profile-env.sh.in
> 2. "mesos-master init.d script for rhl"
> https://github.com/Guavus/incubator-mesos/blob/support/guavus-master/src/deploy/mesos-masterd.sh.in
>
> Best
> Bernardo
>
>
> On Jul 12, 2013, at 12:13 PM, Jason Dusek <[email protected]> wrote:
>
>> 2013/7/11 Daniel Lundin <[email protected]>:
>>> As an option, I've attached the debian packaging patch I've
>>> used for packaging Mesos for Ubuntu (Precise) to MESOS-74. It
>>> does not use a third party / unified packager, rather just the
>>> standard toolchain - A debian directory in the source tree
>>> with all the trimmings. Just run "debuild ..." at the top and,
>>> ideally, you're good to go.
>>>
>>> Overall, in my experience it's hard to maintain packages for
>>> multiple platforms using a "meta-packager" scheme on a
>>> sizeable/multi-language project. It's usually easier to just
>>> go with the romans, whomever they may be at that particular
>>> juncture. Different systems have different policies for
>>> packages, how to split them up (libs, dev, language-specific
>>> bits), dealing with multi-architecture, python versions, etc.
>>> I've always ended up with *more* work trying to unify system
>>> packaging than just doing it once per platform. :)
>>
>> This really seems right to me. The meta package manager might
>> get you something the installer will accept; but not something
>> the distro will accept.
>>
>>> It might be worth considering it can be easier to find people
>>> experienced, interested and opinionated in platform-specific
>>> packaging, and the work tends to be low-hanging fruit for
>>> contributing to a project.
>>>
>>> In any case, hope the patch comes in handy.
>>
>> In its pretty form, this is pretty hard to work with. If there
>> is anyway you could create branch on GitHub...
>>
>> Of course I will still try to read it over the weekend, anyways.
>>
>> An open question for the project is how we want to manage Mesos
>> configuration. In the branch I'm working on, it's all
>> environment variables; and /etc/mesos/zk is loaded into an
>> environment variable and is the only "config file". We could
>> have a `mesos.conf' but as far as I understand it, file-based
>> config is slated for removal.
>>
>> --
>> Jason Dusek
>> pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B
>
