[
https://issues.apache.org/jira/browse/MESOS-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155464#comment-13155464
]
Charles Reiss commented on MESOS-85:
------------------------------------
To get our pending autotools patch, I've done work (in the autotools github
branch as of this writing) towards this, including:
- adding a configuration option for the location mesos-launcher and the webui
files, defaulting to (hardcoded at compile-time) install locations. In the
current version, the default install locations are $(prefix)/libexec/mesos for
mesos-launcher and $(prefix)/share/mesos for the WebUI scripts.
- modifying the test harness to set MESOS_SOURCE_DIR and MESOS_BUILD_DIR and
having the external test scripts to use those environment variables instead of
MESOS_HOME;
The biggest issue I see remaining is how we should handle running out of the
build directory without MESOS_HOME. I don't think it's appropriate for an
installed binary to look in the current work directory for installed files
(assuming it's the build directory and that we staged files there), and I'm
sure it's not appropriate to have an installed binary look in a hard-coded
source directory before where files are installed (since this will cause
mysterious use of an uninstalled Mesos by a production binary). And if we look
in the installed locations first but "usually" find the uninstalled files, this
might confuse developers who have modified their uninstalled files (e.g. to add
features to the webui). We could tell anyone running out of the build directory
to set some environment variable (such as MESOS_UNINSTALLED=1 or
MESOS_BUILD_DIR=`pwd` or just MESOS_CONF set to point to a configuration file
built from AC_OUTPUT), which would require minimum modifications to Mesos.
Alternately, we could try to guess if we were running out of the installed
locations from /proc/self/exe and/or argv[0], but I'm worried this will be
fragile (and a bunch of extra code for non-Linux systems).
Other remaining issues are choosing sensible defaults for log_dir and work_dir
that aren't based on MESOS_HOME.
> Need to update semantics of MESOS_HOME
> --------------------------------------
>
> Key: MESOS-85
> URL: https://issues.apache.org/jira/browse/MESOS-85
> Project: Mesos
> Issue Type: Improvement
> Components: build, master, slave, test
> Reporter: Benjamin Hindman
> Assignee: Charles Reiss
> Priority: Blocker
>
> Currently MESOS_HOME is getting used for too much stuff. It is used to
> represent where the slave should store it's "work" directory, where the slave
> expects "killtree" to be, where the master and slave should put logging,
> where the tests assume certain scripts live, etc. In practice this has meant
> that if mesos gets installed at /usr/local/mesos, then slave work directories
> go there, logs go there, etc, which is totally unacceptable.
> MESOS_HOME should either be eliminated, or it's semantics should be changed
> so that it only represents where binaries live, but not where things like
> work directories exist, logs go, etc. In addition, the testing infrastructure
> should get updated so that the external tests can find the scripts they need
> to run things *without* needing MESOS_HOME while still supporting a remote
> build directory.
> This issue is tagged as a blocker because in order to do the port to
> autotools cleanly, this really needs to get done in order to run the external
> tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
