Installing mesos on OSX is quite easy. There are two common options for installing mesos using homebrew or compiling the sources.
The directions here are pretty complete.
The homebrew install doesn’t provide a launcher for OSX. Launching applications on computer systems should become a research topic for an abstraction that works on all the systems. Dealing with all the syntax differences between Windows, OSX and all the Linux flavors introduces inefficiencies since one needs to remember more than four different syntax and conventions for the basic concept of launching an application in the foreground or the background. The number of verbs in an operating system dwarfs the number of verbs in a Programming Language. Linux has had quite a few changed directions in this area with the typical solution being another fork with new syntax that all the different Linux systems don’t adopt. The latest approach is to use systemd and abandon /etc/init.d/ and upstart. The following links are very useful for creating your own launchers on OSX.
Directions I used to build. (IMO there is something very wrong with a programming industry that has detailed directions to build, the current build systems are rooted in the past and not the future). Maven does a good job for Java but C, C++ are notorious for complexity.
The directions have worked very well on 0.25 and 0.26 when using github or a packaged source release. The wget download is a distribution, when building using the latest tip from github you may get a tip that doesn’t build. The mesos development effort is odd in that they don’t identify releases with tags or branches and often the version strings in the docs and release notes don’t match what maven prints as the version number.
- http://launchd.info/ Overview of launchd
- http://www.soma-zone.com/LaunchControl/ Not very useful app to create and manage launchd configurations which are based on plist formats. Most things don’t work unless you buy it and it doesn’t tell you during install or after launch you have to do the work and go read the website I guess.
- Doesn’t allow you to write to the directories where plist files should be kept
- Confusion between top level app directory and meaning of .app
- Doesn’t provide default locations — assumes you want to figure it out.
- If you change the plist disk, it doesn’t reload it.
Another solution is to use xcode or edit and move the files around yourself based on this link http://launchd.info/ and use LaunchControl for viewing only if you don’t use the CLI. Xcode doesn’t provide much help. Sadly the best solution IMO is to just use an editor and use the above tools once you have the file created. You would think that there would be a basic template included that is for running a background process.
You can check your file with: plutil -lint org.apache.mesos.master.plist
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>org.apache.mesos.master</string> <key>ProgramArguments</key> <array> <string>/usr/local/sbin/mesos-master</string> <string>--registry=in_memory</string> <string>--ip=127.0.0.1</string> <string>--work_dir=/var/log/mesos</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist>
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>org.apache.mesos.slave</string> <key>ProgramArguments</key> <array> <string>/usr/local/sbin/mesos-slave</string> <string>--master=127.0.0.1:5050</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist>
Improving system configuration broadly
The current design for most launch services is not well suited to clouds. The configuration approaches were developed when it was one computer not n of them. Many of the follow on updates to packaging do very little to address the core issues. For example Linux relies heavily on little files all over the disk. While Microsoft started the process with the registry, the apis and access approaches are not rest based and are not scalable. A complete refactoring is needed that should include:
- the use of network addressable stores having key value pairs,
- access via rest services,
- use of multicast technologies instead of point to point
- name space management.