[jira] [Issue Comment Edited] (MESOS-85) Need to update semantics of MESOS_HOME

["Charles Reiss (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155464#comment-13155464 ] 

Charles Reiss edited comment on MESOS-85 at 11/22/11 9:49 PM:
--------------------------------------------------------------

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 or build directory before looking 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.
                
      was (Author: woggle):
    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