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
