You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mesos.apache.org by dl...@apache.org on 2015/10/09 15:11:17 UTC
[3/3] mesos git commit: Documentation file naming cleanup
Documentation file naming cleanup
Part of https://issues.apache.org/jira/browse/MESOS-3686
Clean up of filenames in documentation, prefer hyphens and drop 'mesos' from filenames
This closes: #70
Review: https://github.com/apache/mesos/pull/70
Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/b29ec4f1
Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/b29ec4f1
Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/b29ec4f1
Branch: refs/heads/master
Commit: b29ec4f110483555a5e1a65ef25a7ecc13e31b7f
Parents: e8e9768
Author: Elsmore <ch...@demandlogic.co.uk>
Authored: Fri Oct 9 14:09:20 2015 +0100
Committer: Dave Lester <dl...@Daves-MacBook-Pro.local>
Committed: Fri Oct 9 14:09:20 2015 +0100
----------------------------------------------------------------------
docs/architecture.md | 32 ++
docs/c++-style-guide.md | 579 ++++++++++++++++++++++++++++++++
docs/clang-format.md | 2 +-
docs/containerizer.md | 82 +++++
docs/documentation-guide.md | 37 ++
docs/doxygen-style-guide.md | 196 +++++++++++
docs/effective-code-reviewing.md | 4 +-
docs/frameworks.md | 34 ++
docs/home.md | 24 +-
docs/markdown-style-guide.md | 118 +++++++
docs/mesos-architecture.md | 32 --
docs/mesos-c++-style-guide.md | 579 --------------------------------
docs/mesos-containerizer.md | 82 -----
docs/mesos-documentation-guide.md | 2 +
docs/mesos-doxygen-style-guide.md | 196 -----------
docs/mesos-frameworks.md | 34 --
docs/mesos-markdown-style-guide.md | 118 -------
docs/mesos-presentations.md | 92 -----
docs/mesos-roadmap.md | 13 -
docs/mesos-ssl.md | 92 -----
docs/mesos-testing-patterns.md | 81 -----
docs/powered-by-mesos.md | 2 +-
docs/presentations.md | 92 +++++
docs/roadmap.md | 13 +
docs/scheduler-http-api.md | 519 ++++++++++++++++++++++++++++
docs/scheduler_http_api.md | 519 ----------------------------
docs/ssl.md | 92 +++++
docs/submitting-a-patch.md | 6 +-
docs/testing-patterns.md | 81 +++++
docs/tools.md | 4 +-
30 files changed, 1898 insertions(+), 1859 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/architecture.md
----------------------------------------------------------------------
diff --git a/docs/architecture.md b/docs/architecture.md
new file mode 100644
index 0000000..439a56d
--- /dev/null
+++ b/docs/architecture.md
@@ -0,0 +1,32 @@
+---
+layout: documentation
+---
+
+# Mesos Architecture
+
+
+
+The above figure shows the main components of Mesos. Mesos consists of a *master* daemon that manages *slave* daemons running on each cluster node, and *mesos applications* (also called *frameworks*) that run *tasks* on these slaves.
+
+The master enables fine-grained sharing of resources (cpu, ram, ...) across applications by making them *resource offers*. Each resource offer contains a list of <slave ID, resource1: amount1, resource2, amount2, ...>. The master decides *how many* resources to offer to each framework according to a given organizational policy, such as fair sharing, or strict priority. To support a diverse set of policies, the master employs a modular architecture that makes it easy to add new allocation modules via a plugin mechanism.
+
+A framework running on top of Mesos consists of two components: a *scheduler* that registers with the master to be offered resources, and an *executor* process that is launched on slave nodes to run the framework's tasks (see the [App/Framework development guide](app-framework-development-guide.md) for more details about application schedulers and executors). While the master determines **how many** resources are offered to each framework, the frameworks' schedulers select **which** of the offered resources to use. When a frameworks accepts offered resources, it passes to Mesos a description of the tasks it wants to run on them. In turn, Mesos launches the tasks on the corresponding slaves.
+
+## Example of resource offer
+
+The figure below shows an example of how a framework gets scheduled to run a task.
+
+
+
+Let's walk through the events in the figure.
+
+1. Slave 1 reports to the master that it has 4 CPUs and 4 GB of memory free. The master then invokes the allocation policy module, which tells it that framework 1 should be offered all available resources.
+1. The master sends a resource offer describing what is available on slave 1 to framework 1.
+1. The framework's scheduler replies to the master with information about two tasks to run on the slave, using <2 CPUs, 1 GB RAM> for the first task, and <1 CPUs, 2 GB RAM> for the second task.
+1. Finally, the master sends the tasks to the slave, which allocates appropriate resources to the framework's executor, which in turn launches the two tasks (depicted with dotted-line borders in the figure). Because 1 CPU and 1 GB of RAM are still unallocated, the allocation module may now offer them to framework 2.
+
+In addition, this resource offer process repeats when tasks finish and new resources become free.
+
+While the thin interface provided by Mesos allows it to scale and allows the frameworks to evolve independently, one question remains: how can the constraints of a framework be satisfied without Mesos knowing about these constraints? For example, how can a framework achieve data locality without Mesos knowing which nodes store the data required by the framework? Mesos answers these questions by simply giving frameworks the ability to **reject** offers. A framework will reject the offers that do not satisfy its constraints and accept the ones that do. In particular, we have found that a simple policy called delay scheduling, in which frameworks wait for a limited time to acquire nodes storing the input data, yields nearly optimal data locality.
+
+You can also read much more about the Mesos architecture in this [technical paper](http://mesos.berkeley.edu/mesos_tech_report.pdf).
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/c++-style-guide.md
----------------------------------------------------------------------
diff --git a/docs/c++-style-guide.md b/docs/c++-style-guide.md
new file mode 100644
index 0000000..0b61891
--- /dev/null
+++ b/docs/c++-style-guide.md
@@ -0,0 +1,579 @@
+---
+layout: documentation
+---
+
+# Mesos C++ Style Guide
+
+The Mesos codebase follows the [Google C++ Style Guide](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml) with some notable differences, as described below. Note that the [clang-format](/documentation/latest/clang-format/) tool can be helpful to ensure that some of the mechanical style rules are obeyed.
+
+## Scoping
+
+### Namespaces
+* We avoid `using namespace foo` statements as it is not explicit about which symbols are pulled in, and it can often pull in a lot of symbols, which sometimes lead to conflicts.
+* It is OK to use namespace aliases to help pull in sub-namespaces, such as `namespace http = process::http;`. These should only be present at the top of the .cpp file.
+
+## Naming
+
+### Variable Names
+* We use [lowerCamelCase](http://en.wikipedia.org/wiki/CamelCase#Variations_and_synonyms) for variable names (Google uses snake_case, and their class member variables have trailing underscores).
+* We prepend constructor and function arguments with a leading underscore to avoid ambiguity and / or shadowing:
+
+~~~{.cpp}
+Try(State _state, T* _t = NULL, const std::string& _message = "")
+ : state(_state), t(_t), message(_message) {}
+~~~
+
+* Prefer trailing underscores for use as member fields (but not required). Some trailing underscores are used to distinguish between similar variables in the same scope (think prime symbols), *but this should be avoided as much as possible, including removing existing instances in the code base.*
+
+* If you find yourself creating a copy of an argument passed by const reference, consider passing it by value instead (if you don't want to use a leading underscore and copy in the body of the function):
+
+~~~{.cpp}
+// You can pass-by-value in ProtobufProcess::install() handlers.
+void Slave::statusUpdate(StatusUpdate update, const UPID& pid)
+{
+ ...
+ update.mutable_status()->set_source(
+ pid == UPID() ? TaskStatus::SOURCE_SLAVE : TaskStatus::SOURCE_EXECUTOR);
+ ...
+}
+~~~
+
+### Constant Names
+* We use [SCREAMING_SNAKE_CASE](http://en.wikipedia.org/wiki/Letter_case#Special_case_styles) for constant names (Google uses a `k` followed by mixed case, e.g. `kDaysInAWeek`).
+
+### Function Names
+* We use [lowerCamelCase](http://en.wikipedia.org/wiki/CamelCase#Variations_and_synonyms) for function names (Google uses mixed case for regular functions; and their accessors and mutators match the name of the variable).
+
+## Strings
+* Strings used in log and error messages should end without a period.
+
+## Comments
+* End each sentence within a comment with a punctuation mark (please note that we generally prefer periods); this applies to incomplete sentences as well.
+* For trailing comments, leave one space.
+
+## Breaks
+* Break before braces on enum, function, and record (i.e. struct, class, union) definitions.
+
+## Indentation
+
+### Class Format
+* Access modifiers are not indented (Google uses one space indentation).
+* Constructor initializers are indented by 2 spaces (Google indents by 4).
+
+### Templates
+* Leave one space after the `template` keyword, e.g. `template <typename T>` rather than `template<typename T>`.
+
+### Function Definition/Invocation
+* Newline when calling or defining a function: indent with 4 spaces.
+* We do not follow Google's style of wrapping on the open parenthesis, the general goal is to reduce visual "jaggedness" in the code. Prefer (1), (4), (5), sometimes (3), never (2):
+
+~~~{.cpp}
+// 1: OK.
+allocator->resourcesRecovered(frameworkId, slaveId, resources, filters);
+
+// 2: Don't use.
+allocator->resourcesRecovered(frameworkId, slaveId,
+ resources, filters);
+
+// 3: Don't use in this case due to "jaggedness".
+allocator->resourcesRecovered(frameworkId,
+ slaveId,
+ resources,
+ filters);
+
+// 3: In this case, 3 is OK.
+foobar(someArgument,
+ someOtherArgument,
+ theLastArgument);
+
+// 4: OK.
+allocator->resourcesRecovered(
+ frameworkId,
+ slaveId,
+ resources,
+ filters);
+
+// 5: OK.
+allocator->resourcesRecovered(
+ frameworkId, slaveId, resources, filters);
+~~~
+
+### Continuation
+* Newline for an assignment statement: indent with 2 spaces.
+
+~~~{.cpp}
+Try<Duration> failoverTimeout =
+ Duration::create(FrameworkInfo().failover_timeout());
+~~~
+
+## Empty Lines
+* 1 blank line at the end of the file.
+* Elements outside classes (classes, structs, global functions, etc.) should be spaced apart by 2 blank lines.
+* Elements inside classes (member variables and functions) should not be spaced apart by more than 1 blank line.
+
+## Capture by Reference
+
+We disallow capturing **temporaries** by reference. See [MESOS-2629](https://issues.apache.org/jira/browse/MESOS-2629) for the rationale.
+
+~~~{.cpp}
+Future<Nothing> f() { return Nothing(); }
+Future<bool> g() { return false; }
+
+struct T
+{
+ T(const char* data) : data(data) {}
+ const T& member() const { return *this; }
+ const char* data;
+};
+
+// 1: Don't use.
+const Future<Nothing>& future = f();
+
+// 1: Instead use.
+const Future<Nothing> future = f();
+
+// 2: Don't use.
+const Future<Nothing>& future = Future<Nothing>(Nothing());
+
+// 2: Instead use.
+const Future<Nothing> future = Future<Nothing>(Nothing());
+
+// 3: Don't use.
+const Future<bool>& future = f().then(lambda::bind(g));
+
+// 3: Instead use.
+const Future<bool> future = f().then(lambda::bind(g));
+
+// 4: Don't use (since the T that got constructed is a temporary!).
+const T& t = T("Hello").member();
+
+// 4: Preferred alias pattern (see below).
+const T t("Hello");
+const T& t_ = t.member();
+
+// 4: Can also use.
+const T t = T("Hello").member();
+~~~
+
+We allow capturing non-temporaries by *constant reference* when the intent is to **alias**.
+
+The goal is to make code more concise and improve readability. Use this if an expression referencing a field by `const` is:
+
+* Used repeatedly.
+* Would benefit from a concise name to provide context for readability.
+* Will **not** be invalidated during the lifetime of the alias. Otherwise document this explicitly.
+
+~~~{.cpp}
+hashmap<string, hashset<int>> index;
+
+// 1: Ok.
+const hashset<int>& values = index[2];
+
+// 2: Ok.
+for (auto iterator = index.begin(); iterator != index.end(); ++iterator) {
+ const hashset<int>& values = iterator->second;
+}
+
+// 3: Ok.
+foreachpair (const string& key, const hashset<int>& values, index) {}
+foreachvalue (const hashset<int>& values, index) {}
+foreachkey (const string& key, index) {}
+
+// 4: Avoid aliases in most circumstances as they can be dangerous.
+// This is an example of a dangling alias!
+vector<string> strings{"hello"};
+
+string& s = strings[0];
+
+strings.erase(strings.begin());
+
+s += "world"; // THIS IS A DANGLING REFERENCE!
+~~~
+
+## File Headers
+
+* Mesos source files must contain the "ASF" header:
+
+ /**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+
+* Stout and libprocess source files must contain the "Apache License Version 2.0" header:
+
+ /**
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License
+ */
+
+## C++11
+
+We support C++11 and require GCC 4.8+ or Clang 3.5+ compilers. The whitelist of supported C++11 features is:
+
+* Static assertions.
+* Multiple right angle brackets.
+* Type inference (`auto` and `decltype`). The main goal is to increase code readability. This is safely the case if the exact same type omitted on the left is already fully stated on the right. Here are several examples:
+
+~~~{.cpp}
+// 1: OK.
+const auto i = values.find(keys.front());
+// Compare with
+const typename map::iterator i = values.find(keys.front());
+
+// 2: OK.
+auto names = shared_ptr<list<string>>(new list<string>());
+// Compare with
+shared_ptr<list<string>> names = shared_ptr<list<string>>(new list<string>());
+
+// 3: Don't use.
+auto authorizer = LocalAuthorizer::create(acls);
+// Compare with
+Try<Owned<LocalAuthorizer>> authorizer = LocalAuthorizer::create();
+~~~
+
+* Rvalue references.
+* Explicitly-defaulted functions.
+* Variadic templates.
+* Delegating constructors.
+* Mutexes.
+ * `std::mutex`
+ * `std::lock_guard<std::mutex>`
+ * `std::unique_lock<std::mutex>`
+* Atomics (`std::atomic`)
+ * The standard defines a number of predefined typedefs for atomic types (e.g., `std::atomic_int`), in addition to `std::atomic<T>`. When a typedef is available, it should be preferred over explicit template specialization of `std::atomic<T>`.
+ * When reading from and writing to atomic values, the `load` and `store` member functions should be used instead of the overloads of `operator T()` and `operator=`. Being explicit helps to draw the reader's attention to the fact that atomic values are being manipulated.
+* Shared from this.
+ * `class T : public std::enable_shared_from_this<T>`
+ * `shared_from_this()`
+* Lambdas!
+ * Don't put a space between the capture list and the parameter list:
+
+~~~{.cpp}
+// 1: OK.
+[]() { ...; };
+
+// 2: Don't use.
+[] () { ...; };
+~~~
+
+ * Prefer default capture by value, explicit capture by value, then capture by reference. To avoid dangling-pointer bugs, *never* use default capture by reference:
+
+~~~{.cpp}
+// 1: OK.
+[=]() { ... }; // Default capture by value.
+[n]() { ... }; // Explicit capture by value.
+[&n]() { ... }; // Explicit capture by reference.
+[=, &n]() { ... }; // Default capture by value, explicit capture by reference.
+
+// 2: Don't use.
+[&]() { ... }; // Default capture by reference.
+~~~
+
+ * Use `mutable` only when absolutely necessary.
+
+~~~{.cpp}
+// 1: OK.
+[]() mutable { ...; };
+~~~
+
+ * Feel free to ignore the return type by default, adding it as necessary to appease the compiler or be more explicit for the reader.
+
+~~~{.cpp}
+// 1: OK.
+[]() { return true; };
+[]() -> bool { return ambiguous(); };
+~~~
+
+ * Feel free to use `auto` when naming a lambda expression:
+
+~~~{.cpp}
+// 1: OK.
+auto lambda = []() { ...; };
+~~~
+
+ * Format lambdas similar to how we format functions and methods. Feel free to let lambdas be one-liners:
+
+~~~{.cpp}
+// 1: OK.
+auto lambda = []() {
+ ...;
+};
+
+// 2: OK.
+auto lambda = []() { ...; };
+~~~
+
+ * Feel free to inline lambdas within function arguments:
+
+~~~{.cpp}
+instance.method([]() {
+ ...;
+});
+~~~
+
+ * Chain function calls on a newline after the closing brace of the lambda and the closing parenthesis of function call:
+
+~~~{.cpp}
+// 1: OK.
+instance
+ .method([]() {
+ ...;
+ })
+ .then([]() { ...; })
+ .then([]() {
+ ...;
+ });
+
+// 2: OK (when no chaining, compare to 1).
+instance.method([]() {
+ ...;
+});
+
+// 3: OK (if no 'instance.method').
+function([]() {
+ ...;
+})
+.then([]() { ...; })
+.then([]() {
+ ...;
+});
+
+// 3: OK (but prefer 1).
+instance.method([]() {
+ ...;
+})
+.then([]() { ...; })
+.then([]() {
+ ...;
+});
+~~~
+
+ * Wrap capture lists independently of parameters, *use the same formatting as if the capture list were template parameters*:
+
+~~~{.cpp}
+// 1: OK.
+function([&capture1, &capture2, &capture3](
+ const T1& p1, const T2& p2, const T3& p3) {
+ ...;
+});
+
+function(
+ [&capture1, &capture2, &capture3](
+ const T1& p1, const T2& p2, const T3& p3) {
+ ...;
+});
+
+auto lambda = [&capture1, &capture2, &capture3](
+ const T1& p1, const T2& p2, const T3& p3) {
+ ...;
+};
+
+auto lambda =
+ [&capture1, &capture2, &capture3](
+ const T1& p1, const T2& p2, const T3& p3) {
+ ...;
+};
+
+// 2: OK (when capture list is longer than 80 characters).
+function([
+ &capture1,
+ &capture2,
+ &capture3,
+ &capture4](
+ const T1& p1, const T2& p2) {
+ ...;
+});
+
+auto lambda = [
+ &capture1,
+ &capture2,
+ &capture3,
+ &capture4](
+ const T1& p1, const T2& p2) {
+ ...;
+};
+
+// 3: OK (but prefer 2).
+function([
+ &capture1,
+ &capture2,
+ &capture3,
+ &capture4](const T1& p1, const T2& t2) {
+ ...;
+});
+
+auto lambda = [
+ &capture1,
+ &capture2,
+ &capture3,
+ &capture4](const T1& p1, const T2& p2) {
+ ...;
+};
+
+// 3: Don't use.
+function([&capture1,
+ &capture2,
+ &capture3,
+ &capture4](const T1& p1, const T2& p2) {
+ ...;
+});
+
+auto lambda = [&capture1,
+ &capture2,
+ &capture3,
+ &capture4](const T1& p1, const T2& p2) {
+ ...;
+ };
+
+// 4: Don't use.
+function([&capture1,
+ &capture2,
+ &capture3,
+ &capture4](
+ const T1& p1, const T2& p2, const T3& p3) {
+ ...;
+});
+
+auto lambda = [&capture1,
+ &capture2,
+ &capture3,
+ &capture4](
+ const T1& p1, const T2& p2, const T3& p3) {
+ ...;
+};
+
+// 5: Don't use.
+function([&capture1,
+ &capture2,
+ &capture3,
+ &capture4](
+ const T1& p1,
+ const T2& p2,
+ const T3& p3) {
+ ...;
+ });
+
+auto lambda = [&capture1,
+ &capture2,
+ &capture3,
+ &capture4](
+ const T1& p1,
+ const T2& p2,
+ const T3& p3) {
+ ...;
+};
+
+// 6: OK (parameter list longer than 80 characters).
+function([&capture1, &capture2, &capture3](
+ const T1& p1,
+ const T2& p2,
+ const T3& p3,
+ const T4& p4) {
+ ...;
+});
+
+auto lambda = [&capture1, &capture2, &capture3](
+ const T1& p1,
+ const T2& p2,
+ const T3& p3,
+ const T4& p4) {
+ ...;
+};
+
+// 7: OK (capture and parameter lists longer than 80 characters).
+function([
+ &capture1,
+ &capture2,
+ &capture3,
+ &capture4](
+ const T1& p1,
+ const T2& p2,
+ const T3& p3,
+ const T4& p4) {
+ ...;
+});
+
+auto lambda = [
+ &capture1,
+ &capture2,
+ &capture3,
+ &capture4](
+ const T1& p1,
+ const T2& p2,
+ const T3& p3,
+ const T4& p4) {
+ ...;
+};
+~~~
+
+* Unrestricted Union.
+
+ Like the pre-existing `union`, we can overlap storage allocation for objects that never exist simultaneously. However, with C++11 we are no longer *restricted to having only non-POD types in unions*. Adding non-POD types to unions complicates things, however, because we need to make sure to properly call constructors and destructors. Therefore, only use unrestricted unions (i.e., unions with non-POD types) when the union has only a single field. What does this buy us? Now we can avoid dynamic memory allocations for "container" like types, e.g., `Option`, `Try`, `Result`, etc. In effect, we treat the union like a dynamic allocation, calling *placement new*, `new (&t) T(...)` anyplace we would have just called `new T(...)` and the destructor `t.~T()` anyplace we would have called `delete t`.
+
+* Constant expressions.
+
+ Constant expressions allow the declaration of static non-POD objects while eliminating the unpredictable runtime initialization and destruction issues normally encountered, helping eliminate macros and hard-coded literals without sacrificing performance and type safety. Changes which require converting from `constexpr` to `const` can propagate through the dependency tree requiring that dependent `constexpr` uses also be converted to `const`, hence we avoid using `constexpr` in complex functions.
+
+ `constexpr` behaves as a combination of `inline` and `const` and hence must be defined before use in another `constexpr`.
+
+ Prefer `constexpr` to `const` for all constant POD declarations, `constexpr` `char` arrays are preferred to `const` `string` literals.
+
+~~~{.cpp}
+ // OK
+ constexpr char LITERAL[] = "value";
+
+ // Not OK - not available at compile time for optimization and
+ // definition required in a separate compilation module.
+ const char LITERAL[];
+
+ // Not OK - uncertain initialization order, cannot be used in other
+ // constexpr statements.
+ const string LITERAL("value");
+~~~
+
+ `constexpr` functions are evaluated at compile time if all their arguments are constant expressions. Otherwise they default to initialization at runtime. However `constexpr` functions are limited in that they cannot perform dynamic casts, memory allocation or calls to non-constexpr functions. Prefer `constexpr` over const inline functions.
+
+~~~{.cpp}
+ constexpr size_t MIN = 200;
+ constexpr size_t MAX = 1000;
+ constexpr size_t SPAN() { return MAX-MIN; }
+ int array[SPAN()];
+~~~
+
+Const expression constructors allow object initialization at compile time provided that all the constructor arguments are `constexpr` and the constructor body is empty, i.e. all initialization is performed in the initialization list. Classes which provide `constexpr` constructors should normally also provide `constexpr` copy constructors to allow the class to be used in the return value from a `constexpr` function.
+
+~~~{.cpp}
+ class C
+ {
+ public:
+ constexpr C(int _i) : i(_i) {};
+ constexpr C(const C& c) : i(c.i) {}
+ private:
+ const int i;
+ };
+~~~
+
+ C++11 does not provide `constexpr string` or `constexpr` containers in the STL and hence `constexpr` cannot be used for any class using stout's Error() class.
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/clang-format.md
----------------------------------------------------------------------
diff --git a/docs/clang-format.md b/docs/clang-format.md
index e8f593f..0ad8dc3 100644
--- a/docs/clang-format.md
+++ b/docs/clang-format.md
@@ -6,7 +6,7 @@ layout: documentation
[ClangFormat](http://llvm.org/releases/3.5.1/tools/clang/docs/ClangFormat.html) is an automatic source code formatting tool which helps us focus on the code rather than the formatting.
-> The provided configurations try to honor the [Mesos C++ Style Guide](http://mesos.apache.org/documentation/latest/mesos-c++-style-guide/) as much as possible, but there are some limitations which require manual attention. Even with these limitations however, ClangFormat will be extremely useful for your workflow!
+> The provided configurations try to honor the [Mesos C++ Style Guide](http://mesos.apache.org/documentation/latest/c++-style-guide/) as much as possible, but there are some limitations which require manual attention. Even with these limitations however, ClangFormat will be extremely useful for your workflow!
## Setup
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/containerizer.md
----------------------------------------------------------------------
diff --git a/docs/containerizer.md b/docs/containerizer.md
new file mode 100644
index 0000000..ea19558
--- /dev/null
+++ b/docs/containerizer.md
@@ -0,0 +1,82 @@
+---
+layout: documentation
+---
+
+# Mesos Containerizer
+
+The MesosContainerizer provides lightweight containerization and
+resource isolation of executors using Linux-specific functionality
+such as control cgroups and namespaces. It is composable so operators
+can selectively enable different isolators.
+
+It also provides basic support for POSIX systems (e.g., OSX) but
+without any actual isolation, only resource usage reporting.
+
+### Shared Filesystem
+
+The SharedFilesystem isolator can optionally be used on Linux hosts to
+enable modifications to each container's view of the shared
+filesystem.
+
+The modifications are specified in the ContainerInfo included in the
+ExecutorInfo, either by a framework or by using the
+--default\_container\_info slave flag.
+
+ContainerInfo specifies Volumes which map parts of the shared
+filesystem (host\_path) into the container's view of the filesystem
+(container\_path), as read-write or read-only. The host\_path can be
+absolute, in which case it will make the filesystem subtree rooted at
+host\_path also accessible under container\_path for each container.
+If host\_path is relative then it is considered as a directory
+relative to the executor's work directory. The directory will be
+created and permissions copied from the corresponding directory (which
+must exist) in the shared filesystem.
+
+The primary use-case for this isolator is to selectively make parts of
+the shared filesystem private to each container. For example, a
+private "/tmp" directory can be achieved with host\_path="tmp" and
+container\_path="/tmp" which will create a directory "tmp" inside the
+executor's work directory (mode 1777) and simultaneously mount it as
+/tmp inside the container. This is transparent to processes running
+inside the container. Containers will not be able to see the host's
+/tmp or any other container's /tmp.
+
+### Pid Namespace
+
+The Pid Namespace isolator can be used to isolate each container in
+a separate pid namespace with two main benefits:
+1. Visibility: Processes running in the container (executor and
+ descendants) are unable to see or signal processes outside the
+ namespace.
+2. Clean termination: Termination of the leading process in a pid
+ namespace will result in the kernel terminating all other processes
+ in the namespace.
+
+The Launcher will use (2) during destruction of a container in
+preference to the freezer cgroup, avoiding known kernel issues related
+to freezing cgroups under OOM conditions.
+
+/proc will be mounted for containers so tools such as 'ps' will work
+correctly.
+
+
+### Posix Disk Isolator
+
+The Posix Disk isolator provides basic disk isolation. It is able to
+report the disk usage for each sandbox and optionally enforce the disk
+quota. It can be used on both Linux and OS X.
+
+To enable the Posix Disk isolator, append `posix/disk` to the
+`--isolation` flag when starting the slave.
+
+By default, the disk quota enforcement is disabled. To enable it,
+specify `--enforce_container_disk_quota` when starting the slave.
+
+The Posix Disk isolator reports disk usage for each sandbox by
+periodically running the `du` command. The disk usage can be retrieved
+from the resource statistics endpoint (`/monitor/statistics.json`).
+
+The interval between two `du`s can be controlled by the slave flag
+`--container_disk_watch_interval`. For example,
+`--container_disk_watch_interval=1mins` sets the interval to be 1
+minute. The default interval is 15 seconds.
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/documentation-guide.md
----------------------------------------------------------------------
diff --git a/docs/documentation-guide.md b/docs/documentation-guide.md
new file mode 100644
index 0000000..9548bca
--- /dev/null
+++ b/docs/documentation-guide.md
@@ -0,0 +1,37 @@
+# Mesos Documentation Guide
+
+Documentation is an integral part of every good feature. It describes the intended usage and enables new users to start using and understanding the feature.
+
+We have three different kinds of documentation:
+
+
+1. [MarkDown User Guides](/documentation/latest/markdown-style-guide/)
+
+ User guides and non-code technical documentation are stored in markdown files in the `docs/` folder. These files get rendered for the [online documentation](http://mesos.apache.org/documentation/latest/).
+
+ We will accept small documentation changes on [Github via a pull request](https://github.com/apache/mesos), larger documentation changes should go through the (reviewboard)[https://reviews.apache.org/groups/mesos/]
+
+
+2. [Doxygen API Documentation and Developer Guides as part of source code](/documentation/latest/doxygen-style-guide/)
+
+ Doxygen API documentation needs only to be applied to source code parts that
+ constitute an interface for which we want to generate Mesos API documentation
+ files. Implementation code that does not participate in this should still be
+ enhanced by source code comments as appropriate, but these comments should not follow the doxygen style.
+
+ Substantial libraries, components, and subcomponents of the Mesos system such as
+ stout, libprocess, master, slave, containerizer, allocator, and others
+ should have an overview page in markdown format that explains their
+ purpose, overall structure, and general use. This can even be a complete developer guide.
+
+
+3. Regular source code documentation
+
+ All other source code comments must follow the [Google Style Guide](https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Comments).
+
+
+## Conventions
+
+We follow the [IETF RFC 2119](https://www.ietf.org/rfc/rfc2119.txt)
+on how to use words such as "must", "should", "can",
+and other requirement-related notions.
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/doxygen-style-guide.md
----------------------------------------------------------------------
diff --git a/docs/doxygen-style-guide.md b/docs/doxygen-style-guide.md
new file mode 100644
index 0000000..1bd3b3d
--- /dev/null
+++ b/docs/doxygen-style-guide.md
@@ -0,0 +1,196 @@
+# Apache Mesos Doxygen Style Guide
+
+This guide introduces a consistent style
+for [documenting Mesos source code](http://mesos.apache.org/api/latest/c++)
+using [Doxygen](http://www.doxygen.org).
+There is an ongoing, incremental effort with the goal to document all public Mesos, libprocess, and stout APIs this way.
+For now, existing code may not follow these guidelines, but new code should.
+
+
+## Source Code Documentation Syntax
+
+Doxygen documentation needs only to be applied to source code parts that
+constitute an interface for which we want to generate Mesos API documentation
+files. Implementation code that does not participate in this should still be
+enhanced by source code comments as appropriate, but these comments should not follow the doxygen style.
+
+We follow the [Javadoc syntax](http://en.wikipedia.org/wiki/Javadoc) to mark comment blocks.
+These have the general form:
+
+
+<!-- NOTE: In order to show the comments as part of the code blocks in
+this we must use indentation instead of fenced code blocks (i.e.,
+~~~{.cpp}) because doxygen will remove all of the comments and just
+render the code. -->
+
+
+ /**
+ * Brief summary.
+ *
+ * Detailed description. More detail.
+ * @see Some reference
+ *
+ * @param <name> Parameter description.
+ * @return Return value description.
+ */
+
+Example:
+
+ /**
+ * Returns a compressed version of a string.
+ *
+ * Compresses an input string using the foobar algorithm.
+ *
+ * @param uncompressed The input string.
+ * @return A compressed version of the input string.
+ */
+ std::string compress(const std::string& uncompressed);
+
+
+### Doxygen Tags
+
+This is the allowed set of doxygen tags that can be used.
+
+ * [\@param](http://doxygen.org/manual/commands.html#cmdparam) Describes function parameters.
+ * [\@return](http://doxygen.org/manual/commands.html#cmdreturn) Describes return values.
+ * [\@see](http://doxygen.org/manual/commands.html#cmdsa) Describes a cross-reference to classes, functions, methods, variables, files or URL.
+
+Example:
+
+ /**
+ * Available kinds of implementations.
+ *
+ * @see process::network::PollSocketImpl
+ */
+
+ * [\@file](http://doxygen.org/manual/commands.html#cmdfile) Describes a refence to a file. It is required when documenting global functions, variables, typedefs, or enums in separate files.
+ * [\@link](http://doxygen.org/manual/commands.html#cmdlink) and [\@endlink](http://doxygen.org/manual/commands.html#cmdendlink) Describes a link to a file, class, or member.
+ * [\@example](http://doxygen.org/manual/commands.html#cmdexample) Describes source code examples.
+ * [\@image](http://doxygen.org/manual/commands.html#cmdimage) Describes an image.
+
+ * When following these links be aware that the doxygen documentation is using another syntax in that \@param is explained as \\param.
+
+
+### Wrapping
+
+We wrap long descriptions using four spaces on the next line.
+
+ @param uncompressed The input string that requires
+ a very long description and an even longer
+ description on this line as well.
+
+
+### Constants and Variables
+
+Example:
+
+ /**
+ * Prefix used to name Docker containers in order to distinguish
+ * those created by Mesos from those created manually.
+ */
+ extern const std::string DOCKER_NAME_PREFIX;
+
+
+#### Fields
+
+Example:
+
+ /**
+ * The parent side of the pipe for stdin.
+ * If the mode is not PIPE, None will be stored.
+ * **NOTE**: stdin is a macro on some systems, hence this name instead.
+ */
+ Option<int> in;
+
+
+### Functions and Methods
+
+Example:
+
+ /**
+ * Forks a subprocess and execs the specified 'path' with the
+ * specified 'argv', redirecting stdin, stdout, and stderr as
+ * specified by 'in', 'out', and 'err' respectively.
+ *
+ * If 'setup' is not None, runs the specified function after forking
+ * but before exec'ing. If the return value of 'setup' is non-zero
+ * then that gets returned in 'status()' and we will not exec.
+ *
+ * @param path Relative or absolute path in the filesytem to the
+ * executable.
+ * @param argv Argument vector to pass to exec.
+ * @param in Redirection specification for stdin.
+ * @param out Redirection specification for stdout.
+ * @param err Redirection specification for stderr.
+ * @param flags Flags to be stringified and appended to 'argv'.
+ * @param environment Environment variables to use for the new
+ * subprocess or if None (the default) then the new subprocess
+ * will inherit the environment of the current process.
+ * @param setup Function to be invoked after forking but before
+ * exec'ing. NOTE: Take extra care not to invoke any
+ * async unsafe code in the body of this function.
+ * @param clone Function to be invoked in order to fork/clone the
+ * subprocess.
+ * @return The subprocess or an error if one occurred.
+ */
+ Try<Subprocess> subprocess(
+ const std::string& path,
+ std::vector<std::string> argv,
+ const Subprocess::IO& in = Subprocess::FD(STDIN_FILENO),
+ const Subprocess::IO& out = Subprocess::FD(STDOUT_FILENO),
+ const Subprocess::IO& err = Subprocess::FD(STDERR_FILENO),
+ const Option<flags::FlagsBase>& flags = None(),
+ const Option<std::map<std::string, std::string>>& environment = None(),
+ const Option<lambda::function<int()>>& setup = None(),
+ const Option<lambda::function<
+ pid_t(const lambda::function<int()>&)>>& clone = None());
+
+
+### Classes and Structs
+
+Example:
+
+ /**
+ * Represents a fork() exec()ed subprocess. Access is provided to the
+ * input / output of the process, as well as the exit status. The
+ * input / output file descriptors are only closed after:
+ * 1. The subprocess has terminated.
+ * 2. There are no longer any references to the associated
+ * Subprocess object.
+ */
+ class Subprocess
+ {
+ public:
+
+
+## Library and Component Overview Pages and Developer Guides
+
+Substantial libraries, components, and subcomponents of the Mesos system such as
+stout, libprocess, master, slave, containerizer, allocator, and others
+should have an overview page in markdown format that explains their
+purpose, overall structure, and general use. This can even be a complete developer guide.
+
+This page must be located in the top directory of the library/component and named "README.md".
+
+The first line in such a document must be a section heading bearing the title which will appear in the generated Doxygen index.
+Example: "# Libprocess Developer Guide"
+
+### Example Code
+
+C++ code examples should be enclosed by '~~~{.cpp}'.
+
+Example:
+
+~~~{.cpp}
+int main(int argc, char** argv)
+{
+ ...
+}
+~~~
+
+**NOTE**: Because of shortcomings of Doxygen's markdown parser we currently use indentation for wrapping all non C++ code blocks.
+
+
+## Building Doxygen Documentation
+
+As of right now, the Doxygen documentation should be built from the *build* subdirectory using *doxygen ../Doxyfile* . The documentation will then be generated into the *./doxygen* subdirectory.
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/effective-code-reviewing.md
----------------------------------------------------------------------
diff --git a/docs/effective-code-reviewing.md b/docs/effective-code-reviewing.md
index ff6507c..25d7126 100644
--- a/docs/effective-code-reviewing.md
+++ b/docs/effective-code-reviewing.md
@@ -22,7 +22,7 @@ to consider before sending review requests:
change clear in the review request, so the reviewer is not left
guessing. It is highly recommended to attach a JIRA issue with your
review for additional context.
-4. **Follow the [style guide](http://mesos.apache.org/documentation/latest/mesos-c++-style-guide/)
+4. **Follow the [style guide](http://mesos.apache.org/documentation/latest/c++-style-guide/)
and the style of code around you**.
5. **Do a self-review of your changes before publishing**: Approach it
from the perspective of a reviewer with no context. Is it easy to figure
@@ -88,4 +88,4 @@ review process.
6. **For reviewers, be thorough when giving a 'ship it'**: understand that
reviewing requires a substantial investment of time and focus:
a. You are expected to understand and support code that you're giving a 'ship it' to.
- b. You are expected to be accountable for the quality of the code you've given a 'ship it' to.
\ No newline at end of file
+ b. You are expected to be accountable for the quality of the code you've given a 'ship it' to.
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/frameworks.md
----------------------------------------------------------------------
diff --git a/docs/frameworks.md b/docs/frameworks.md
new file mode 100644
index 0000000..60405b1
--- /dev/null
+++ b/docs/frameworks.md
@@ -0,0 +1,34 @@
+---
+layout: documentation
+---
+# Software projects built on Mesos
+
+## Long Running Services
+
+* [Aurora](http://aurora.incubator.apache.org) is a service scheduler that runs on top of Mesos, enabling you to run long-running services that take advantage of Mesos' scalability, fault-tolerance, and resource isolation.
+* [Marathon](https://github.com/mesosphere/marathon) is a private PaaS built on Mesos. It automatically handles hardware or software failures and ensures that an app is "always on".
+* [Singularity](https://github.com/HubSpot/Singularity) is a scheduler (HTTP API and web interface) for running Mesos tasks: long running processes, one-off tasks, and scheduled jobs.
+* [SSSP](https://github.com/mesosphere/sssp) is a simple web application that provides a white-label "Megaupload" for storing and sharing files in S3.
+
+## Big Data Processing
+
+* [Cray Chapel](https://github.com/nqn/mesos-chapel) is a productive parallel programming language. The Chapel Mesos scheduler lets you run Chapel programs on Mesos.
+* [Dpark](https://github.com/douban/dpark) is a Python clone of Spark, a MapReduce-like framework written in Python, running on Mesos.
+* [Exelixi](https://github.com/mesosphere/exelixi) is a distributed framework for running genetic algorithms at scale.
+* [Hadoop](https://github.com/mesos/hadoop) Running Hadoop on Mesos distributes MapReduce jobs efficiently across an entire cluster.
+* [Hama](http://wiki.apache.org/hama/GettingStartedMesos) is a distributed computing framework based on Bulk Synchronous Parallel computing techniques for massive scientific computations e.g., matrix, graph and network algorithms.
+* [MPI](https://github.com/mesosphere/mesos-hydra) is a message-passing system designed to function on a wide variety of parallel computers.
+* [Spark](http://spark.incubator.apache.org/) is a fast and general-purpose cluster computing system which makes parallel jobs easy to write.
+* [Storm](https://github.com/mesosphere/storm-mesos) is a distributed realtime computation system. Storm makes it easy to reliably process unbounded streams of data, doing for realtime processing what Hadoop did for batch processing.
+
+## Batch Scheduling
+
+* [Chronos](https://github.com/airbnb/chronos) is a distributed job scheduler that supports complex job topologies. It can be used as a more fault-tolerant replacement for Cron.
+* [Jenkins](https://github.com/jenkinsci/mesos-plugin) is a continuous integration server. The mesos-jenkins plugin allows it to dynamically launch workers on a Mesos cluster depending on the workload.
+* [JobServer](http://www.grandlogic.com/content/html_docs/jobserver.html) is a distributed job scheduler and processor which allows developers to build custom batch processing Tasklets using point and click web UI.
+
+## Data Storage
+
+* [Cassandra](https://github.com/mesosphere/cassandra-mesos) is a performant and highly available distributed database. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data.
+* [ElasticSearch](https://github.com/mesosphere/elasticsearch-mesos) is a distributed search engine. Mesos makes it easy to run and scale.
+* [Hypertable](https://code.google.com/p/hypertable/wiki/Mesos) is a high performance, scalable, distributed storage and processing system for structured and unstructured data.
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/home.md
----------------------------------------------------------------------
diff --git a/docs/home.md b/docs/home.md
index e7d6930..af88625 100644
--- a/docs/home.md
+++ b/docs/home.md
@@ -6,14 +6,14 @@ layout: documentation
## Mesos Fundamentals
-* [Mesos Architecture](/documentation/latest/mesos-architecture/) providing an overview of Mesos concepts.
-* [Video and Slides of Mesos Presentations](/documentation/latest/mesos-presentations/)
+* [Mesos Architecture](/documentation/latest/architecture/) providing an overview of Mesos concepts.
+* [Video and Slides of Mesos Presentations](/documentation/latest/presentations/)
## Running Mesos
* [Getting Started](/documentation/latest/getting-started/) for basic instructions on compiling and installing Mesos.
* [Configuration](/documentation/latest/configuration/) for command-line arguments.
-* [Mesos Containerizer](/documentation/latest/mesos-containerizer/) default containerizer, supports both Linux and POSIX systems.
+* [Mesos Containerizer](/documentation/latest/containerizer/) default containerizer, supports both Linux and POSIX systems.
* [Docker Containerizer](/documentation/latest/docker-containerizer/) for launching a Docker image as a Task, or as an Executor.
* [External Containerizer](/documentation/latest/external-containerizer/) for custom containerization implementations.
* [Framework Authentication](/documentation/latest/authentication/)
@@ -27,7 +27,7 @@ layout: documentation
* [Slave Recovery](/documentation/latest/slave-recovery/) for doing seamless upgrades.
* [Maintenance](/documentation/latest/maintenance/) for performing maintenance on a Mesos cluster.
* [Tools](/documentation/latest/tools/) for setting up and running a Mesos cluster.
-* [SSL](/documentation/latest/mesos-ssl/) for enabling and enforcing SSL communication.
+* [SSL](/documentation/latest/ssl/) for enabling and enforcing SSL communication.
## Advanced Features
@@ -40,13 +40,13 @@ layout: documentation
## Running Mesos Frameworks
- * [Mesos frameworks](/documentation/latest/mesos-frameworks/) for a list of apps built on top of Mesos and instructions on how to run them.
+ * [Mesos frameworks](/documentation/latest/frameworks/) for a list of apps built on top of Mesos and instructions on how to run them.
## Developing Mesos Frameworks
* [Framework Development Guide](/documentation/latest/app-framework-development-guide/) describes how to build applications on top of Mesos.
* [Reconciliation](/documentation/latest/reconciliation/) for ensuring a framework's state remains eventually consistent in the face of failures.
-* [Scheduler HTTP API](/documentation/latest/scheduler_http_api/) describes the new HTTP API for communication between schedulers and the Mesos master.
+* [Scheduler HTTP API](/documentation/latest/scheduler-http-api/) describes the new HTTP API for communication between schedulers and the Mesos master.
* [Javadoc](/api/latest/java/) documents the Mesos Java API.
* [Doxygen](/api/latest/c++/namespacemesos.html) documents the Mesos C++ API.
* [Developer Tools](/documentation/latest/tools/) for hacking on Mesos or writing frameworks.
@@ -60,17 +60,17 @@ layout: documentation
* [Reporting an Issue, Improvement, or Feature](/documentation/latest/reporting-a-bug/) for getting started with JIRA.
* [Submitting a Patch](/documentation/latest/submitting-a-patch/) for getting started with ReviewBoard and our tooling around it.
-* [Testing Patterns](/documentation/latest/mesos-testing-patterns/) for tips and tricks used in Mesos tests.
+* [Testing Patterns](/documentation/latest/testing-patterns/) for tips and tricks used in Mesos tests.
* [Effective Code Reviewing](/documentation/latest/effective-code-reviewing/) guidelines, tips, and learnings for how to do effective code reviews.
* [Engineering Principles and Practices](/documentation/latest/engineering-principles-and-practices/) to serve as a shared set of project-level values for the community.
* [Committing](/documentation/latest/committing/) guidelines for committing changes.
* [Committers and Maintainers](/documentation/latest/committers/) a listing of project committers and component maintainers; useful when seeking feedback.
* [Doxygen](/api/latest/c++/) documents the internal Mesos APIs.
-* [Documentation Guide](/documentation/latest/mesos-documentation-guide/)
- * [C++ Style Guide](/documentation/latest/mesos-c++-style-guide/)
- * [Doxygen Style Guide](/documentation/latest/mesos-doxygen-style-guide/)
- * [Markdown Style Guide](/documentation/latest/mesos-markdown-style-guide/)
-* [Development Roadmap](/documentation/latest/mesos-roadmap/)
+* [Documentation Guide](/documentation/latest/documentation-guide/)
+ * [C++ Style Guide](/documentation/latest/c++-style-guide/)
+ * [Doxygen Style Guide](/documentation/latest/doxygen-style-guide/)
+ * [Markdown Style Guide](/documentation/latest/markdown-style-guide/)
+* [Development Roadmap](/documentation/latest/roadmap/)
* [Release Guide](/documentation/latest/release-guide/)
## More Info about Mesos
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/markdown-style-guide.md
----------------------------------------------------------------------
diff --git a/docs/markdown-style-guide.md b/docs/markdown-style-guide.md
new file mode 100644
index 0000000..fe9ffef
--- /dev/null
+++ b/docs/markdown-style-guide.md
@@ -0,0 +1,118 @@
+# Mesos Markdown Style Guide
+
+This guide introduces a consistent documentation style to be used across the entire non-code documentation.
+User guides and non-code technical documentation are stored in markdown files in the `docs/` folder. These files get rendered for the [online documentation](http://mesos.apache.org/documentation/latest/).
+
+**NOTE:** As of right now this is work in progress and the existing documentation might not yet comply to this style.
+
+
+## What to document?
+
+Any new substantial feature should be documented in its own markdown file.
+If the link between source code and documentation is not obvious, consider inserting a short code comment stating that there is non-code documentation that needs to be kept in sync and indicating where it is located.
+
+
+## Keep documentation and style-guides in sync with code.
+
+When changing code consider whether you need to update the documentation.
+This is especially relevant when introducing new or updating existing command line flags.
+These should be reflected in `configuration.md`!
+
+
+## Code Examples
+
+Code examples should be specified as follows:
+
+ ~~~{.cpp}
+ int main(int argc, char** argv)
+ {
+ ....
+ }
+ ~~~
+
+**NOTE:** Because of shortcomings of Doxygen's markdown parser we currently use indentation for wrapping all non C++ code blocks.
+
+## Notes/Emphasis
+
+Notes are used to highlight important parts of the text and should be specified as follows.
+
+~~~{.txt}
+**NOTE:** Short note.
+Continued longer note.
+~~~
+
+We use single backticks to highlight individual words in a sentence such as certain identifiers:
+
+~~~{.txt}
+Use the default `HierarchicalDRF` allocator....
+~~~
+
+
+## Commands
+
+We use single backticks to highlight sample commands as follows:
+
+~~~{.txt}
+`mesos-master --help`
+~~~
+
+
+## Files/Path
+
+Files and path references should be specified as follows:
+
+~~~{.text}
+Remember you can also use the `file:///path/to/file` or `/path/to/file`
+~~~
+
+
+## Tables
+
+In order to avoid problems with markdown formatting we should specify tables in html directly:
+
+~~~{.html}
+<table class="table table-striped">
+ <thead>
+ <tr>
+ <th width="30%">
+ Flag
+ </th>
+ <th>
+ Explanation
+ </th>
+ </thead>
+ <tr>
+ <td>
+ --ip=VALUE
+ </td>
+ <td>
+ IP address to listen on
+ </td>
+ </tr>
+ <tr>
+ <td>
+ --[no-]help
+ </td>
+ <td>
+ Prints this help message (default: false)
+
+ </td>
+ </tr>
+</table>
+~~~
+
+
+## Indendation and Whitespace
+
+We use no extra indentation in markdown files.
+We have one new line after section headings and two blank lines
+in between sections.
+
+~~~{.txt}
+... end of previous section.
+
+
+## New Section
+
+Beginning of new section ....
+~~~
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/mesos-architecture.md
----------------------------------------------------------------------
diff --git a/docs/mesos-architecture.md b/docs/mesos-architecture.md
deleted file mode 100644
index 439a56d..0000000
--- a/docs/mesos-architecture.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-layout: documentation
----
-
-# Mesos Architecture
-
-
-
-The above figure shows the main components of Mesos. Mesos consists of a *master* daemon that manages *slave* daemons running on each cluster node, and *mesos applications* (also called *frameworks*) that run *tasks* on these slaves.
-
-The master enables fine-grained sharing of resources (cpu, ram, ...) across applications by making them *resource offers*. Each resource offer contains a list of <slave ID, resource1: amount1, resource2, amount2, ...>. The master decides *how many* resources to offer to each framework according to a given organizational policy, such as fair sharing, or strict priority. To support a diverse set of policies, the master employs a modular architecture that makes it easy to add new allocation modules via a plugin mechanism.
-
-A framework running on top of Mesos consists of two components: a *scheduler* that registers with the master to be offered resources, and an *executor* process that is launched on slave nodes to run the framework's tasks (see the [App/Framework development guide](app-framework-development-guide.md) for more details about application schedulers and executors). While the master determines **how many** resources are offered to each framework, the frameworks' schedulers select **which** of the offered resources to use. When a frameworks accepts offered resources, it passes to Mesos a description of the tasks it wants to run on them. In turn, Mesos launches the tasks on the corresponding slaves.
-
-## Example of resource offer
-
-The figure below shows an example of how a framework gets scheduled to run a task.
-
-
-
-Let's walk through the events in the figure.
-
-1. Slave 1 reports to the master that it has 4 CPUs and 4 GB of memory free. The master then invokes the allocation policy module, which tells it that framework 1 should be offered all available resources.
-1. The master sends a resource offer describing what is available on slave 1 to framework 1.
-1. The framework's scheduler replies to the master with information about two tasks to run on the slave, using <2 CPUs, 1 GB RAM> for the first task, and <1 CPUs, 2 GB RAM> for the second task.
-1. Finally, the master sends the tasks to the slave, which allocates appropriate resources to the framework's executor, which in turn launches the two tasks (depicted with dotted-line borders in the figure). Because 1 CPU and 1 GB of RAM are still unallocated, the allocation module may now offer them to framework 2.
-
-In addition, this resource offer process repeats when tasks finish and new resources become free.
-
-While the thin interface provided by Mesos allows it to scale and allows the frameworks to evolve independently, one question remains: how can the constraints of a framework be satisfied without Mesos knowing about these constraints? For example, how can a framework achieve data locality without Mesos knowing which nodes store the data required by the framework? Mesos answers these questions by simply giving frameworks the ability to **reject** offers. A framework will reject the offers that do not satisfy its constraints and accept the ones that do. In particular, we have found that a simple policy called delay scheduling, in which frameworks wait for a limited time to acquire nodes storing the input data, yields nearly optimal data locality.
-
-You can also read much more about the Mesos architecture in this [technical paper](http://mesos.berkeley.edu/mesos_tech_report.pdf).
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/mesos-c++-style-guide.md
----------------------------------------------------------------------
diff --git a/docs/mesos-c++-style-guide.md b/docs/mesos-c++-style-guide.md
deleted file mode 100644
index 0b61891..0000000
--- a/docs/mesos-c++-style-guide.md
+++ /dev/null
@@ -1,579 +0,0 @@
----
-layout: documentation
----
-
-# Mesos C++ Style Guide
-
-The Mesos codebase follows the [Google C++ Style Guide](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml) with some notable differences, as described below. Note that the [clang-format](/documentation/latest/clang-format/) tool can be helpful to ensure that some of the mechanical style rules are obeyed.
-
-## Scoping
-
-### Namespaces
-* We avoid `using namespace foo` statements as it is not explicit about which symbols are pulled in, and it can often pull in a lot of symbols, which sometimes lead to conflicts.
-* It is OK to use namespace aliases to help pull in sub-namespaces, such as `namespace http = process::http;`. These should only be present at the top of the .cpp file.
-
-## Naming
-
-### Variable Names
-* We use [lowerCamelCase](http://en.wikipedia.org/wiki/CamelCase#Variations_and_synonyms) for variable names (Google uses snake_case, and their class member variables have trailing underscores).
-* We prepend constructor and function arguments with a leading underscore to avoid ambiguity and / or shadowing:
-
-~~~{.cpp}
-Try(State _state, T* _t = NULL, const std::string& _message = "")
- : state(_state), t(_t), message(_message) {}
-~~~
-
-* Prefer trailing underscores for use as member fields (but not required). Some trailing underscores are used to distinguish between similar variables in the same scope (think prime symbols), *but this should be avoided as much as possible, including removing existing instances in the code base.*
-
-* If you find yourself creating a copy of an argument passed by const reference, consider passing it by value instead (if you don't want to use a leading underscore and copy in the body of the function):
-
-~~~{.cpp}
-// You can pass-by-value in ProtobufProcess::install() handlers.
-void Slave::statusUpdate(StatusUpdate update, const UPID& pid)
-{
- ...
- update.mutable_status()->set_source(
- pid == UPID() ? TaskStatus::SOURCE_SLAVE : TaskStatus::SOURCE_EXECUTOR);
- ...
-}
-~~~
-
-### Constant Names
-* We use [SCREAMING_SNAKE_CASE](http://en.wikipedia.org/wiki/Letter_case#Special_case_styles) for constant names (Google uses a `k` followed by mixed case, e.g. `kDaysInAWeek`).
-
-### Function Names
-* We use [lowerCamelCase](http://en.wikipedia.org/wiki/CamelCase#Variations_and_synonyms) for function names (Google uses mixed case for regular functions; and their accessors and mutators match the name of the variable).
-
-## Strings
-* Strings used in log and error messages should end without a period.
-
-## Comments
-* End each sentence within a comment with a punctuation mark (please note that we generally prefer periods); this applies to incomplete sentences as well.
-* For trailing comments, leave one space.
-
-## Breaks
-* Break before braces on enum, function, and record (i.e. struct, class, union) definitions.
-
-## Indentation
-
-### Class Format
-* Access modifiers are not indented (Google uses one space indentation).
-* Constructor initializers are indented by 2 spaces (Google indents by 4).
-
-### Templates
-* Leave one space after the `template` keyword, e.g. `template <typename T>` rather than `template<typename T>`.
-
-### Function Definition/Invocation
-* Newline when calling or defining a function: indent with 4 spaces.
-* We do not follow Google's style of wrapping on the open parenthesis, the general goal is to reduce visual "jaggedness" in the code. Prefer (1), (4), (5), sometimes (3), never (2):
-
-~~~{.cpp}
-// 1: OK.
-allocator->resourcesRecovered(frameworkId, slaveId, resources, filters);
-
-// 2: Don't use.
-allocator->resourcesRecovered(frameworkId, slaveId,
- resources, filters);
-
-// 3: Don't use in this case due to "jaggedness".
-allocator->resourcesRecovered(frameworkId,
- slaveId,
- resources,
- filters);
-
-// 3: In this case, 3 is OK.
-foobar(someArgument,
- someOtherArgument,
- theLastArgument);
-
-// 4: OK.
-allocator->resourcesRecovered(
- frameworkId,
- slaveId,
- resources,
- filters);
-
-// 5: OK.
-allocator->resourcesRecovered(
- frameworkId, slaveId, resources, filters);
-~~~
-
-### Continuation
-* Newline for an assignment statement: indent with 2 spaces.
-
-~~~{.cpp}
-Try<Duration> failoverTimeout =
- Duration::create(FrameworkInfo().failover_timeout());
-~~~
-
-## Empty Lines
-* 1 blank line at the end of the file.
-* Elements outside classes (classes, structs, global functions, etc.) should be spaced apart by 2 blank lines.
-* Elements inside classes (member variables and functions) should not be spaced apart by more than 1 blank line.
-
-## Capture by Reference
-
-We disallow capturing **temporaries** by reference. See [MESOS-2629](https://issues.apache.org/jira/browse/MESOS-2629) for the rationale.
-
-~~~{.cpp}
-Future<Nothing> f() { return Nothing(); }
-Future<bool> g() { return false; }
-
-struct T
-{
- T(const char* data) : data(data) {}
- const T& member() const { return *this; }
- const char* data;
-};
-
-// 1: Don't use.
-const Future<Nothing>& future = f();
-
-// 1: Instead use.
-const Future<Nothing> future = f();
-
-// 2: Don't use.
-const Future<Nothing>& future = Future<Nothing>(Nothing());
-
-// 2: Instead use.
-const Future<Nothing> future = Future<Nothing>(Nothing());
-
-// 3: Don't use.
-const Future<bool>& future = f().then(lambda::bind(g));
-
-// 3: Instead use.
-const Future<bool> future = f().then(lambda::bind(g));
-
-// 4: Don't use (since the T that got constructed is a temporary!).
-const T& t = T("Hello").member();
-
-// 4: Preferred alias pattern (see below).
-const T t("Hello");
-const T& t_ = t.member();
-
-// 4: Can also use.
-const T t = T("Hello").member();
-~~~
-
-We allow capturing non-temporaries by *constant reference* when the intent is to **alias**.
-
-The goal is to make code more concise and improve readability. Use this if an expression referencing a field by `const` is:
-
-* Used repeatedly.
-* Would benefit from a concise name to provide context for readability.
-* Will **not** be invalidated during the lifetime of the alias. Otherwise document this explicitly.
-
-~~~{.cpp}
-hashmap<string, hashset<int>> index;
-
-// 1: Ok.
-const hashset<int>& values = index[2];
-
-// 2: Ok.
-for (auto iterator = index.begin(); iterator != index.end(); ++iterator) {
- const hashset<int>& values = iterator->second;
-}
-
-// 3: Ok.
-foreachpair (const string& key, const hashset<int>& values, index) {}
-foreachvalue (const hashset<int>& values, index) {}
-foreachkey (const string& key, index) {}
-
-// 4: Avoid aliases in most circumstances as they can be dangerous.
-// This is an example of a dangling alias!
-vector<string> strings{"hello"};
-
-string& s = strings[0];
-
-strings.erase(strings.begin());
-
-s += "world"; // THIS IS A DANGLING REFERENCE!
-~~~
-
-## File Headers
-
-* Mesos source files must contain the "ASF" header:
-
- /**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-
-* Stout and libprocess source files must contain the "Apache License Version 2.0" header:
-
- /**
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License
- */
-
-## C++11
-
-We support C++11 and require GCC 4.8+ or Clang 3.5+ compilers. The whitelist of supported C++11 features is:
-
-* Static assertions.
-* Multiple right angle brackets.
-* Type inference (`auto` and `decltype`). The main goal is to increase code readability. This is safely the case if the exact same type omitted on the left is already fully stated on the right. Here are several examples:
-
-~~~{.cpp}
-// 1: OK.
-const auto i = values.find(keys.front());
-// Compare with
-const typename map::iterator i = values.find(keys.front());
-
-// 2: OK.
-auto names = shared_ptr<list<string>>(new list<string>());
-// Compare with
-shared_ptr<list<string>> names = shared_ptr<list<string>>(new list<string>());
-
-// 3: Don't use.
-auto authorizer = LocalAuthorizer::create(acls);
-// Compare with
-Try<Owned<LocalAuthorizer>> authorizer = LocalAuthorizer::create();
-~~~
-
-* Rvalue references.
-* Explicitly-defaulted functions.
-* Variadic templates.
-* Delegating constructors.
-* Mutexes.
- * `std::mutex`
- * `std::lock_guard<std::mutex>`
- * `std::unique_lock<std::mutex>`
-* Atomics (`std::atomic`)
- * The standard defines a number of predefined typedefs for atomic types (e.g., `std::atomic_int`), in addition to `std::atomic<T>`. When a typedef is available, it should be preferred over explicit template specialization of `std::atomic<T>`.
- * When reading from and writing to atomic values, the `load` and `store` member functions should be used instead of the overloads of `operator T()` and `operator=`. Being explicit helps to draw the reader's attention to the fact that atomic values are being manipulated.
-* Shared from this.
- * `class T : public std::enable_shared_from_this<T>`
- * `shared_from_this()`
-* Lambdas!
- * Don't put a space between the capture list and the parameter list:
-
-~~~{.cpp}
-// 1: OK.
-[]() { ...; };
-
-// 2: Don't use.
-[] () { ...; };
-~~~
-
- * Prefer default capture by value, explicit capture by value, then capture by reference. To avoid dangling-pointer bugs, *never* use default capture by reference:
-
-~~~{.cpp}
-// 1: OK.
-[=]() { ... }; // Default capture by value.
-[n]() { ... }; // Explicit capture by value.
-[&n]() { ... }; // Explicit capture by reference.
-[=, &n]() { ... }; // Default capture by value, explicit capture by reference.
-
-// 2: Don't use.
-[&]() { ... }; // Default capture by reference.
-~~~
-
- * Use `mutable` only when absolutely necessary.
-
-~~~{.cpp}
-// 1: OK.
-[]() mutable { ...; };
-~~~
-
- * Feel free to ignore the return type by default, adding it as necessary to appease the compiler or be more explicit for the reader.
-
-~~~{.cpp}
-// 1: OK.
-[]() { return true; };
-[]() -> bool { return ambiguous(); };
-~~~
-
- * Feel free to use `auto` when naming a lambda expression:
-
-~~~{.cpp}
-// 1: OK.
-auto lambda = []() { ...; };
-~~~
-
- * Format lambdas similar to how we format functions and methods. Feel free to let lambdas be one-liners:
-
-~~~{.cpp}
-// 1: OK.
-auto lambda = []() {
- ...;
-};
-
-// 2: OK.
-auto lambda = []() { ...; };
-~~~
-
- * Feel free to inline lambdas within function arguments:
-
-~~~{.cpp}
-instance.method([]() {
- ...;
-});
-~~~
-
- * Chain function calls on a newline after the closing brace of the lambda and the closing parenthesis of function call:
-
-~~~{.cpp}
-// 1: OK.
-instance
- .method([]() {
- ...;
- })
- .then([]() { ...; })
- .then([]() {
- ...;
- });
-
-// 2: OK (when no chaining, compare to 1).
-instance.method([]() {
- ...;
-});
-
-// 3: OK (if no 'instance.method').
-function([]() {
- ...;
-})
-.then([]() { ...; })
-.then([]() {
- ...;
-});
-
-// 3: OK (but prefer 1).
-instance.method([]() {
- ...;
-})
-.then([]() { ...; })
-.then([]() {
- ...;
-});
-~~~
-
- * Wrap capture lists independently of parameters, *use the same formatting as if the capture list were template parameters*:
-
-~~~{.cpp}
-// 1: OK.
-function([&capture1, &capture2, &capture3](
- const T1& p1, const T2& p2, const T3& p3) {
- ...;
-});
-
-function(
- [&capture1, &capture2, &capture3](
- const T1& p1, const T2& p2, const T3& p3) {
- ...;
-});
-
-auto lambda = [&capture1, &capture2, &capture3](
- const T1& p1, const T2& p2, const T3& p3) {
- ...;
-};
-
-auto lambda =
- [&capture1, &capture2, &capture3](
- const T1& p1, const T2& p2, const T3& p3) {
- ...;
-};
-
-// 2: OK (when capture list is longer than 80 characters).
-function([
- &capture1,
- &capture2,
- &capture3,
- &capture4](
- const T1& p1, const T2& p2) {
- ...;
-});
-
-auto lambda = [
- &capture1,
- &capture2,
- &capture3,
- &capture4](
- const T1& p1, const T2& p2) {
- ...;
-};
-
-// 3: OK (but prefer 2).
-function([
- &capture1,
- &capture2,
- &capture3,
- &capture4](const T1& p1, const T2& t2) {
- ...;
-});
-
-auto lambda = [
- &capture1,
- &capture2,
- &capture3,
- &capture4](const T1& p1, const T2& p2) {
- ...;
-};
-
-// 3: Don't use.
-function([&capture1,
- &capture2,
- &capture3,
- &capture4](const T1& p1, const T2& p2) {
- ...;
-});
-
-auto lambda = [&capture1,
- &capture2,
- &capture3,
- &capture4](const T1& p1, const T2& p2) {
- ...;
- };
-
-// 4: Don't use.
-function([&capture1,
- &capture2,
- &capture3,
- &capture4](
- const T1& p1, const T2& p2, const T3& p3) {
- ...;
-});
-
-auto lambda = [&capture1,
- &capture2,
- &capture3,
- &capture4](
- const T1& p1, const T2& p2, const T3& p3) {
- ...;
-};
-
-// 5: Don't use.
-function([&capture1,
- &capture2,
- &capture3,
- &capture4](
- const T1& p1,
- const T2& p2,
- const T3& p3) {
- ...;
- });
-
-auto lambda = [&capture1,
- &capture2,
- &capture3,
- &capture4](
- const T1& p1,
- const T2& p2,
- const T3& p3) {
- ...;
-};
-
-// 6: OK (parameter list longer than 80 characters).
-function([&capture1, &capture2, &capture3](
- const T1& p1,
- const T2& p2,
- const T3& p3,
- const T4& p4) {
- ...;
-});
-
-auto lambda = [&capture1, &capture2, &capture3](
- const T1& p1,
- const T2& p2,
- const T3& p3,
- const T4& p4) {
- ...;
-};
-
-// 7: OK (capture and parameter lists longer than 80 characters).
-function([
- &capture1,
- &capture2,
- &capture3,
- &capture4](
- const T1& p1,
- const T2& p2,
- const T3& p3,
- const T4& p4) {
- ...;
-});
-
-auto lambda = [
- &capture1,
- &capture2,
- &capture3,
- &capture4](
- const T1& p1,
- const T2& p2,
- const T3& p3,
- const T4& p4) {
- ...;
-};
-~~~
-
-* Unrestricted Union.
-
- Like the pre-existing `union`, we can overlap storage allocation for objects that never exist simultaneously. However, with C++11 we are no longer *restricted to having only non-POD types in unions*. Adding non-POD types to unions complicates things, however, because we need to make sure to properly call constructors and destructors. Therefore, only use unrestricted unions (i.e., unions with non-POD types) when the union has only a single field. What does this buy us? Now we can avoid dynamic memory allocations for "container" like types, e.g., `Option`, `Try`, `Result`, etc. In effect, we treat the union like a dynamic allocation, calling *placement new*, `new (&t) T(...)` anyplace we would have just called `new T(...)` and the destructor `t.~T()` anyplace we would have called `delete t`.
-
-* Constant expressions.
-
- Constant expressions allow the declaration of static non-POD objects while eliminating the unpredictable runtime initialization and destruction issues normally encountered, helping eliminate macros and hard-coded literals without sacrificing performance and type safety. Changes which require converting from `constexpr` to `const` can propagate through the dependency tree requiring that dependent `constexpr` uses also be converted to `const`, hence we avoid using `constexpr` in complex functions.
-
- `constexpr` behaves as a combination of `inline` and `const` and hence must be defined before use in another `constexpr`.
-
- Prefer `constexpr` to `const` for all constant POD declarations, `constexpr` `char` arrays are preferred to `const` `string` literals.
-
-~~~{.cpp}
- // OK
- constexpr char LITERAL[] = "value";
-
- // Not OK - not available at compile time for optimization and
- // definition required in a separate compilation module.
- const char LITERAL[];
-
- // Not OK - uncertain initialization order, cannot be used in other
- // constexpr statements.
- const string LITERAL("value");
-~~~
-
- `constexpr` functions are evaluated at compile time if all their arguments are constant expressions. Otherwise they default to initialization at runtime. However `constexpr` functions are limited in that they cannot perform dynamic casts, memory allocation or calls to non-constexpr functions. Prefer `constexpr` over const inline functions.
-
-~~~{.cpp}
- constexpr size_t MIN = 200;
- constexpr size_t MAX = 1000;
- constexpr size_t SPAN() { return MAX-MIN; }
- int array[SPAN()];
-~~~
-
-Const expression constructors allow object initialization at compile time provided that all the constructor arguments are `constexpr` and the constructor body is empty, i.e. all initialization is performed in the initialization list. Classes which provide `constexpr` constructors should normally also provide `constexpr` copy constructors to allow the class to be used in the return value from a `constexpr` function.
-
-~~~{.cpp}
- class C
- {
- public:
- constexpr C(int _i) : i(_i) {};
- constexpr C(const C& c) : i(c.i) {}
- private:
- const int i;
- };
-~~~
-
- C++11 does not provide `constexpr string` or `constexpr` containers in the STL and hence `constexpr` cannot be used for any class using stout's Error() class.
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/mesos-containerizer.md
----------------------------------------------------------------------
diff --git a/docs/mesos-containerizer.md b/docs/mesos-containerizer.md
deleted file mode 100644
index ea19558..0000000
--- a/docs/mesos-containerizer.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-layout: documentation
----
-
-# Mesos Containerizer
-
-The MesosContainerizer provides lightweight containerization and
-resource isolation of executors using Linux-specific functionality
-such as control cgroups and namespaces. It is composable so operators
-can selectively enable different isolators.
-
-It also provides basic support for POSIX systems (e.g., OSX) but
-without any actual isolation, only resource usage reporting.
-
-### Shared Filesystem
-
-The SharedFilesystem isolator can optionally be used on Linux hosts to
-enable modifications to each container's view of the shared
-filesystem.
-
-The modifications are specified in the ContainerInfo included in the
-ExecutorInfo, either by a framework or by using the
---default\_container\_info slave flag.
-
-ContainerInfo specifies Volumes which map parts of the shared
-filesystem (host\_path) into the container's view of the filesystem
-(container\_path), as read-write or read-only. The host\_path can be
-absolute, in which case it will make the filesystem subtree rooted at
-host\_path also accessible under container\_path for each container.
-If host\_path is relative then it is considered as a directory
-relative to the executor's work directory. The directory will be
-created and permissions copied from the corresponding directory (which
-must exist) in the shared filesystem.
-
-The primary use-case for this isolator is to selectively make parts of
-the shared filesystem private to each container. For example, a
-private "/tmp" directory can be achieved with host\_path="tmp" and
-container\_path="/tmp" which will create a directory "tmp" inside the
-executor's work directory (mode 1777) and simultaneously mount it as
-/tmp inside the container. This is transparent to processes running
-inside the container. Containers will not be able to see the host's
-/tmp or any other container's /tmp.
-
-### Pid Namespace
-
-The Pid Namespace isolator can be used to isolate each container in
-a separate pid namespace with two main benefits:
-1. Visibility: Processes running in the container (executor and
- descendants) are unable to see or signal processes outside the
- namespace.
-2. Clean termination: Termination of the leading process in a pid
- namespace will result in the kernel terminating all other processes
- in the namespace.
-
-The Launcher will use (2) during destruction of a container in
-preference to the freezer cgroup, avoiding known kernel issues related
-to freezing cgroups under OOM conditions.
-
-/proc will be mounted for containers so tools such as 'ps' will work
-correctly.
-
-
-### Posix Disk Isolator
-
-The Posix Disk isolator provides basic disk isolation. It is able to
-report the disk usage for each sandbox and optionally enforce the disk
-quota. It can be used on both Linux and OS X.
-
-To enable the Posix Disk isolator, append `posix/disk` to the
-`--isolation` flag when starting the slave.
-
-By default, the disk quota enforcement is disabled. To enable it,
-specify `--enforce_container_disk_quota` when starting the slave.
-
-The Posix Disk isolator reports disk usage for each sandbox by
-periodically running the `du` command. The disk usage can be retrieved
-from the resource statistics endpoint (`/monitor/statistics.json`).
-
-The interval between two `du`s can be controlled by the slave flag
-`--container_disk_watch_interval`. For example,
-`--container_disk_watch_interval=1mins` sets the interval to be 1
-minute. The default interval is 15 seconds.
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/mesos-documentation-guide.md
----------------------------------------------------------------------
diff --git a/docs/mesos-documentation-guide.md b/docs/mesos-documentation-guide.md
index 42ed95f..2a4151b 100644
--- a/docs/mesos-documentation-guide.md
+++ b/docs/mesos-documentation-guide.md
@@ -9,6 +9,8 @@ We have three different kinds of documentation:
User guides and non-code technical documentation are stored in markdown files in the `docs/` folder. These files get rendered for the [online documentation](http://mesos.apache.org/documentation/latest/).
+ We will accept small documentation changes on [Github via a pull request](https://github.com/apache/mesos), larger documentation changes should go through the (reviewboard)[https://reviews.apache.org/groups/mesos/]
+
2. [Doxygen API Documentation and Developer Guides as part of source code](/documentation/latest/mesos-doxygen-style-guide/)
http://git-wip-us.apache.org/repos/asf/mesos/blob/b29ec4f1/docs/mesos-doxygen-style-guide.md
----------------------------------------------------------------------
diff --git a/docs/mesos-doxygen-style-guide.md b/docs/mesos-doxygen-style-guide.md
deleted file mode 100644
index 1bd3b3d..0000000
--- a/docs/mesos-doxygen-style-guide.md
+++ /dev/null
@@ -1,196 +0,0 @@
-# Apache Mesos Doxygen Style Guide
-
-This guide introduces a consistent style
-for [documenting Mesos source code](http://mesos.apache.org/api/latest/c++)
-using [Doxygen](http://www.doxygen.org).
-There is an ongoing, incremental effort with the goal to document all public Mesos, libprocess, and stout APIs this way.
-For now, existing code may not follow these guidelines, but new code should.
-
-
-## Source Code Documentation Syntax
-
-Doxygen documentation needs only to be applied to source code parts that
-constitute an interface for which we want to generate Mesos API documentation
-files. Implementation code that does not participate in this should still be
-enhanced by source code comments as appropriate, but these comments should not follow the doxygen style.
-
-We follow the [Javadoc syntax](http://en.wikipedia.org/wiki/Javadoc) to mark comment blocks.
-These have the general form:
-
-
-<!-- NOTE: In order to show the comments as part of the code blocks in
-this we must use indentation instead of fenced code blocks (i.e.,
-~~~{.cpp}) because doxygen will remove all of the comments and just
-render the code. -->
-
-
- /**
- * Brief summary.
- *
- * Detailed description. More detail.
- * @see Some reference
- *
- * @param <name> Parameter description.
- * @return Return value description.
- */
-
-Example:
-
- /**
- * Returns a compressed version of a string.
- *
- * Compresses an input string using the foobar algorithm.
- *
- * @param uncompressed The input string.
- * @return A compressed version of the input string.
- */
- std::string compress(const std::string& uncompressed);
-
-
-### Doxygen Tags
-
-This is the allowed set of doxygen tags that can be used.
-
- * [\@param](http://doxygen.org/manual/commands.html#cmdparam) Describes function parameters.
- * [\@return](http://doxygen.org/manual/commands.html#cmdreturn) Describes return values.
- * [\@see](http://doxygen.org/manual/commands.html#cmdsa) Describes a cross-reference to classes, functions, methods, variables, files or URL.
-
-Example:
-
- /**
- * Available kinds of implementations.
- *
- * @see process::network::PollSocketImpl
- */
-
- * [\@file](http://doxygen.org/manual/commands.html#cmdfile) Describes a refence to a file. It is required when documenting global functions, variables, typedefs, or enums in separate files.
- * [\@link](http://doxygen.org/manual/commands.html#cmdlink) and [\@endlink](http://doxygen.org/manual/commands.html#cmdendlink) Describes a link to a file, class, or member.
- * [\@example](http://doxygen.org/manual/commands.html#cmdexample) Describes source code examples.
- * [\@image](http://doxygen.org/manual/commands.html#cmdimage) Describes an image.
-
- * When following these links be aware that the doxygen documentation is using another syntax in that \@param is explained as \\param.
-
-
-### Wrapping
-
-We wrap long descriptions using four spaces on the next line.
-
- @param uncompressed The input string that requires
- a very long description and an even longer
- description on this line as well.
-
-
-### Constants and Variables
-
-Example:
-
- /**
- * Prefix used to name Docker containers in order to distinguish
- * those created by Mesos from those created manually.
- */
- extern const std::string DOCKER_NAME_PREFIX;
-
-
-#### Fields
-
-Example:
-
- /**
- * The parent side of the pipe for stdin.
- * If the mode is not PIPE, None will be stored.
- * **NOTE**: stdin is a macro on some systems, hence this name instead.
- */
- Option<int> in;
-
-
-### Functions and Methods
-
-Example:
-
- /**
- * Forks a subprocess and execs the specified 'path' with the
- * specified 'argv', redirecting stdin, stdout, and stderr as
- * specified by 'in', 'out', and 'err' respectively.
- *
- * If 'setup' is not None, runs the specified function after forking
- * but before exec'ing. If the return value of 'setup' is non-zero
- * then that gets returned in 'status()' and we will not exec.
- *
- * @param path Relative or absolute path in the filesytem to the
- * executable.
- * @param argv Argument vector to pass to exec.
- * @param in Redirection specification for stdin.
- * @param out Redirection specification for stdout.
- * @param err Redirection specification for stderr.
- * @param flags Flags to be stringified and appended to 'argv'.
- * @param environment Environment variables to use for the new
- * subprocess or if None (the default) then the new subprocess
- * will inherit the environment of the current process.
- * @param setup Function to be invoked after forking but before
- * exec'ing. NOTE: Take extra care not to invoke any
- * async unsafe code in the body of this function.
- * @param clone Function to be invoked in order to fork/clone the
- * subprocess.
- * @return The subprocess or an error if one occurred.
- */
- Try<Subprocess> subprocess(
- const std::string& path,
- std::vector<std::string> argv,
- const Subprocess::IO& in = Subprocess::FD(STDIN_FILENO),
- const Subprocess::IO& out = Subprocess::FD(STDOUT_FILENO),
- const Subprocess::IO& err = Subprocess::FD(STDERR_FILENO),
- const Option<flags::FlagsBase>& flags = None(),
- const Option<std::map<std::string, std::string>>& environment = None(),
- const Option<lambda::function<int()>>& setup = None(),
- const Option<lambda::function<
- pid_t(const lambda::function<int()>&)>>& clone = None());
-
-
-### Classes and Structs
-
-Example:
-
- /**
- * Represents a fork() exec()ed subprocess. Access is provided to the
- * input / output of the process, as well as the exit status. The
- * input / output file descriptors are only closed after:
- * 1. The subprocess has terminated.
- * 2. There are no longer any references to the associated
- * Subprocess object.
- */
- class Subprocess
- {
- public:
-
-
-## Library and Component Overview Pages and Developer Guides
-
-Substantial libraries, components, and subcomponents of the Mesos system such as
-stout, libprocess, master, slave, containerizer, allocator, and others
-should have an overview page in markdown format that explains their
-purpose, overall structure, and general use. This can even be a complete developer guide.
-
-This page must be located in the top directory of the library/component and named "README.md".
-
-The first line in such a document must be a section heading bearing the title which will appear in the generated Doxygen index.
-Example: "# Libprocess Developer Guide"
-
-### Example Code
-
-C++ code examples should be enclosed by '~~~{.cpp}'.
-
-Example:
-
-~~~{.cpp}
-int main(int argc, char** argv)
-{
- ...
-}
-~~~
-
-**NOTE**: Because of shortcomings of Doxygen's markdown parser we currently use indentation for wrapping all non C++ code blocks.
-
-
-## Building Doxygen Documentation
-
-As of right now, the Doxygen documentation should be built from the *build* subdirectory using *doxygen ../Doxyfile* . The documentation will then be generated into the *./doxygen* subdirectory.