Modify file structure of docs source files.

Changed the file structure to allow for easier and better maintenance of
the docs. Files were renamed as needed and following a consistent
convention. Added a index.rst to every folder allowing for partial
builds of the docs. Included content previously left out of the docs
build. The commit also performs minimal housekeeping.

Signed-off-by: Rodrigo Caballero <rodrigo.caballero.abraham@intel.com>

source/Makefile

@@ -1,192 +1,192 @@
-# Makefile for Sphinx documentation
-#
-
-# You can set these variables from the command line.
-SPHINXOPTS    =
-SPHINXBUILD   = sphinx-build
-PAPER         =
-BUILDDIR      = _build
-
-# User-friendly check for sphinx-build
-ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
-$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
-endif
-
-# Internal variables.
-PAPEROPT_a4     = -D latex_paper_size=a4
-PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-# the i18n builder cannot share the environment and doctrees with the others
-I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-
-.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest coverage gettext
-
-help:
-	@echo "Please use \`make <target>' where <target> is one of"
-	@echo "  html       to make standalone HTML files"
-	@echo "  dirhtml    to make HTML files named index.html in directories"
-	@echo "  singlehtml to make a single large HTML file"
-	@echo "  pickle     to make pickle files"
-	@echo "  json       to make JSON files"
-	@echo "  htmlhelp   to make HTML files and a HTML help project"
-	@echo "  qthelp     to make HTML files and a qthelp project"
-	@echo "  applehelp  to make an Apple Help Book"
-	@echo "  devhelp    to make HTML files and a Devhelp project"
-	@echo "  epub       to make an epub"
-	@echo "  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
-	@echo "  latexpdf   to make LaTeX files and run them through pdflatex"
-	@echo "  latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
-	@echo "  text       to make text files"
-	@echo "  man        to make manual pages"
-	@echo "  texinfo    to make Texinfo files"
-	@echo "  info       to make Texinfo files and run them through makeinfo"
-	@echo "  gettext    to make PO message catalogs"
-	@echo "  changes    to make an overview of all changed/added/deprecated items"
-	@echo "  xml        to make Docutils-native XML files"
-	@echo "  pseudoxml  to make pseudoxml-XML files for display purposes"
-	@echo "  linkcheck  to check all external links for integrity"
-	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"
-	@echo "  coverage   to run coverage check of the documentation (if enabled)"
-
-clean:
-	rm -rf $(BUILDDIR)/*
-
-html:
-	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
-	@echo
-	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
-
-dirhtml:
-	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
-	@echo
-	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
-
-singlehtml:
-	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
-	@echo
-	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
-
-pickle:
-	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
-	@echo
-	@echo "Build finished; now you can process the pickle files."
-
-json:
-	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
-	@echo
-	@echo "Build finished; now you can process the JSON files."
-
-htmlhelp:
-	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
-	@echo
-	@echo "Build finished; now you can run HTML Help Workshop with the" \
-	      ".hhp project file in $(BUILDDIR)/htmlhelp."
-
-qthelp:
-	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
-	@echo
-	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
-	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
-	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/ClearLinuxDocumentation.qhcp"
-	@echo "To view the help file:"
-	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/ClearLinuxDocumentation.qhc"
-
-applehelp:
-	$(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
-	@echo
-	@echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
-	@echo "N.B. You won't be able to view it unless you put it in" \
-	      "~/Library/Documentation/Help or install it in your application" \
-	      "bundle."
-
-devhelp:
-	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
-	@echo
-	@echo "Build finished."
-	@echo "To view the help file:"
-	@echo "# mkdir -p $$HOME/.local/share/devhelp/ClearLinuxDocumentation"
-	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/ClearLinuxDocumentation"
-	@echo "# devhelp"
-
-epub:
-	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
-	@echo
-	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
-
-latex:
-	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
-	@echo
-	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
-	@echo "Run \`make' in that directory to run these through (pdf)latex" \
-	      "(use \`make latexpdf' here to do that automatically)."
-
-latexpdf:
-	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
-	@echo "Running LaTeX files through pdflatex..."
-	$(MAKE) -C $(BUILDDIR)/latex all-pdf
-	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-latexpdfja:
-	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
-	@echo "Running LaTeX files through platex and dvipdfmx..."
-	$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
-	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-text:
-	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
-	@echo
-	@echo "Build finished. The text files are in $(BUILDDIR)/text."
-
-man:
-	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
-	@echo
-	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
-
-texinfo:
-	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
-	@echo
-	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
-	@echo "Run \`make' in that directory to run these through makeinfo" \
-	      "(use \`make info' here to do that automatically)."
-
-info:
-	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
-	@echo "Running Texinfo files through makeinfo..."
-	make -C $(BUILDDIR)/texinfo info
-	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
-
-gettext:
-	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
-	@echo
-	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
-
-changes:
-	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
-	@echo
-	@echo "The overview file is in $(BUILDDIR)/changes."
-
-linkcheck:
-	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
-	@echo
-	@echo "Link check complete; look for any errors in the above output " \
-	      "or in $(BUILDDIR)/linkcheck/output.txt."
-
-doctest:
-	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
-	@echo "Testing of doctests in the sources finished, look at the " \
-	      "results in $(BUILDDIR)/doctest/output.txt."
-
-coverage:
-	$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
-	@echo "Testing of coverage in the sources finished, look at the " \
-	      "results in $(BUILDDIR)/coverage/python.txt."
-
-xml:
-	$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
-	@echo
-	@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
-
-pseudoxml:
-	$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
-	@echo
-	@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+PAPER         =
+BUILDDIR      = _build
+
+# User-friendly check for sphinx-build
+ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
+$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
+endif
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest coverage gettext
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html       to make standalone HTML files"
+	@echo "  dirhtml    to make HTML files named index.html in directories"
+	@echo "  singlehtml to make a single large HTML file"
+	@echo "  pickle     to make pickle files"
+	@echo "  json       to make JSON files"
+	@echo "  htmlhelp   to make HTML files and a HTML help project"
+	@echo "  qthelp     to make HTML files and a qthelp project"
+	@echo "  applehelp  to make an Apple Help Book"
+	@echo "  devhelp    to make HTML files and a Devhelp project"
+	@echo "  epub       to make an epub"
+	@echo "  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+	@echo "  latexpdf   to make LaTeX files and run them through pdflatex"
+	@echo "  latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
+	@echo "  text       to make text files"
+	@echo "  man        to make manual pages"
+	@echo "  texinfo    to make Texinfo files"
+	@echo "  info       to make Texinfo files and run them through makeinfo"
+	@echo "  gettext    to make PO message catalogs"
+	@echo "  changes    to make an overview of all changed/added/deprecated items"
+	@echo "  xml        to make Docutils-native XML files"
+	@echo "  pseudoxml  to make pseudoxml-XML files for display purposes"
+	@echo "  linkcheck  to check all external links for integrity"
+	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"
+	@echo "  coverage   to run coverage check of the documentation (if enabled)"
+
+clean:
+	rm -rf $(BUILDDIR)/*
+
+html:
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
+
+dirhtml:
+	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
+
+singlehtml:
+	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
+	@echo
+	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
+
+pickle:
+	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
+	@echo
+	@echo "Build finished; now you can process the pickle files."
+
+json:
+	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
+	@echo
+	@echo "Build finished; now you can process the JSON files."
+
+htmlhelp:
+	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
+	@echo
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      ".hhp project file in $(BUILDDIR)/htmlhelp."
+
+qthelp:
+	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
+	@echo
+	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
+	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
+	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/ClearLinuxDocumentation.qhcp"
+	@echo "To view the help file:"
+	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/ClearLinuxDocumentation.qhc"
+
+applehelp:
+	$(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
+	@echo
+	@echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
+	@echo "N.B. You won't be able to view it unless you put it in" \
+	      "~/Library/Documentation/Help or install it in your application" \
+	      "bundle."
+
+devhelp:
+	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
+	@echo
+	@echo "Build finished."
+	@echo "To view the help file:"
+	@echo "# mkdir -p $$HOME/.local/share/devhelp/ClearLinuxDocumentation"
+	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/ClearLinuxDocumentation"
+	@echo "# devhelp"
+
+epub:
+	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
+	@echo
+	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
+
+latex:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo
+	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
+	@echo "Run \`make' in that directory to run these through (pdf)latex" \
+	      "(use \`make latexpdf' here to do that automatically)."
+
+latexpdf:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo "Running LaTeX files through pdflatex..."
+	$(MAKE) -C $(BUILDDIR)/latex all-pdf
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+latexpdfja:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo "Running LaTeX files through platex and dvipdfmx..."
+	$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+text:
+	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
+	@echo
+	@echo "Build finished. The text files are in $(BUILDDIR)/text."
+
+man:
+	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
+	@echo
+	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
+
+texinfo:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo
+	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
+	@echo "Run \`make' in that directory to run these through makeinfo" \
+	      "(use \`make info' here to do that automatically)."
+
+info:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo "Running Texinfo files through makeinfo..."
+	make -C $(BUILDDIR)/texinfo info
+	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
+
+gettext:
+	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
+	@echo
+	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
+
+changes:
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
+	@echo
+	@echo "The overview file is in $(BUILDDIR)/changes."
+
+linkcheck:
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in $(BUILDDIR)/linkcheck/output.txt."
+
+doctest:
+	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
+	@echo "Testing of doctests in the sources finished, look at the " \
+	      "results in $(BUILDDIR)/doctest/output.txt."
+
+coverage:
+	$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
+	@echo "Testing of coverage in the sources finished, look at the " \
+	      "results in $(BUILDDIR)/coverage/python.txt."
+
+xml:
+	$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
+	@echo
+	@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
+
+pseudoxml:
+	$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
+	@echo
+	@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."

source/_static/images/clearcontainersV1.svg

@@ -1,125 +1,125 @@
-<!DOCTYPE html>
-<html lang='en'>
-<head>
-<meta charset='utf-8'>
-<meta content='GitLab Community Edition' name='description'>
-<title>
-
-GitLab
-</title>
-<link href="/assets/favicon-baaa14bade1248aa6165e9d34e7d83c0.ico" rel="shortcut icon" type="image/vnd.microsoft.icon" />
-<link href="/assets/application-b98c4e3de10f80b29e9d63b433eea3ff.css" media="all" rel="stylesheet" />
-<link href="/assets/print-1df3ea9b8ff148a6745321899e0cb213.css" media="print" rel="stylesheet" />
-<script src="/assets/application-c4186ca579dd09b3e48eaf1b5a3e4434.js"></script>
-<meta content="authenticity_token" name="csrf-param" />
-<meta content="Ytxqo6u4bXdch1mBIQXjVpw05a7xest8E7A2ODox8f0=" name="csrf-token" />
-<script type="text/javascript">
-//<![CDATA[
-window.gon={};gon.default_issues_tracker="gitlab";gon.api_version="v3";gon.relative_url_root="";gon.default_avatar_url="http://clrgitlab.intel.com/assets/no_avatar-adffbfe10d45b20495cd2a9b88974150.png";
-//]]>
-</script>
-<meta content='width=device-width, initial-scale=1.0' name='viewport'>
-
-
-</head>
-
-<body class='ui_basic login-page'>
-<div class='container'>
-<div class='content'>
-<div class='login-title'>
-<h1>GitLab Community Edition</h1>
-</div>
-</div>
-</div>
-<hr>
-<div class='container'>
-<div class='content'>
-<div class='flash-container'>
-<div class='flash-alert'>
-You need to sign in before continuing.
-</div>
-</div>
-
-<div class='row'>
-<div class='col-md-7 brand-holder'>
-<div class='brand-image default-brand-image hidden-sm hidden-xs'>
-<img alt="Brand logo" src="/assets/brand_logo-c37eb221b456bb4b472cc1084480991f.png" />
-</div>
-<div class='brand_text hidden-xs'>
-<h2>Open source software to collaborate on code</h2>
-<p class='lead'>
-Manage git repositories with fine grained access controls that keep your code secure.
-Perform code reviews and enhance collaboration with merge requests.
-Each project can also have an issue tracker and a wiki.
-</p>
-</div>
-</div>
-<div class='col-md-5'>
-<div class='login-box'>
-<div class='login-heading'>
-<h3>Sign in</h3>
-</div>
-<div class='login-body'>
-<ul class='nav nav-tabs'>
-<li class='active'>
-<a data-toggle="tab" href="#tab-ldapmain">Intel Corporation</a>
-</li>
-<li>
-<a data-toggle="tab" href="#tab-signin">Standard</a>
-</li>
-</ul>
-<div class='tab-content'>
-<div class='active tab-pane' id='tab-ldapmain'>
-<form accept-charset="UTF-8" action="/users/auth/ldapmain/callback" id="new_ldap_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="Ytxqo6u4bXdch1mBIQXjVpw05a7xest8E7A2ODox8f0=" /></div>
-<input autofocus="autofocus" class="form-control top" id="username" name="username" placeholder="LDAP Login" type="text" />
-<input class="form-control bottom" id="password" name="password" placeholder="Password" type="password" />
-<br>
-<button class="btn-save btn" name="button" type="submit">LDAP Sign in</button>
-</form>
-
-
-</div>
-<div class='tab-pane' id='tab-signin'>
-<form accept-charset="UTF-8" action="/users/sign_in" class="new_user" id="new_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="Ytxqo6u4bXdch1mBIQXjVpw05a7xest8E7A2ODox8f0=" /></div><input autofocus="autofocus" class="form-control top" id="user_login" name="user[login]" placeholder="Username or Email" type="text" />
-<input class="form-control bottom" id="user_password" name="user[password]" placeholder="Password" type="password" />
-<div class='clearfix append-bottom-10'>
-<label class='checkbox remember_me' for='user_remember_me'>
-<input name="user[remember_me]" type="hidden" value="0" /><input id="user_remember_me" name="user[remember_me]" type="checkbox" value="1" />
-<span>Remember me</span>
-<div class='pull-right'>
-<a href="/users/password/new">Forgot your password?</a>
-</div>
-</label>
-</div>
-<div>
-<input class="btn btn-save" name="commit" type="submit" value="Sign in" />
-</div>
-</form>
-
-
-</div>
-</div>
-
-</div>
-<div class='login-footer'>
-<p>
-<span class='light'>Did not receive confirmation email?</span>
-<a href="/users/confirmation/new">Send again</a>
-</p>
-</div>
-</div>
-
-</div>
-</div>
-</div>
-</div>
-<hr>
-<div class='container'>
-<div class='footer-links'>
-<a href="/explore">Explore</a>
-<a href="http://doc.gitlab.com/" rel="nofollow">Documentation</a>
-<a href="https://about.gitlab.com/" rel="nofollow">About GitLab</a>
-</div>
-</div>
-</body>
-</html>
+<!DOCTYPE html>
+<html lang='en'>
+<head>
+<meta charset='utf-8'>
+<meta content='GitLab Community Edition' name='description'>
+<title>
+
+GitLab
+</title>
+<link href="/assets/favicon-baaa14bade1248aa6165e9d34e7d83c0.ico" rel="shortcut icon" type="image/vnd.microsoft.icon" />
+<link href="/assets/application-b98c4e3de10f80b29e9d63b433eea3ff.css" media="all" rel="stylesheet" />
+<link href="/assets/print-1df3ea9b8ff148a6745321899e0cb213.css" media="print" rel="stylesheet" />
+<script src="/assets/application-c4186ca579dd09b3e48eaf1b5a3e4434.js"></script>
+<meta content="authenticity_token" name="csrf-param" />
+<meta content="Ytxqo6u4bXdch1mBIQXjVpw05a7xest8E7A2ODox8f0=" name="csrf-token" />
+<script type="text/javascript">
+//<![CDATA[
+window.gon={};gon.default_issues_tracker="gitlab";gon.api_version="v3";gon.relative_url_root="";gon.default_avatar_url="http://clrgitlab.intel.com/assets/no_avatar-adffbfe10d45b20495cd2a9b88974150.png";
+//]]>
+</script>
+<meta content='width=device-width, initial-scale=1.0' name='viewport'>
+
+
+</head>
+
+<body class='ui_basic login-page'>
+<div class='container'>
+<div class='content'>
+<div class='login-title'>
+<h1>GitLab Community Edition</h1>
+</div>
+</div>
+</div>
+<hr>
+<div class='container'>
+<div class='content'>
+<div class='flash-container'>
+<div class='flash-alert'>
+You need to sign in before continuing.
+</div>
+</div>
+
+<div class='row'>
+<div class='col-md-7 brand-holder'>
+<div class='brand-image default-brand-image hidden-sm hidden-xs'>
+<img alt="Brand logo" src="/assets/brand_logo-c37eb221b456bb4b472cc1084480991f.png" />
+</div>
+<div class='brand_text hidden-xs'>
+<h2>Open source software to collaborate on code</h2>
+<p class='lead'>
+Manage git repositories with fine grained access controls that keep your code secure.
+Perform code reviews and enhance collaboration with merge requests.
+Each project can also have an issue tracker and a wiki.
+</p>
+</div>
+</div>
+<div class='col-md-5'>
+<div class='login-box'>
+<div class='login-heading'>
+<h3>Sign in</h3>
+</div>
+<div class='login-body'>
+<ul class='nav nav-tabs'>
+<li class='active'>
+<a data-toggle="tab" href="#tab-ldapmain">Intel Corporation</a>
+</li>
+<li>
+<a data-toggle="tab" href="#tab-signin">Standard</a>
+</li>
+</ul>
+<div class='tab-content'>
+<div class='active tab-pane' id='tab-ldapmain'>
+<form accept-charset="UTF-8" action="/users/auth/ldapmain/callback" id="new_ldap_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="Ytxqo6u4bXdch1mBIQXjVpw05a7xest8E7A2ODox8f0=" /></div>
+<input autofocus="autofocus" class="form-control top" id="username" name="username" placeholder="LDAP Login" type="text" />
+<input class="form-control bottom" id="password" name="password" placeholder="Password" type="password" />
+<br>
+<button class="btn-save btn" name="button" type="submit">LDAP Sign in</button>
+</form>
+
+
+</div>
+<div class='tab-pane' id='tab-signin'>
+<form accept-charset="UTF-8" action="/users/sign_in" class="new_user" id="new_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="Ytxqo6u4bXdch1mBIQXjVpw05a7xest8E7A2ODox8f0=" /></div><input autofocus="autofocus" class="form-control top" id="user_login" name="user[login]" placeholder="Username or Email" type="text" />
+<input class="form-control bottom" id="user_password" name="user[password]" placeholder="Password" type="password" />
+<div class='clearfix append-bottom-10'>
+<label class='checkbox remember_me' for='user_remember_me'>
+<input name="user[remember_me]" type="hidden" value="0" /><input id="user_remember_me" name="user[remember_me]" type="checkbox" value="1" />
+<span>Remember me</span>
+<div class='pull-right'>
+<a href="/users/password/new">Forgot your password?</a>
+</div>
+</label>
+</div>
+<div>
+<input class="btn btn-save" name="commit" type="submit" value="Sign in" />
+</div>
+</form>
+
+
+</div>
+</div>
+
+</div>
+<div class='login-footer'>
+<p>
+<span class='light'>Did not receive confirmation email?</span>
+<a href="/users/confirmation/new">Send again</a>
+</p>
+</div>
+</div>
+
+</div>
+</div>
+</div>
+</div>
+<hr>
+<div class='container'>
+<div class='footer-links'>
+<a href="/explore">Explore</a>
+<a href="http://doc.gitlab.com/" rel="nofollow">Documentation</a>
+<a href="https://about.gitlab.com/" rel="nofollow">About GitLab</a>
+</div>
+</div>
+</body>
+</html>

source/_static/images/clearcontainersV2.svg

@@ -1,125 +1,125 @@
-<!DOCTYPE html>
-<html lang='en'>
-<head>
-<meta charset='utf-8'>
-<meta content='GitLab Community Edition' name='description'>
-<title>
-
-GitLab
-</title>
-<link href="/assets/favicon-baaa14bade1248aa6165e9d34e7d83c0.ico" rel="shortcut icon" type="image/vnd.microsoft.icon" />
-<link href="/assets/application-b98c4e3de10f80b29e9d63b433eea3ff.css" media="all" rel="stylesheet" />
-<link href="/assets/print-1df3ea9b8ff148a6745321899e0cb213.css" media="print" rel="stylesheet" />
-<script src="/assets/application-c4186ca579dd09b3e48eaf1b5a3e4434.js"></script>
-<meta content="authenticity_token" name="csrf-param" />
-<meta content="rZLe6DTuc4TRf8DnGIbU26p59xH3Eq8aWYC4NvVc1pM=" name="csrf-token" />
-<script type="text/javascript">
-//<![CDATA[
-window.gon={};gon.default_issues_tracker="gitlab";gon.api_version="v3";gon.relative_url_root="";gon.default_avatar_url="http://clrgitlab.intel.com/assets/no_avatar-adffbfe10d45b20495cd2a9b88974150.png";
-//]]>
-</script>
-<meta content='width=device-width, initial-scale=1.0' name='viewport'>
-
-
-</head>
-
-<body class='ui_basic login-page'>
-<div class='container'>
-<div class='content'>
-<div class='login-title'>
-<h1>GitLab Community Edition</h1>
-</div>
-</div>
-</div>
-<hr>
-<div class='container'>
-<div class='content'>
-<div class='flash-container'>
-<div class='flash-alert'>
-You need to sign in before continuing.
-</div>
-</div>
-
-<div class='row'>
-<div class='col-md-7 brand-holder'>
-<div class='brand-image default-brand-image hidden-sm hidden-xs'>
-<img alt="Brand logo" src="/assets/brand_logo-c37eb221b456bb4b472cc1084480991f.png" />
-</div>
-<div class='brand_text hidden-xs'>
-<h2>Open source software to collaborate on code</h2>
-<p class='lead'>
-Manage git repositories with fine grained access controls that keep your code secure.
-Perform code reviews and enhance collaboration with merge requests.
-Each project can also have an issue tracker and a wiki.
-</p>
-</div>
-</div>
-<div class='col-md-5'>
-<div class='login-box'>
-<div class='login-heading'>
-<h3>Sign in</h3>
-</div>
-<div class='login-body'>
-<ul class='nav nav-tabs'>
-<li class='active'>
-<a data-toggle="tab" href="#tab-ldapmain">Intel Corporation</a>
-</li>
-<li>
-<a data-toggle="tab" href="#tab-signin">Standard</a>
-</li>
-</ul>
-<div class='tab-content'>
-<div class='active tab-pane' id='tab-ldapmain'>
-<form accept-charset="UTF-8" action="/users/auth/ldapmain/callback" id="new_ldap_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="rZLe6DTuc4TRf8DnGIbU26p59xH3Eq8aWYC4NvVc1pM=" /></div>
-<input autofocus="autofocus" class="form-control top" id="username" name="username" placeholder="LDAP Login" type="text" />
-<input class="form-control bottom" id="password" name="password" placeholder="Password" type="password" />
-<br>
-<button class="btn-save btn" name="button" type="submit">LDAP Sign in</button>
-</form>
-
-
-</div>
-<div class='tab-pane' id='tab-signin'>
-<form accept-charset="UTF-8" action="/users/sign_in" class="new_user" id="new_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="rZLe6DTuc4TRf8DnGIbU26p59xH3Eq8aWYC4NvVc1pM=" /></div><input autofocus="autofocus" class="form-control top" id="user_login" name="user[login]" placeholder="Username or Email" type="text" />
-<input class="form-control bottom" id="user_password" name="user[password]" placeholder="Password" type="password" />
-<div class='clearfix append-bottom-10'>
-<label class='checkbox remember_me' for='user_remember_me'>
-<input name="user[remember_me]" type="hidden" value="0" /><input id="user_remember_me" name="user[remember_me]" type="checkbox" value="1" />
-<span>Remember me</span>
-<div class='pull-right'>
-<a href="/users/password/new">Forgot your password?</a>
-</div>
-</label>
-</div>
-<div>
-<input class="btn btn-save" name="commit" type="submit" value="Sign in" />
-</div>
-</form>
-
-
-</div>
-</div>
-
-</div>
-<div class='login-footer'>
-<p>
-<span class='light'>Did not receive confirmation email?</span>
-<a href="/users/confirmation/new">Send again</a>
-</p>
-</div>
-</div>
-
-</div>
-</div>
-</div>
-</div>
-<hr>
-<div class='container'>
-<div class='footer-links'>
-<a href="/explore">Explore</a>
-<a href="http://doc.gitlab.com/" rel="nofollow">Documentation</a>
-<a href="https://about.gitlab.com/" rel="nofollow">About GitLab</a>
-</div>
-</div>
-</body>
-</html>
+<!DOCTYPE html>
+<html lang='en'>
+<head>
+<meta charset='utf-8'>
+<meta content='GitLab Community Edition' name='description'>
+<title>
+
+GitLab
+</title>
+<link href="/assets/favicon-baaa14bade1248aa6165e9d34e7d83c0.ico" rel="shortcut icon" type="image/vnd.microsoft.icon" />
+<link href="/assets/application-b98c4e3de10f80b29e9d63b433eea3ff.css" media="all" rel="stylesheet" />
+<link href="/assets/print-1df3ea9b8ff148a6745321899e0cb213.css" media="print" rel="stylesheet" />
+<script src="/assets/application-c4186ca579dd09b3e48eaf1b5a3e4434.js"></script>
+<meta content="authenticity_token" name="csrf-param" />
+<meta content="rZLe6DTuc4TRf8DnGIbU26p59xH3Eq8aWYC4NvVc1pM=" name="csrf-token" />
+<script type="text/javascript">
+//<![CDATA[
+window.gon={};gon.default_issues_tracker="gitlab";gon.api_version="v3";gon.relative_url_root="";gon.default_avatar_url="http://clrgitlab.intel.com/assets/no_avatar-adffbfe10d45b20495cd2a9b88974150.png";
+//]]>
+</script>
+<meta content='width=device-width, initial-scale=1.0' name='viewport'>
+
+
+</head>
+
+<body class='ui_basic login-page'>
+<div class='container'>
+<div class='content'>
+<div class='login-title'>
+<h1>GitLab Community Edition</h1>
+</div>
+</div>
+</div>
+<hr>
+<div class='container'>
+<div class='content'>
+<div class='flash-container'>
+<div class='flash-alert'>
+You need to sign in before continuing.
+</div>
+</div>
+
+<div class='row'>
+<div class='col-md-7 brand-holder'>
+<div class='brand-image default-brand-image hidden-sm hidden-xs'>
+<img alt="Brand logo" src="/assets/brand_logo-c37eb221b456bb4b472cc1084480991f.png" />
+</div>
+<div class='brand_text hidden-xs'>
+<h2>Open source software to collaborate on code</h2>
+<p class='lead'>
+Manage git repositories with fine grained access controls that keep your code secure.
+Perform code reviews and enhance collaboration with merge requests.
+Each project can also have an issue tracker and a wiki.
+</p>
+</div>
+</div>
+<div class='col-md-5'>
+<div class='login-box'>
+<div class='login-heading'>
+<h3>Sign in</h3>
+</div>
+<div class='login-body'>
+<ul class='nav nav-tabs'>
+<li class='active'>
+<a data-toggle="tab" href="#tab-ldapmain">Intel Corporation</a>
+</li>
+<li>
+<a data-toggle="tab" href="#tab-signin">Standard</a>
+</li>
+</ul>
+<div class='tab-content'>
+<div class='active tab-pane' id='tab-ldapmain'>
+<form accept-charset="UTF-8" action="/users/auth/ldapmain/callback" id="new_ldap_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="rZLe6DTuc4TRf8DnGIbU26p59xH3Eq8aWYC4NvVc1pM=" /></div>
+<input autofocus="autofocus" class="form-control top" id="username" name="username" placeholder="LDAP Login" type="text" />
+<input class="form-control bottom" id="password" name="password" placeholder="Password" type="password" />
+<br>
+<button class="btn-save btn" name="button" type="submit">LDAP Sign in</button>
+</form>
+
+
+</div>
+<div class='tab-pane' id='tab-signin'>
+<form accept-charset="UTF-8" action="/users/sign_in" class="new_user" id="new_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="rZLe6DTuc4TRf8DnGIbU26p59xH3Eq8aWYC4NvVc1pM=" /></div><input autofocus="autofocus" class="form-control top" id="user_login" name="user[login]" placeholder="Username or Email" type="text" />
+<input class="form-control bottom" id="user_password" name="user[password]" placeholder="Password" type="password" />
+<div class='clearfix append-bottom-10'>
+<label class='checkbox remember_me' for='user_remember_me'>
+<input name="user[remember_me]" type="hidden" value="0" /><input id="user_remember_me" name="user[remember_me]" type="checkbox" value="1" />
+<span>Remember me</span>
+<div class='pull-right'>
+<a href="/users/password/new">Forgot your password?</a>
+</div>
+</label>
+</div>
+<div>
+<input class="btn btn-save" name="commit" type="submit" value="Sign in" />
+</div>
+</form>
+
+
+</div>
+</div>
+
+</div>
+<div class='login-footer'>
+<p>
+<span class='light'>Did not receive confirmation email?</span>
+<a href="/users/confirmation/new">Send again</a>
+</p>
+</div>
+</div>
+
+</div>
+</div>
+</div>
+</div>
+<hr>
+<div class='container'>
+<div class='footer-links'>
+<a href="/explore">Explore</a>
+<a href="http://doc.gitlab.com/" rel="nofollow">Documentation</a>
+<a href="https://about.gitlab.com/" rel="nofollow">About GitLab</a>
+</div>
+</div>
+</body>
+</html>

source/_static/images/dax-V1.svg

@@ -1,125 +1,125 @@
-<!DOCTYPE html>
-<html lang='en'>
-<head>
-<meta charset='utf-8'>
-<meta content='GitLab Community Edition' name='description'>
-<title>
-
-GitLab
-</title>
-<link href="/assets/favicon-baaa14bade1248aa6165e9d34e7d83c0.ico" rel="shortcut icon" type="image/vnd.microsoft.icon" />
-<link href="/assets/application-b98c4e3de10f80b29e9d63b433eea3ff.css" media="all" rel="stylesheet" />
-<link href="/assets/print-1df3ea9b8ff148a6745321899e0cb213.css" media="print" rel="stylesheet" />
-<script src="/assets/application-c4186ca579dd09b3e48eaf1b5a3e4434.js"></script>
-<meta content="authenticity_token" name="csrf-param" />
-<meta content="orwKZnvQVEFT09F4bNkHKLCcIQkcaL7tZw1Dj55jqVY=" name="csrf-token" />
-<script type="text/javascript">
-//<![CDATA[
-window.gon={};gon.default_issues_tracker="gitlab";gon.api_version="v3";gon.relative_url_root="";gon.default_avatar_url="http://clrgitlab.intel.com/assets/no_avatar-adffbfe10d45b20495cd2a9b88974150.png";
-//]]>
-</script>
-<meta content='width=device-width, initial-scale=1.0' name='viewport'>
-
-
-</head>
-
-<body class='ui_basic login-page'>
-<div class='container'>
-<div class='content'>
-<div class='login-title'>
-<h1>GitLab Community Edition</h1>
-</div>
-</div>
-</div>
-<hr>
-<div class='container'>
-<div class='content'>
-<div class='flash-container'>
-<div class='flash-alert'>
-You need to sign in before continuing.
-</div>
-</div>
-
-<div class='row'>
-<div class='col-md-7 brand-holder'>
-<div class='brand-image default-brand-image hidden-sm hidden-xs'>
-<img alt="Brand logo" src="/assets/brand_logo-c37eb221b456bb4b472cc1084480991f.png" />
-</div>
-<div class='brand_text hidden-xs'>
-<h2>Open source software to collaborate on code</h2>
-<p class='lead'>
-Manage git repositories with fine grained access controls that keep your code secure.
-Perform code reviews and enhance collaboration with merge requests.
-Each project can also have an issue tracker and a wiki.
-</p>
-</div>
-</div>
-<div class='col-md-5'>
-<div class='login-box'>
-<div class='login-heading'>
-<h3>Sign in</h3>
-</div>
-<div class='login-body'>
-<ul class='nav nav-tabs'>
-<li class='active'>
-<a data-toggle="tab" href="#tab-ldapmain">Intel Corporation</a>
-</li>
-<li>
-<a data-toggle="tab" href="#tab-signin">Standard</a>
-</li>
-</ul>
-<div class='tab-content'>
-<div class='active tab-pane' id='tab-ldapmain'>
-<form accept-charset="UTF-8" action="/users/auth/ldapmain/callback" id="new_ldap_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="orwKZnvQVEFT09F4bNkHKLCcIQkcaL7tZw1Dj55jqVY=" /></div>
-<input autofocus="autofocus" class="form-control top" id="username" name="username" placeholder="LDAP Login" type="text" />
-<input class="form-control bottom" id="password" name="password" placeholder="Password" type="password" />
-<br>
-<button class="btn-save btn" name="button" type="submit">LDAP Sign in</button>
-</form>
-
-
-</div>
-<div class='tab-pane' id='tab-signin'>
-<form accept-charset="UTF-8" action="/users/sign_in" class="new_user" id="new_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="orwKZnvQVEFT09F4bNkHKLCcIQkcaL7tZw1Dj55jqVY=" /></div><input autofocus="autofocus" class="form-control top" id="user_login" name="user[login]" placeholder="Username or Email" type="text" />
-<input class="form-control bottom" id="user_password" name="user[password]" placeholder="Password" type="password" />
-<div class='clearfix append-bottom-10'>
-<label class='checkbox remember_me' for='user_remember_me'>
-<input name="user[remember_me]" type="hidden" value="0" /><input id="user_remember_me" name="user[remember_me]" type="checkbox" value="1" />
-<span>Remember me</span>
-<div class='pull-right'>
-<a href="/users/password/new">Forgot your password?</a>
-</div>
-</label>
-</div>
-<div>
-<input class="btn btn-save" name="commit" type="submit" value="Sign in" />
-</div>
-</form>
-
-
-</div>
-</div>
-
-</div>
-<div class='login-footer'>
-<p>
-<span class='light'>Did not receive confirmation email?</span>
-<a href="/users/confirmation/new">Send again</a>
-</p>
-</div>
-</div>
-
-</div>
-</div>
-</div>
-</div>
-<hr>
-<div class='container'>
-<div class='footer-links'>
-<a href="/explore">Explore</a>
-<a href="http://doc.gitlab.com/" rel="nofollow">Documentation</a>
-<a href="https://about.gitlab.com/" rel="nofollow">About GitLab</a>
-</div>
-</div>
-</body>
-</html>
+<!DOCTYPE html>
+<html lang='en'>
+<head>
+<meta charset='utf-8'>
+<meta content='GitLab Community Edition' name='description'>
+<title>
+
+GitLab
+</title>
+<link href="/assets/favicon-baaa14bade1248aa6165e9d34e7d83c0.ico" rel="shortcut icon" type="image/vnd.microsoft.icon" />
+<link href="/assets/application-b98c4e3de10f80b29e9d63b433eea3ff.css" media="all" rel="stylesheet" />
+<link href="/assets/print-1df3ea9b8ff148a6745321899e0cb213.css" media="print" rel="stylesheet" />
+<script src="/assets/application-c4186ca579dd09b3e48eaf1b5a3e4434.js"></script>
+<meta content="authenticity_token" name="csrf-param" />
+<meta content="orwKZnvQVEFT09F4bNkHKLCcIQkcaL7tZw1Dj55jqVY=" name="csrf-token" />
+<script type="text/javascript">
+//<![CDATA[
+window.gon={};gon.default_issues_tracker="gitlab";gon.api_version="v3";gon.relative_url_root="";gon.default_avatar_url="http://clrgitlab.intel.com/assets/no_avatar-adffbfe10d45b20495cd2a9b88974150.png";
+//]]>
+</script>
+<meta content='width=device-width, initial-scale=1.0' name='viewport'>
+
+
+</head>
+
+<body class='ui_basic login-page'>
+<div class='container'>
+<div class='content'>
+<div class='login-title'>
+<h1>GitLab Community Edition</h1>
+</div>
+</div>
+</div>
+<hr>
+<div class='container'>
+<div class='content'>
+<div class='flash-container'>
+<div class='flash-alert'>
+You need to sign in before continuing.
+</div>
+</div>
+
+<div class='row'>
+<div class='col-md-7 brand-holder'>
+<div class='brand-image default-brand-image hidden-sm hidden-xs'>
+<img alt="Brand logo" src="/assets/brand_logo-c37eb221b456bb4b472cc1084480991f.png" />
+</div>
+<div class='brand_text hidden-xs'>
+<h2>Open source software to collaborate on code</h2>
+<p class='lead'>
+Manage git repositories with fine grained access controls that keep your code secure.
+Perform code reviews and enhance collaboration with merge requests.
+Each project can also have an issue tracker and a wiki.
+</p>
+</div>
+</div>
+<div class='col-md-5'>
+<div class='login-box'>
+<div class='login-heading'>
+<h3>Sign in</h3>
+</div>
+<div class='login-body'>
+<ul class='nav nav-tabs'>
+<li class='active'>
+<a data-toggle="tab" href="#tab-ldapmain">Intel Corporation</a>
+</li>
+<li>
+<a data-toggle="tab" href="#tab-signin">Standard</a>
+</li>
+</ul>
+<div class='tab-content'>
+<div class='active tab-pane' id='tab-ldapmain'>
+<form accept-charset="UTF-8" action="/users/auth/ldapmain/callback" id="new_ldap_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="orwKZnvQVEFT09F4bNkHKLCcIQkcaL7tZw1Dj55jqVY=" /></div>
+<input autofocus="autofocus" class="form-control top" id="username" name="username" placeholder="LDAP Login" type="text" />
+<input class="form-control bottom" id="password" name="password" placeholder="Password" type="password" />
+<br>
+<button class="btn-save btn" name="button" type="submit">LDAP Sign in</button>
+</form>
+
+
+</div>
+<div class='tab-pane' id='tab-signin'>
+<form accept-charset="UTF-8" action="/users/sign_in" class="new_user" id="new_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="orwKZnvQVEFT09F4bNkHKLCcIQkcaL7tZw1Dj55jqVY=" /></div><input autofocus="autofocus" class="form-control top" id="user_login" name="user[login]" placeholder="Username or Email" type="text" />
+<input class="form-control bottom" id="user_password" name="user[password]" placeholder="Password" type="password" />
+<div class='clearfix append-bottom-10'>
+<label class='checkbox remember_me' for='user_remember_me'>
+<input name="user[remember_me]" type="hidden" value="0" /><input id="user_remember_me" name="user[remember_me]" type="checkbox" value="1" />
+<span>Remember me</span>
+<div class='pull-right'>
+<a href="/users/password/new">Forgot your password?</a>
+</div>
+</label>
+</div>
+<div>
+<input class="btn btn-save" name="commit" type="submit" value="Sign in" />
+</div>
+</form>
+
+
+</div>
+</div>
+
+</div>
+<div class='login-footer'>
+<p>
+<span class='light'>Did not receive confirmation email?</span>
+<a href="/users/confirmation/new">Send again</a>
+</p>
+</div>
+</div>
+
+</div>
+</div>
+</div>
+</div>
+<hr>
+<div class='container'>
+<div class='footer-links'>
+<a href="/explore">Explore</a>
+<a href="http://doc.gitlab.com/" rel="nofollow">Documentation</a>
+<a href="https://about.gitlab.com/" rel="nofollow">About GitLab</a>
+</div>
+</div>
+</body>
+</html>

source/_static/images/dax-V2.svg

@@ -1,125 +1,125 @@
-<!DOCTYPE html>
-<html lang='en'>
-<head>
-<meta charset='utf-8'>
-<meta content='GitLab Community Edition' name='description'>
-<title>
-
-GitLab
-</title>
-<link href="/assets/favicon-baaa14bade1248aa6165e9d34e7d83c0.ico" rel="shortcut icon" type="image/vnd.microsoft.icon" />
-<link href="/assets/application-b98c4e3de10f80b29e9d63b433eea3ff.css" media="all" rel="stylesheet" />
-<link href="/assets/print-1df3ea9b8ff148a6745321899e0cb213.css" media="print" rel="stylesheet" />
-<script src="/assets/application-c4186ca579dd09b3e48eaf1b5a3e4434.js"></script>
-<meta content="authenticity_token" name="csrf-param" />
-<meta content="BYgN41Swlhaocx5zAtsekHQP9MSc9qwtQDgk2kQ1n+w=" name="csrf-token" />
-<script type="text/javascript">
-//<![CDATA[
-window.gon={};gon.default_issues_tracker="gitlab";gon.api_version="v3";gon.relative_url_root="";gon.default_avatar_url="http://clrgitlab.intel.com/assets/no_avatar-adffbfe10d45b20495cd2a9b88974150.png";
-//]]>
-</script>
-<meta content='width=device-width, initial-scale=1.0' name='viewport'>
-
-
-</head>
-
-<body class='ui_basic login-page'>
-<div class='container'>
-<div class='content'>
-<div class='login-title'>
-<h1>GitLab Community Edition</h1>
-</div>
-</div>
-</div>
-<hr>
-<div class='container'>
-<div class='content'>
-<div class='flash-container'>
-<div class='flash-alert'>
-You need to sign in before continuing.
-</div>
-</div>
-
-<div class='row'>
-<div class='col-md-7 brand-holder'>
-<div class='brand-image default-brand-image hidden-sm hidden-xs'>
-<img alt="Brand logo" src="/assets/brand_logo-c37eb221b456bb4b472cc1084480991f.png" />
-</div>
-<div class='brand_text hidden-xs'>
-<h2>Open source software to collaborate on code</h2>
-<p class='lead'>
-Manage git repositories with fine grained access controls that keep your code secure.
-Perform code reviews and enhance collaboration with merge requests.
-Each project can also have an issue tracker and a wiki.
-</p>
-</div>
-</div>
-<div class='col-md-5'>
-<div class='login-box'>
-<div class='login-heading'>
-<h3>Sign in</h3>
-</div>
-<div class='login-body'>
-<ul class='nav nav-tabs'>
-<li class='active'>
-<a data-toggle="tab" href="#tab-ldapmain">Intel Corporation</a>
-</li>
-<li>
-<a data-toggle="tab" href="#tab-signin">Standard</a>
-</li>
-</ul>
-<div class='tab-content'>
-<div class='active tab-pane' id='tab-ldapmain'>
-<form accept-charset="UTF-8" action="/users/auth/ldapmain/callback" id="new_ldap_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="BYgN41Swlhaocx5zAtsekHQP9MSc9qwtQDgk2kQ1n+w=" /></div>
-<input autofocus="autofocus" class="form-control top" id="username" name="username" placeholder="LDAP Login" type="text" />
-<input class="form-control bottom" id="password" name="password" placeholder="Password" type="password" />
-<br>
-<button class="btn-save btn" name="button" type="submit">LDAP Sign in</button>
-</form>
-
-
-</div>
-<div class='tab-pane' id='tab-signin'>
-<form accept-charset="UTF-8" action="/users/sign_in" class="new_user" id="new_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="BYgN41Swlhaocx5zAtsekHQP9MSc9qwtQDgk2kQ1n+w=" /></div><input autofocus="autofocus" class="form-control top" id="user_login" name="user[login]" placeholder="Username or Email" type="text" />
-<input class="form-control bottom" id="user_password" name="user[password]" placeholder="Password" type="password" />
-<div class='clearfix append-bottom-10'>
-<label class='checkbox remember_me' for='user_remember_me'>
-<input name="user[remember_me]" type="hidden" value="0" /><input id="user_remember_me" name="user[remember_me]" type="checkbox" value="1" />
-<span>Remember me</span>
-<div class='pull-right'>
-<a href="/users/password/new">Forgot your password?</a>
-</div>
-</label>
-</div>
-<div>
-<input class="btn btn-save" name="commit" type="submit" value="Sign in" />
-</div>
-</form>
-
-
-</div>
-</div>
-
-</div>
-<div class='login-footer'>
-<p>
-<span class='light'>Did not receive confirmation email?</span>
-<a href="/users/confirmation/new">Send again</a>
-</p>
-</div>
-</div>
-
-</div>
-</div>
-</div>
-</div>
-<hr>
-<div class='container'>
-<div class='footer-links'>
-<a href="/explore">Explore</a>
-<a href="http://doc.gitlab.com/" rel="nofollow">Documentation</a>
-<a href="https://about.gitlab.com/" rel="nofollow">About GitLab</a>
-</div>
-</div>
-</body>
-</html>
+<!DOCTYPE html>
+<html lang='en'>
+<head>
+<meta charset='utf-8'>
+<meta content='GitLab Community Edition' name='description'>
+<title>
+
+GitLab
+</title>
+<link href="/assets/favicon-baaa14bade1248aa6165e9d34e7d83c0.ico" rel="shortcut icon" type="image/vnd.microsoft.icon" />
+<link href="/assets/application-b98c4e3de10f80b29e9d63b433eea3ff.css" media="all" rel="stylesheet" />
+<link href="/assets/print-1df3ea9b8ff148a6745321899e0cb213.css" media="print" rel="stylesheet" />
+<script src="/assets/application-c4186ca579dd09b3e48eaf1b5a3e4434.js"></script>
+<meta content="authenticity_token" name="csrf-param" />
+<meta content="BYgN41Swlhaocx5zAtsekHQP9MSc9qwtQDgk2kQ1n+w=" name="csrf-token" />
+<script type="text/javascript">
+//<![CDATA[
+window.gon={};gon.default_issues_tracker="gitlab";gon.api_version="v3";gon.relative_url_root="";gon.default_avatar_url="http://clrgitlab.intel.com/assets/no_avatar-adffbfe10d45b20495cd2a9b88974150.png";
+//]]>
+</script>
+<meta content='width=device-width, initial-scale=1.0' name='viewport'>
+
+
+</head>
+
+<body class='ui_basic login-page'>
+<div class='container'>
+<div class='content'>
+<div class='login-title'>
+<h1>GitLab Community Edition</h1>
+</div>
+</div>
+</div>
+<hr>
+<div class='container'>
+<div class='content'>
+<div class='flash-container'>
+<div class='flash-alert'>
+You need to sign in before continuing.
+</div>
+</div>
+
+<div class='row'>
+<div class='col-md-7 brand-holder'>
+<div class='brand-image default-brand-image hidden-sm hidden-xs'>
+<img alt="Brand logo" src="/assets/brand_logo-c37eb221b456bb4b472cc1084480991f.png" />
+</div>
+<div class='brand_text hidden-xs'>
+<h2>Open source software to collaborate on code</h2>
+<p class='lead'>
+Manage git repositories with fine grained access controls that keep your code secure.
+Perform code reviews and enhance collaboration with merge requests.
+Each project can also have an issue tracker and a wiki.
+</p>
+</div>
+</div>
+<div class='col-md-5'>
+<div class='login-box'>
+<div class='login-heading'>
+<h3>Sign in</h3>
+</div>
+<div class='login-body'>
+<ul class='nav nav-tabs'>
+<li class='active'>
+<a data-toggle="tab" href="#tab-ldapmain">Intel Corporation</a>
+</li>
+<li>
+<a data-toggle="tab" href="#tab-signin">Standard</a>
+</li>
+</ul>
+<div class='tab-content'>
+<div class='active tab-pane' id='tab-ldapmain'>
+<form accept-charset="UTF-8" action="/users/auth/ldapmain/callback" id="new_ldap_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="BYgN41Swlhaocx5zAtsekHQP9MSc9qwtQDgk2kQ1n+w=" /></div>
+<input autofocus="autofocus" class="form-control top" id="username" name="username" placeholder="LDAP Login" type="text" />
+<input class="form-control bottom" id="password" name="password" placeholder="Password" type="password" />
+<br>
+<button class="btn-save btn" name="button" type="submit">LDAP Sign in</button>
+</form>
+
+
+</div>
+<div class='tab-pane' id='tab-signin'>
+<form accept-charset="UTF-8" action="/users/sign_in" class="new_user" id="new_user" method="post"><div style="display:none"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value="BYgN41Swlhaocx5zAtsekHQP9MSc9qwtQDgk2kQ1n+w=" /></div><input autofocus="autofocus" class="form-control top" id="user_login" name="user[login]" placeholder="Username or Email" type="text" />
+<input class="form-control bottom" id="user_password" name="user[password]" placeholder="Password" type="password" />
+<div class='clearfix append-bottom-10'>
+<label class='checkbox remember_me' for='user_remember_me'>
+<input name="user[remember_me]" type="hidden" value="0" /><input id="user_remember_me" name="user[remember_me]" type="checkbox" value="1" />
+<span>Remember me</span>
+<div class='pull-right'>
+<a href="/users/password/new">Forgot your password?</a>
+</div>
+</label>
+</div>
+<div>
+<input class="btn btn-save" name="commit" type="submit" value="Sign in" />
+</div>
+</form>
+
+
+</div>
+</div>
+
+</div>
+<div class='login-footer'>
+<p>
+<span class='light'>Did not receive confirmation email?</span>
+<a href="/users/confirmation/new">Send again</a>
+</p>
+</div>
+</div>
+
+</div>
+</div>
+</div>
+</div>
+<hr>
+<div class='container'>
+<div class='footer-links'>
+<a href="/explore">Explore</a>
+<a href="http://doc.gitlab.com/" rel="nofollow">Documentation</a>
+<a href="https://about.gitlab.com/" rel="nofollow">About GitLab</a>
+</div>
+</div>
+</body>
+</html>

source/_themes/clearlinux/__init__.py

@@ -1,20 +1,20 @@
-import os
-
-from alabaster import _version as version
-
-
-def get_path():
-    """
-    Shortcut for users whose theme is next to their conf.py.
-    """
-    # Theme directory is defined as our parent directory
-    return os.path.abspath(os.path.dirname(os.path.dirname(__file__)))
-
-
-def update_context(app, pagename, templatename, context, doctree):
-    context['alabaster_version'] = version.__version__
-
-def setup(app):
-    app.connect('html-page-context', update_context)
-    return {'version': version.__version__,
-            'parallel_read_safe': True}
+import os
+
+from alabaster import _version as version
+
+
+def get_path():
+    """
+    Shortcut for users whose theme is next to their conf.py.
+    """
+    # Theme directory is defined as our parent directory
+    return os.path.abspath(os.path.dirname(os.path.dirname(__file__)))
+
+
+def update_context(app, pagename, templatename, context, doctree):
+    context['alabaster_version'] = version.__version__
+
+def setup(app):
+    app.connect('html-page-context', update_context)
+    return {'version': version.__version__,
+            'parallel_read_safe': True}

source/_themes/clearlinux/_version.py

@@ -1,2 +1,2 @@
-__version_info__ = (0, 7, 6)
-__version__ = '.'.join(map(str, __version_info__))
+__version_info__ = (0, 7, 6)
+__version__ = '.'.join(map(str, __version_info__))

source/_themes/clearlinux/about.html

@@ -1,39 +1,39 @@
-{% if theme_logo %}
-<p class="logo">
-  <a href="{{ pathto(master_doc) }}">
-    <img class="logo" src="{{ pathto('_static/' ~ theme_logo, 1) }}" alt="Logo"/>
-    {% if theme_logo_name|lower == 'true' %}
-    <h1 class="logo logo-name">{{ project }}</h2>
-    {% endif %}
-  </a>
-</p>
-{% else %}
-<h1 class="logo"><a href="{{ pathto(master_doc) }}">{{ project }}</a></h1>
-{% endif %}
-
-{% if theme_description %}
-<p class="blurb">{{ theme_description }}</p>
-{% endif %}
-
-{% if theme_github_button|lower == 'true' %}
-<p>
-<iframe src="https://ghbtns.com/github-btn.html?user={{ theme_github_user }}&repo={{ theme_github_repo }}&type={{ theme_github_type }}&count={{ theme_github_count }}&size=large"
-  allowtransparency="true" frameborder="0" scrolling="0" width="200px" height="35px"></iframe>
-</p>
-{% endif %}
-
-{% if theme_travis_button|lower != 'false' %}
-{% if theme_travis_button|lower == 'true' %}
-    {% set path = theme_github_user + '/' + theme_github_repo %}
-{% else %}
-    {% set path = theme_travis_button %}
-{% endif %}
-<p>
-<a href="https://travis-ci.org/{{ path }}">
-    <img
-        alt="https://secure.travis-ci.org/{{ path }}.png?branch=master"
-        src="https://secure.travis-ci.org/{{ path }}.png?branch=master"
-    >
-</a>
-</p>
-{% endif %}
+{% if theme_logo %}
+<p class="logo">
+  <a href="{{ pathto(master_doc) }}">
+    <img class="logo" src="{{ pathto('_static/' ~ theme_logo, 1) }}" alt="Logo"/>
+    {% if theme_logo_name|lower == 'true' %}
+    <h1 class="logo logo-name">{{ project }}</h2>
+    {% endif %}
+  </a>
+</p>
+{% else %}
+<h1 class="logo"><a href="{{ pathto(master_doc) }}">{{ project }}</a></h1>
+{% endif %}
+
+{% if theme_description %}
+<p class="blurb">{{ theme_description }}</p>
+{% endif %}
+
+{% if theme_github_button|lower == 'true' %}
+<p>
+<iframe src="https://ghbtns.com/github-btn.html?user={{ theme_github_user }}&repo={{ theme_github_repo }}&type={{ theme_github_type }}&count={{ theme_github_count }}&size=large"
+  allowtransparency="true" frameborder="0" scrolling="0" width="200px" height="35px"></iframe>
+</p>
+{% endif %}
+
+{% if theme_travis_button|lower != 'false' %}
+{% if theme_travis_button|lower == 'true' %}
+    {% set path = theme_github_user + '/' + theme_github_repo %}
+{% else %}
+    {% set path = theme_travis_button %}
+{% endif %}
+<p>
+<a href="https://travis-ci.org/{{ path }}">
+    <img
+        alt="https://secure.travis-ci.org/{{ path }}.png?branch=master"
+        src="https://secure.travis-ci.org/{{ path }}.png?branch=master"
+    >
+</a>
+</p>
+{% endif %}

source/_themes/clearlinux/breadcrumbs.html

@@ -1,14 +1,14 @@
-{# Support for Sphinx 1.3+ page_source_suffix, but don't break old builds. #}
-
-{% if page_source_suffix %}
-{% set suffix = page_source_suffix %}
-{% else %}
-{% set suffix = source_suffix %}
-{% endif %}
-
-<div id="site-breadcrumb" class="hidden-sm">
-  <h2 class="element-invisible"></h2>
-  <div class="breadcrumb">
-    <a href="/">Home</a> » <a href="{{ pathto(master_doc) }}">Documentation</a> » {{ title }}
-  </div>
-</div>
+{# Support for Sphinx 1.3+ page_source_suffix, but don't break old builds. #}
+
+{% if page_source_suffix %}
+{% set suffix = page_source_suffix %}
+{% else %}
+{% set suffix = source_suffix %}
+{% endif %}
+
+<div id="site-breadcrumb" class="hidden-sm">
+  <h2 class="element-invisible"></h2>
+  <div class="breadcrumb">
+    <a href="/">Home</a> » <a href="{{ pathto(master_doc) }}">Documentation</a> » {{ title }}
+  </div>
+</div>

source/_themes/clearlinux/donate.html

@@ -1,9 +1,9 @@
-{% if theme_gratipay_user or theme_gittip_user %}
-<h3>Donate</h3>
-<p>
-Consider supporting the authors on <a href="https://www.gratipay.com/">Gratipay</a>:
-<script data-gratipay-username="{{ theme_gratipay_user or theme_gittip_user }}"
-        data-gratipay-widget="button"
-        src="//gttp.co/v1.js"></script>
-</p>
-{% endif %}
+{% if theme_gratipay_user or theme_gittip_user %}
+<h3>Donate</h3>
+<p>
+Consider supporting the authors on <a href="https://www.gratipay.com/">Gratipay</a>:
+<script data-gratipay-username="{{ theme_gratipay_user or theme_gittip_user }}"
+        data-gratipay-widget="button"
+        src="//gttp.co/v1.js"></script>
+</p>
+{% endif %}

source/_themes/clearlinux/footer.html

@@ -1,32 +1,32 @@
-<footer id="footer">
-    <div class="project-footer container clearfix">
-      <span class="intel-sw-logo"></span>
-      <div class="mobile-menu"></div>
-                <div class="region region-footer">
-    <div id="block-menu-menu-footer-menu" class="block block-menu">
-
-
-  <ul class="menu"><li class="first leaf"><a href="/about/privacy-policy">Privacy Policy</a></li>
-<li class="leaf"><a href="mailto:dev@lists.clearlinux.org" class="mailto">Contact us</a></li>
-<li class="leaf"><a href="/about/terms-service">Terms of Service</a></li>
-<li class="leaf"><a href="http://www.intel.com/content/www/us/en/legal/trademarks.html" target="_blank" class="ext">* Trademarks</a></li>
-<li class="last leaf"><a href="http://www.intel.com/content/www/us/en/privacy/intel-cookie-notice.html" target="_blank" class="ext">Cookies</a></li>
-</ul>
-</div>
-<div id="block-menu-block-1" class="block block-menu-block">
-
-
-  <div class="menu-block-wrapper menu-block-1 menu-name-menu-social-media parent-mlid-0 menu-level-1">
-  <ul class="menu"><li class="first leaf menu-mlid-8277"><a href="https://twitter.com/clearlinux" class="social-media icon twitter">Twitter</a></li>
-<li class="leaf menu-mlid-8286"><a href="https://plus.google.com/u/2/b/110130641055512104222/110130641055512104222/posts/p/pub?_ga=1.28912252.1365239857.1461340816" class="social-media icon googleplus">Google +</a></li>
-<li class="last leaf menu-mlid-8279"><a href="https://github.com/clearlinux" class="social-media icon github">Github</a></li>
-</ul></div>
-
-</div>
-  </div>
-    </div>
-    <div class="footer-copyright">
-      <small>Copyright © 2016 Intel Corporation. All rights reserved</small> <br>
-      <small>*Other names and brands may be claimed as the property of others</small>
-    </div>
-</footer>
+<footer id="footer">
+    <div class="project-footer container clearfix">
+      <span class="intel-sw-logo"></span>
+      <div class="mobile-menu"></div>
+                <div class="region region-footer">
+    <div id="block-menu-menu-footer-menu" class="block block-menu">
+
+
+  <ul class="menu"><li class="first leaf"><a href="/about/privacy-policy">Privacy Policy</a></li>
+<li class="leaf"><a href="mailto:dev@lists.clearlinux.org" class="mailto">Contact us</a></li>
+<li class="leaf"><a href="/about/terms-service">Terms of Service</a></li>
+<li class="leaf"><a href="http://www.intel.com/content/www/us/en/legal/trademarks.html" target="_blank" class="ext">* Trademarks</a></li>
+<li class="last leaf"><a href="http://www.intel.com/content/www/us/en/privacy/intel-cookie-notice.html" target="_blank" class="ext">Cookies</a></li>
+</ul>
+</div>
+<div id="block-menu-block-1" class="block block-menu-block">
+
+
+  <div class="menu-block-wrapper menu-block-1 menu-name-menu-social-media parent-mlid-0 menu-level-1">
+  <ul class="menu"><li class="first leaf menu-mlid-8277"><a href="https://twitter.com/clearlinux" class="social-media icon twitter">Twitter</a></li>
+<li class="leaf menu-mlid-8286"><a href="https://plus.google.com/u/2/b/110130641055512104222/110130641055512104222/posts/p/pub?_ga=1.28912252.1365239857.1461340816" class="social-media icon googleplus">Google +</a></li>
+<li class="last leaf menu-mlid-8279"><a href="https://github.com/clearlinux" class="social-media icon github">Github</a></li>
+</ul></div>
+
+</div>
+  </div>
+    </div>
+    <div class="footer-copyright">
+      <small>Copyright © 2016 Intel Corporation. All rights reserved</small> <br>
+      <small>*Other names and brands may be claimed as the property of others</small>
+    </div>
+</footer>

source/_themes/clearlinux/header.html

@@ -1,43 +1,43 @@
-<header>
-    <div id="o1-header">
-      <div class="o1-logo-container hidden-xs">
-        <div class="container"><a href="http://01.org" class="o1-logo ext" target="_blank"></a></div>
-      </div>
-      <div class="project-header container clearfix">
-        <div class="left inline">
-          <a href="/" id="project-name">
-            <span id="project-name-left">Clear Linux&nbsp; <sup>*</sup></span>
-            <span id="project-name-right">Project</span>
-            <span id="project-name-bottom">for Intel* Architecture</span>
-          </a>
-        </div>
-        <div class="right">
-          <div class="mobile-menu"></div>
-                        <div class="region region-header">
-    <div id="block-system-main-menu" class="block block-system block-menu">
-
-
-  <ul class="menu"><li class="first leaf"><a href="https://download.clearlinux.org" title="Downloads" target="_blank">Downloads</a></li>
-<li class="collapsed"><a href="/features" title="Features">Features</a></li>
-<li class="collapsed"><a href="/documentation" title="Documentation" class="active">Documentation</a></li>
-</ul>
-</div>
-<div id="block-menu-menu-get-involved" class="block block-menu">
-
-        <h4>Get Involved</h4>
-
-  <ul class="menu">
-    <li class="first leaf"><a href="http://freenode.net/" target="_blank">IRC #clearlinux</a></li>
-<li class="leaf"><a href="https://lists.clearlinux.org/mailman/listinfo/dev">Mailing list</a></li>
-<li class="last leaf"><a href="/blogs">Blogs</a></li>
-</ul>
-</div>
-  </div>
-                    <ul class="nav-tools">
-            <li><a href="/search"><i class="fa fa-search"></i></a></li>
-            <!--<li><i class="fa fa-mail-forward"></i></li>-->
-          </ul>
-
-      </div>
-    </div>
-  </div></header>
+<header>
+    <div id="o1-header">
+      <div class="o1-logo-container hidden-xs">
+        <div class="container"><a href="http://01.org" class="o1-logo ext" target="_blank"></a></div>
+      </div>
+      <div class="project-header container clearfix">
+        <div class="left inline">
+          <a href="/" id="project-name">
+            <span id="project-name-left">Clear Linux&nbsp; <sup>*</sup></span>
+            <span id="project-name-right">Project</span>
+            <span id="project-name-bottom">for Intel* Architecture</span>
+          </a>
+        </div>
+        <div class="right">
+          <div class="mobile-menu"></div>
+                        <div class="region region-header">
+    <div id="block-system-main-menu" class="block block-system block-menu">
+
+
+  <ul class="menu"><li class="first leaf"><a href="https://download.clearlinux.org" title="Downloads" target="_blank">Downloads</a></li>
+<li class="collapsed"><a href="/features" title="Features">Features</a></li>
+<li class="collapsed"><a href="/documentation" title="Documentation" class="active">Documentation</a></li>
+</ul>
+</div>
+<div id="block-menu-menu-get-involved" class="block block-menu">
+
+        <h4>Get Involved</h4>
+
+  <ul class="menu">
+    <li class="first leaf"><a href="http://freenode.net/" target="_blank">IRC #clearlinux</a></li>
+<li class="leaf"><a href="https://lists.clearlinux.org/mailman/listinfo/dev">Mailing list</a></li>
+<li class="last leaf"><a href="/blogs">Blogs</a></li>
+</ul>
+</div>
+  </div>
+                    <ul class="nav-tools">
+            <li><a href="/search"><i class="fa fa-search"></i></a></li>
+            <!--<li><i class="fa fa-mail-forward"></i></li>-->
+          </ul>
+
+      </div>
+    </div>
+  </div></header>

source/_themes/clearlinux/layout.html

@@ -1,183 +1,183 @@
-{# TEMPLATE VAR SETTINGS #}
-{% set script_files = script_files + ['_static/js/affix.js'] %}
-{% set script_files = script_files + ['_static/js/project.js'] %}
-{%- set url_root = pathto('', 1) %}
-{%- if url_root == '#' %}{% set url_root = '' %}{% endif %}
-
-<!DOCTYPE html>
-<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
-<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
-<head>
-  <meta charset="utf-8">
-  {{ metatags }}
-  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-  {% block htmltitle %}
-  <title>{{ title|striptags|e }}{{ titlesuffix }}</title>
-  {% endblock %}
-
-<link rel="icon" type="image/png" sizes="192x192" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_android_192x192.png" />
-<link rel="apple-touch-icon" sizes="180x180" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_180x180.png" />
-<link rel="apple-touch-icon" sizes="152x152" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_152x152.png" />
-<link rel="icon" type="image/png" sizes="32x32" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_web_32x32.png" />
-<link rel="icon" type="image/png" sizes="96x96" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_web_96x96.png" />
-<meta name="google-site-verification" content="xDIK6ZRF9BKNIeBUstAHF3zS6bpi2eCjBHemCQAEH8o" />
-<meta name="msapplication-TileImage" href="sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_microsoft_144x144.png" />
-<meta name="theme-color" content="#7DD2F7" />
-<link rel="icon" type="image/png" sizes="16x16" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_web_16x16.png" />
-<link rel="apple-touch-icon" sizes="144x144" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_144x144.png" />
-<link rel="apple-touch-icon" sizes="120x120" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_120x120.png" />
-<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
-<link rel="shortcut icon" href="/sites/all/themes/custom/clearlinux_theme/favicon.ico" type="image/vnd.microsoft.icon" />
-<link rel="apple-touch-icon" sizes="57x57" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_57x57.png" />
-<link rel="apple-touch-icon" sizes="76x76" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_76x76.png" />
-<link rel="apple-touch-icon" sizes="72x72" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_72x72.png" />
-<link rel="apple-touch-icon" sizes="60x60" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_60x60.png" />
-<link rel="apple-touch-icon" sizes="114x114" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_114x114.png" />
-
-  {# CSS #}
-
-  {# OPENSEARCH #}
-  {% if not embedded %}
-    {% if use_opensearch %}
-      <link rel="search" type="application/opensearchdescription+xml" title="{% trans docstitle=docstitle|e %}Search within {{ docstitle }}{% endtrans %}" href="{{ pathto('_static/opensearch.xml', 1) }}"/>
-    {% endif %}
-
-  {% endif %}
-
-  {# RTD hosts this file, so just load on non RTD builds #}
-  {% if not READTHEDOCS %}
-    <link rel="stylesheet" href="{{ pathto('_static/' + style, 1) }}" type="text/css" />
-  {% endif %}
-
-  {% for cssfile in css_files %}
-    <link rel="stylesheet" href="{{ pathto(cssfile, 1) }}" type="text/css" />
-  {% endfor %}
-
-  {% for cssfile in extra_css_files %}
-    <link rel="stylesheet" href="{{ pathto(cssfile, 1) }}" type="text/css" />
-  {% endfor %}
-
-    <link rel="stylesheet" href="{{ '/sites/all/themes/custom/clearlinux_theme/css/main.css' }}" type="text/css" />
-    <link rel="stylesheet" href="{{ pathto('_static/css/overrides.css', 1) }}" type="text/css" />
-
-  {%- block linktags %}
-    {%- if hasdoc('about') %}
-        <link rel="author" title="{{ _('About these documents') }}"
-              href="{{ pathto('about') }}"/>
-    {%- endif %}
-    {%- if hasdoc('genindex') %}
-        <link rel="index" title="{{ _('Index') }}"
-              href="{{ pathto('genindex') }}"/>
-    {%- endif %}
-    {%- if hasdoc('search') %}
-        <link rel="search" title="{{ _('Search') }}" href="{{ pathto('search') }}"/>
-    {%- endif %}
-    {%- if hasdoc('copyright') %}
-        <link rel="copyright" title="{{ _('Copyright') }}" href="{{ pathto('copyright') }}"/>
-    {%- endif %}
-    <link rel="top" title="{{ docstitle|e }}" href="{{ pathto('index') }}"/>
-    {%- if parents %}
-        <link rel="up" title="{{ parents[-1].title|striptags|e }}" href="{{ parents[-1].link|e }}"/>
-    {%- endif %}
-    {%- if next %}
-        <link rel="next" title="{{ next.title|striptags|e }}" href="{{ next.link|e }}"/>
-    {%- endif %}
-    {%- if prev %}
-        <link rel="prev" title="{{ prev.title|striptags|e }}" href="{{ prev.link|e }}"/>
-    {%- endif %}
-  {%- endblock %}
-  {%- block extrahead %}
-     {% if theme_touch_icon %}
-      <link rel="apple-touch-icon" href="{{ pathto('_static/' ~ theme_touch_icon, 1) }}" />
-      {% endif %}
-    <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9">
-  {% endblock %}
-
-  {# Keep modernizr in head - http://modernizr.com/docs/#installing #}
-  <script src="{{ '/sites/all/themes/custom/clearlinux_theme/js/modernizr.custom.19994.js' }}"></script>
-
-</head>
-
-<body role="document" >
-  <div id="wrapper">
-  {% include "header.html" %}
-      {# PAGE CONTENT #}
-      <div class="main-content">
-        <div id="site-breadcrumb" class="hidden-sm">
-            <div class="container">{% include "breadcrumbs.html" %}</div>
-          </div>
-        <div class="container clearfix">
-          <div class="row">
-           <div class="col-lg-12 col-md-12 col-sm-12 col-xs-12">
-            <div class="region region-content">
-              <div class="content">
-                <div class="container-fluid">
-                  <div class="row">
-                    <div class="col-md-4 col-sm-4 col-xs-12">
-                      <div class="row"><div class="col-md-12 col-sm-12 col-xs-12">{% include "navigation.html" %}</div></div>
-                      <div class="row"><div class="col-md-12 col-sm-12 col-xs-12">{% include "searchbox.html" %}</div></div>
-                    </div>
-                    <div class="col-md-8 col-sm-8 col-xs-12">{% block body %}{% endblock %}</div>
-                  </div>
-                </div>
-              </div>
-            </div>
-           </div>
-          </div>
-        </div>
-      </div>
-      {% include "footer.html" %}
-    </div>
-    {% if not embedded %}
-
-      <script type="text/javascript">
-          var DOCUMENTATION_OPTIONS = {
-              URL_ROOT:'{{ url_root }}',
-              VERSION:'{{ release|e }}',
-              COLLAPSE_INDEX:false,
-              FILE_SUFFIX:'{{ '' if no_search_suffix else file_suffix }}',
-              HAS_SOURCE:  {{ has_source|lower }}
-          };
-      </script>
-      {%- for scriptfile in script_files %}
-        <script type="text/javascript" src="{{ pathto(scriptfile, 1) }}"></script>
-      {%- endfor %}
-
-    {% endif %}
-
-    {# RTD hosts this file, so just load on non RTD builds #}
-    {% if not READTHEDOCS %}
-      <script type="text/javascript" src="{{ pathto('_static/js/theme.js', 1) }}"></script>
-    {% endif %}
-
-    {# STICKY NAVIGATION #}
-    {% if theme_sticky_navigation %}
-    <script type="text/javascript">
-        jQuery(function () {
-            SphinxRtdTheme.StickyNav.enable();
-        });
-    </script>
-    {% endif %}
-
-     <script type="text/javascript">
-    jQuery(function() { Search.loadIndex("{{ pathto('searchindex.js', 1) }}"); });
-    </script>
-    {# this is used when loading the search index using $.ajax fails,
-       such as on Chrome for documents on localhost #}
-    <script type="text/javascript" id="searchindexloader"></script>
-  {# Adding the google analytics tracking code #}
-  <script>
-  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
-  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
-  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
-  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
-  ga('create', 'UA-61272224-1', 'auto');
-  ga('send', 'pageview');
-  </script>
-  {# Disable base theme's top+bottom related navs; we have our own in sidebar #}
-  {%- block relbar1 %}{% endblock %}
-  {%- block relbar2 %}{% endblock %}
-  {%- block footer %} {% endblock %}
-</body>
-</html>
-
+{# TEMPLATE VAR SETTINGS #}
+{% set script_files = script_files + ['_static/js/affix.js'] %}
+{% set script_files = script_files + ['_static/js/project.js'] %}
+{%- set url_root = pathto('', 1) %}
+{%- if url_root == '#' %}{% set url_root = '' %}{% endif %}
+
+<!DOCTYPE html>
+<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
+<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
+<head>
+  <meta charset="utf-8">
+  {{ metatags }}
+  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+  {% block htmltitle %}
+  <title>{{ title|striptags|e }}{{ titlesuffix }}</title>
+  {% endblock %}
+
+<link rel="icon" type="image/png" sizes="192x192" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_android_192x192.png" />
+<link rel="apple-touch-icon" sizes="180x180" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_180x180.png" />
+<link rel="apple-touch-icon" sizes="152x152" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_152x152.png" />
+<link rel="icon" type="image/png" sizes="32x32" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_web_32x32.png" />
+<link rel="icon" type="image/png" sizes="96x96" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_web_96x96.png" />
+<meta name="google-site-verification" content="xDIK6ZRF9BKNIeBUstAHF3zS6bpi2eCjBHemCQAEH8o" />
+<meta name="msapplication-TileImage" href="sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_microsoft_144x144.png" />
+<meta name="theme-color" content="#7DD2F7" />
+<link rel="icon" type="image/png" sizes="16x16" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_web_16x16.png" />
+<link rel="apple-touch-icon" sizes="144x144" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_144x144.png" />
+<link rel="apple-touch-icon" sizes="120x120" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_120x120.png" />
+<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
+<link rel="shortcut icon" href="/sites/all/themes/custom/clearlinux_theme/favicon.ico" type="image/vnd.microsoft.icon" />
+<link rel="apple-touch-icon" sizes="57x57" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_57x57.png" />
+<link rel="apple-touch-icon" sizes="76x76" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_76x76.png" />
+<link rel="apple-touch-icon" sizes="72x72" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_72x72.png" />
+<link rel="apple-touch-icon" sizes="60x60" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_60x60.png" />
+<link rel="apple-touch-icon" sizes="114x114" href="/sites/all/themes/custom/clearlinux_theme/images/favicons/favicon_apple_114x114.png" />
+
+  {# CSS #}
+
+  {# OPENSEARCH #}
+  {% if not embedded %}
+    {% if use_opensearch %}
+      <link rel="search" type="application/opensearchdescription+xml" title="{% trans docstitle=docstitle|e %}Search within {{ docstitle }}{% endtrans %}" href="{{ pathto('_static/opensearch.xml', 1) }}"/>
+    {% endif %}
+
+  {% endif %}
+
+  {# RTD hosts this file, so just load on non RTD builds #}
+  {% if not READTHEDOCS %}
+    <link rel="stylesheet" href="{{ pathto('_static/' + style, 1) }}" type="text/css" />
+  {% endif %}
+
+  {% for cssfile in css_files %}
+    <link rel="stylesheet" href="{{ pathto(cssfile, 1) }}" type="text/css" />
+  {% endfor %}
+
+  {% for cssfile in extra_css_files %}
+    <link rel="stylesheet" href="{{ pathto(cssfile, 1) }}" type="text/css" />
+  {% endfor %}
+
+    <link rel="stylesheet" href="{{ '/sites/all/themes/custom/clearlinux_theme/css/main.css' }}" type="text/css" />
+    <link rel="stylesheet" href="{{ pathto('_static/css/overrides.css', 1) }}" type="text/css" />
+
+  {%- block linktags %}
+    {%- if hasdoc('about') %}
+        <link rel="author" title="{{ _('About these documents') }}"
+              href="{{ pathto('about') }}"/>
+    {%- endif %}
+    {%- if hasdoc('genindex') %}
+        <link rel="index" title="{{ _('Index') }}"
+              href="{{ pathto('genindex') }}"/>
+    {%- endif %}
+    {%- if hasdoc('search') %}
+        <link rel="search" title="{{ _('Search') }}" href="{{ pathto('search') }}"/>
+    {%- endif %}
+    {%- if hasdoc('copyright') %}
+        <link rel="copyright" title="{{ _('Copyright') }}" href="{{ pathto('copyright') }}"/>
+    {%- endif %}
+    <link rel="top" title="{{ docstitle|e }}" href="{{ pathto('index') }}"/>
+    {%- if parents %}
+        <link rel="up" title="{{ parents[-1].title|striptags|e }}" href="{{ parents[-1].link|e }}"/>
+    {%- endif %}
+    {%- if next %}
+        <link rel="next" title="{{ next.title|striptags|e }}" href="{{ next.link|e }}"/>
+    {%- endif %}
+    {%- if prev %}
+        <link rel="prev" title="{{ prev.title|striptags|e }}" href="{{ prev.link|e }}"/>
+    {%- endif %}
+  {%- endblock %}
+  {%- block extrahead %}
+     {% if theme_touch_icon %}
+      <link rel="apple-touch-icon" href="{{ pathto('_static/' ~ theme_touch_icon, 1) }}" />
+      {% endif %}
+    <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9">
+  {% endblock %}
+
+  {# Keep modernizr in head - http://modernizr.com/docs/#installing #}
+  <script src="{{ '/sites/all/themes/custom/clearlinux_theme/js/modernizr.custom.19994.js' }}"></script>
+
+</head>
+
+<body role="document" >
+  <div id="wrapper">
+  {% include "header.html" %}
+      {# PAGE CONTENT #}
+      <div class="main-content">
+        <div id="site-breadcrumb" class="hidden-sm">
+            <div class="container">{% include "breadcrumbs.html" %}</div>
+          </div>
+        <div class="container clearfix">
+          <div class="row">
+           <div class="col-lg-12 col-md-12 col-sm-12 col-xs-12">
+            <div class="region region-content">
+              <div class="content">
+                <div class="container-fluid">
+                  <div class="row">
+                    <div class="col-md-4 col-sm-4 col-xs-12">
+                      <div class="row"><div class="col-md-12 col-sm-12 col-xs-12">{% include "navigation.html" %}</div></div>
+                      <div class="row"><div class="col-md-12 col-sm-12 col-xs-12">{% include "searchbox.html" %}</div></div>
+                    </div>
+                    <div class="col-md-8 col-sm-8 col-xs-12">{% block body %}{% endblock %}</div>
+                  </div>
+                </div>
+              </div>
+            </div>
+           </div>
+          </div>
+        </div>
+      </div>
+      {% include "footer.html" %}
+    </div>
+    {% if not embedded %}
+
+      <script type="text/javascript">
+          var DOCUMENTATION_OPTIONS = {
+              URL_ROOT:'{{ url_root }}',
+              VERSION:'{{ release|e }}',
+              COLLAPSE_INDEX:false,
+              FILE_SUFFIX:'{{ '' if no_search_suffix else file_suffix }}',
+              HAS_SOURCE:  {{ has_source|lower }}
+          };
+      </script>
+      {%- for scriptfile in script_files %}
+        <script type="text/javascript" src="{{ pathto(scriptfile, 1) }}"></script>
+      {%- endfor %}
+
+    {% endif %}
+
+    {# RTD hosts this file, so just load on non RTD builds #}
+    {% if not READTHEDOCS %}
+      <script type="text/javascript" src="{{ pathto('_static/js/theme.js', 1) }}"></script>
+    {% endif %}
+
+    {# STICKY NAVIGATION #}
+    {% if theme_sticky_navigation %}
+    <script type="text/javascript">
+        jQuery(function () {
+            SphinxRtdTheme.StickyNav.enable();
+        });
+    </script>
+    {% endif %}
+
+     <script type="text/javascript">
+    jQuery(function() { Search.loadIndex("{{ pathto('searchindex.js', 1) }}"); });
+    </script>
+    {# this is used when loading the search index using $.ajax fails,
+       such as on Chrome for documents on localhost #}
+    <script type="text/javascript" id="searchindexloader"></script>
+  {# Adding the google analytics tracking code #}
+  <script>
+  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+  ga('create', 'UA-61272224-1', 'auto');
+  ga('send', 'pageview');
+  </script>
+  {# Disable base theme's top+bottom related navs; we have our own in sidebar #}
+  {%- block relbar1 %}{% endblock %}
+  {%- block relbar2 %}{% endblock %}
+  {%- block footer %} {% endblock %}
+</body>
+</html>
+

source/_themes/clearlinux/navigation.html

@@ -1,12 +1,12 @@
-<sidebar>
-  <h2>Content Map</h2>
-      {% set toctree = toctree(maxdepth=2, collapse=theme_collapse_navigation, includehidden=True) %}
-      {% set toctree = toctree|replace("<ul>", "<ul class=\"custom-dropdown-menu\">", -1)  %}
-      {% set toctree = toctree|replace("<ul class=\"current\">", "<ul class=\"custom-dropdown-menu\">", -1)  %}
-      {% set toctree = toctree|replace("<li class=\"toctree-l1 current\">", "<li class=\"menu-item-open parent-item\">", -1)  %}
-      {% set toctree = toctree|replace("<li class=\"toctree-l1\">", "<li class=\"menu-item-closed parent-item\">", -1)  %}
-      {% set toctree = toctree|replace("<a class=\"current reference internal\" href=\"\">", "<a class=\"active\">", -1)  %}
-      {% set toctree = toctree|replace("<li class=\"toctree-l2\">", "<li class=\"child-item first-level no-childs\">", -1)  %}
-      {% set toctree = toctree|replace("<li class=\"toctree-l2 current\">", "<li class=\"child-item first-level no-childs\">", -1)  %}
-      {{ toctree }}
-</sidebar>
+<sidebar>
+  <h2>Content Map</h2>
+      {% set toctree = toctree(maxdepth=2, collapse=theme_collapse_navigation, includehidden=True) %}
+      {% set toctree = toctree|replace("<ul>", "<ul class=\"custom-dropdown-menu\">", -1)  %}
+      {% set toctree = toctree|replace("<ul class=\"current\">", "<ul class=\"custom-dropdown-menu\">", -1)  %}
+      {% set toctree = toctree|replace("<li class=\"toctree-l1 current\">", "<li class=\"menu-item-open parent-item\">", -1)  %}
+      {% set toctree = toctree|replace("<li class=\"toctree-l1\">", "<li class=\"menu-item-closed parent-item\">", -1)  %}
+      {% set toctree = toctree|replace("<a class=\"current reference internal\" href=\"\">", "<a class=\"active\">", -1)  %}
+      {% set toctree = toctree|replace("<li class=\"toctree-l2\">", "<li class=\"child-item first-level no-childs\">", -1)  %}
+      {% set toctree = toctree|replace("<li class=\"toctree-l2 current\">", "<li class=\"child-item first-level no-childs\">", -1)  %}
+      {{ toctree }}
+</sidebar>

source/_themes/clearlinux/relations.html

@@ -1,21 +1,21 @@
-<div class="relations">
-<h3>Related Topics</h3>
-<ul>
-  <li><a href="{{ pathto(master_doc) }}">Documentation overview</a><ul>
-  {%- for parent in parents %}
-  <li><a href="{{ parent.link|e }}">{{ parent.title }}</a><ul>
-  {%- endfor %}
-    {%- if prev %}
-      <li>Previous: <a href="{{ prev.link|e }}" title="{{ _('previous chapter')
-        }}">{{ prev.title }}</a></li>
-    {%- endif %}
-    {%- if next %}
-      <li>Next: <a href="{{ next.link|e }}" title="{{ _('next chapter')
-        }}">{{ next.title }}</a></li>
-    {%- endif %}
-  {%- for parent in parents %}
-  </ul></li>
-  {%- endfor %}
-  </ul></li>
-</ul>
-</div>
+<div class="relations">
+<h3>Related Topics</h3>
+<ul>
+  <li><a href="{{ pathto(master_doc) }}">Documentation overview</a><ul>
+  {%- for parent in parents %}
+  <li><a href="{{ parent.link|e }}">{{ parent.title }}</a><ul>
+  {%- endfor %}
+    {%- if prev %}
+      <li>Previous: <a href="{{ prev.link|e }}" title="{{ _('previous chapter')
+        }}">{{ prev.title }}</a></li>
+    {%- endif %}
+    {%- if next %}
+      <li>Next: <a href="{{ next.link|e }}" title="{{ _('next chapter')
+        }}">{{ next.title }}</a></li>
+    {%- endif %}
+  {%- for parent in parents %}
+  </ul></li>
+  {%- endfor %}
+  </ul></li>
+</ul>
+</div>

source/_themes/clearlinux/search.html

@@ -1,50 +1,50 @@
-{#
-    basic/search.html
-    ~~~~~~~~~~~~~~~~~
-
-    Template for the search page.
-
-    :copyright: Copyright 2007-2013 by the Sphinx team, see AUTHORS.
-    :license: BSD, see LICENSE for details.
-#}
-{%- extends "layout.html" %}
-{% set title = _('Search') %}
-{% set script_files = script_files + ['_static/searchtools.js'] %}
-{% block footer %}
-  <script type="text/javascript">
-    jQuery(function() { Search.loadIndex("{{ pathto('searchindex.js', 1) }}"); });
-  </script>
-  {# this is used when loading the search index using $.ajax fails,
-     such as on Chrome for documents on localhost #}
-  <script type="text/javascript" id="searchindexloader"></script>
-  {{ super() }}
-{% endblock %}
-{% block body %}
-  <noscript>
-  <div id="fallback" class="admonition warning">
-    <p class="last">
-      {% trans %}Please activate JavaScript to enable the search
-      functionality.{% endtrans %}
-    </p>
-  </div>
-  </noscript>
-
-  {% if search_performed %}
-    <h2>{{ _('Search Results') }}</h2>
-    {% if not search_results %}
-      <p>{{ _('Your search did not match any documents. Please make sure that all words are spelled correctly and that you\'ve selected enough categories.') }}</p>
-    {% endif %}
-  {% endif %}
-  <div id="search-results">
-  {% if search_results %}
-    <ul>
-    {% for href, caption, context in search_results %}
-      <li>
-        <a href="{{ pathto(item.href) }}">{{ caption }}</a>
-        <p class="context">{{ context|e }}</p>
-      </li>
-    {% endfor %}
-    </ul>
-  {% endif %}
-  </div>
-{% endblock %}
+{#
+    basic/search.html
+    ~~~~~~~~~~~~~~~~~
+
+    Template for the search page.
+
+    :copyright: Copyright 2007-2013 by the Sphinx team, see AUTHORS.
+    :license: BSD, see LICENSE for details.
+#}
+{%- extends "layout.html" %}
+{% set title = _('Search') %}
+{% set script_files = script_files + ['_static/searchtools.js'] %}
+{% block footer %}
+  <script type="text/javascript">
+    jQuery(function() { Search.loadIndex("{{ pathto('searchindex.js', 1) }}"); });
+  </script>
+  {# this is used when loading the search index using $.ajax fails,
+     such as on Chrome for documents on localhost #}
+  <script type="text/javascript" id="searchindexloader"></script>
+  {{ super() }}
+{% endblock %}
+{% block body %}
+  <noscript>
+  <div id="fallback" class="admonition warning">
+    <p class="last">
+      {% trans %}Please activate JavaScript to enable the search
+      functionality.{% endtrans %}
+    </p>
+  </div>
+  </noscript>
+
+  {% if search_performed %}
+    <h2>{{ _('Search Results') }}</h2>
+    {% if not search_results %}
+      <p>{{ _('Your search did not match any documents. Please make sure that all words are spelled correctly and that you\'ve selected enough categories.') }}</p>
+    {% endif %}
+  {% endif %}
+  <div id="search-results">
+  {% if search_results %}
+    <ul>
+    {% for href, caption, context in search_results %}
+      <li>
+        <a href="{{ pathto(item.href) }}">{{ caption }}</a>
+        <p class="context">{{ context|e }}</p>
+      </li>
+    {% endfor %}
+    </ul>
+  {% endif %}
+  </div>
+{% endblock %}

source/_themes/clearlinux/searchbox.html

@@ -1,12 +1,12 @@
-{%- if builder != 'singlehtml' %}
-<br />
-<div id="searchbox" role="search">
-  <h2>Quick Search</h2>
-  <form class="search" action="{{ pathto('search') }}" method="get">
-    <input type="text" name="q" placeholder="Search docs" />
-    <input type="hidden" name="check_keywords" value="yes" />
-    <input type="hidden" name="area" value="default" />
-    <input type="submit" value="Go" class="pull-right">
-  </form>
-</div>
-{%- endif %}
+{%- if builder != 'singlehtml' %}
+<br />
+<div id="searchbox" role="search">
+  <h2>Quick Search</h2>
+  <form class="search" action="{{ pathto('search') }}" method="get">
+    <input type="text" name="q" placeholder="Search docs" />
+    <input type="hidden" name="check_keywords" value="yes" />
+    <input type="hidden" name="area" value="default" />
+    <input type="submit" value="Go" class="pull-right">
+  </form>
+</div>
+{%- endif %}

source/_themes/clearlinux/static/css/.gitignore

@@ -1,2 +1,2 @@
-#Ignore css files ands sass cache
-.sass-cache
+#Ignore css files ands sass cache
+.sass-cache

source/_themes/clearlinux/static/css/main.css

@@ -1 +1 @@
-// main
+// main

source/_themes/clearlinux/static/css/overrides.css

@@ -1,162 +1,162 @@
-// Put all css overrides below
-
-#clear-linux-project-for-intel-architecture-documentation li.toctree-l1{
-  list-style-type: none;
-}
-
-#clear-linux-project-for-intel-architecture-documentation li.toctree-l1 > a{
-  display: none;
-}
-
-#clear-linux-project-for-intel-architecture-documentation li.toctree-l2{
-  list-style-type: disc;
-  margin-left: -40px;
-}
-
-#searchbox {
-  margin-bottom: 45px;
-}
-  @media (min-width: 992px) {
-    #searchbox {
-      margin-bottom: 0; } }
-  #searchbox input[type=text] {
-    width: 100%;
-    padding-right: 80px; }
-  #searchbox input[type=submit] {
-    position: absolute;
-    right: 0;
-    top: 0; }
-  #searchbox form.search {
-    position: relative; }
-
-sidebar .custom-dropdown-menu {
-  margin-bottom: 5px;
-  padding: 0; }
-  sidebar .custom-dropdown-menu .no-childs .fa:before {
-    display: none; }
-  sidebar .custom-dropdown-menu li {
-    list-style-type: none;
-    margin: 0; }
-    sidebar .custom-dropdown-menu li a {
-      color: #2d3237 !important;
-      cursor: pointer;
-      text-decoration: none;
-      display: block;
-      padding: 10px 25px 10px 10px; }
-      sidebar .custom-dropdown-menu li a:focus, sidebar .custom-dropdown-menu li a:visited {
-        color: #2d3237 !important;
-        text-decoration: none; }
-        sidebar .custom-dropdown-menu li a:focus span, sidebar .custom-dropdown-menu li a:visited span {
-          color: #fff !important; }
-      sidebar .custom-dropdown-menu li a:hover {
-        color: #fff !important;
-        cursor: pointer;
-        text-decoration: none; }
-        sidebar .custom-dropdown-menu li a:hover span {
-          color: #fff !important;
-          cursor: pointer; }
-      sidebar .custom-dropdown-menu li a:hover, sidebar .custom-dropdown-menu li a.active {
-        background-color: #D1D3D5;
-        color: #2d3237 !important; }
-        sidebar .custom-dropdown-menu li a:hover span.fa, sidebar .custom-dropdown-menu li a.active span.fa {
-          color: #fff !important; }
-      sidebar .custom-dropdown-menu li a span.fa {
-        color: #2d3237 !important;
-        cursor: pointer; }
-    sidebar .custom-dropdown-menu li.parent-item a {
-      position: relative;
-      border: none !important;
-       }
-      sidebar .custom-dropdown-menu li.parent-item a .fa {
-        padding: 5px;
-        position: absolute;
-        right: 5px;
-        top: 10px; }
-    sidebar .custom-dropdown-menu li.parent-item a.active .fa {
-      color: #fff !important;
-    }
-    sidebar .custom-dropdown-menu li.parent-item > a {
-      background-color: #D1D3D5;
-      color: #2d3237 !important;
-      }
-      sidebar .custom-dropdown-menu li.parent-item > a.active, sidebar .custom-dropdown-menu li.parent-item > a:hover {
-        background-color: #00AEFF;
-        color: #fff !important; }
-    sidebar .custom-dropdown-menu li.parent-item a.active {
-      background-color: #00AEFF;
-      color: #fff; }
-    sidebar .custom-dropdown-menu li ul {
-      background-color: #F0F2F4;
-      margin-left: 0 !important;
-      height: 0;
-      visibility: hidden; }
-      sidebar .custom-dropdown-menu li ul ul {
-        margin-top: 0; }
-    sidebar .custom-dropdown-menu li.menu-item-closed ul {
-      height: 0 !important;
-      visibility: hidden !important; }
-    sidebar .custom-dropdown-menu li li.second-level {
-      margin: 0; }
-      sidebar .custom-dropdown-menu li li.second-level a {
-        padding-left: 20px; }
-    sidebar .custom-dropdown-menu li.menu-item-open.parent-item > a {
-      background-color: #D1D3D5;
-      color: #2d3237 !important;
-     border-bottom: none !important;
-     }
-      sidebar .custom-dropdown-menu li.menu-item-open.parent-item > a, sidebar .custom-dropdown-menu li.menu-item-open.parent-item > a:hover {
-        background-color: #00AEFF;
-        color: #fff !important; }
-    sidebar .custom-dropdown-menu li.menu-item-open > ul{
-      height: auto;
-      padding: 0;
-      visibility: visible; }
-    sidebar .custom-dropdown-menu li.active a > .fa:before {
-      position: relative;
-      float: right;
-      top: -3px; }
-
-    sidebar .custom-dropdown-menu li.menu-item-open a > .fa {
-      color: #fff !important;
-    }
-
-   sidebar .custom-dropdown-menu li.menu-item-open li.child-item a:active {
-      color: #000 !important;
-    }
-
-   li.child-item > a.active {
-     background-color: #D1D3D5 !important;
-     color: #000 !important;
-     border-bottom: none !important;
-     border-right: 2px solid #00AEFF !important;
-  }
-
-  .main-content{
-    padding-top: 110px !important;
-  }
-
-#site-breadcrumb {
-  margin-bottom: 0px !important;
-}
-
-.region-content {
-  padding-top: 25px;
-  padding-bottom: 200px;
-}
-
-input[type=text] {
-  min-height: 46px !important;
-}
-
-button, .button, .btn, input[type=button],
-input[type=submit], input[type=reset]{
-  margin: 0px;
-}
-
-footer .menu-name-menu-social-media {
-    text-align: left;
-    margin-right: 15px;
-    position: absolute;
-    right: 0;
-    top: 25px;
-}
+// Put all css overrides below
+
+#clear-linux-project-for-intel-architecture-documentation li.toctree-l1{
+  list-style-type: none;
+}
+
+#clear-linux-project-for-intel-architecture-documentation li.toctree-l1 > a{
+  display: none;
+}
+
+#clear-linux-project-for-intel-architecture-documentation li.toctree-l2{
+  list-style-type: disc;
+  margin-left: -40px;
+}
+
+#searchbox {
+  margin-bottom: 45px;
+}
+  @media (min-width: 992px) {
+    #searchbox {
+      margin-bottom: 0; } }
+  #searchbox input[type=text] {
+    width: 100%;
+    padding-right: 80px; }
+  #searchbox input[type=submit] {
+    position: absolute;
+    right: 0;
+    top: 0; }
+  #searchbox form.search {
+    position: relative; }
+
+sidebar .custom-dropdown-menu {
+  margin-bottom: 5px;
+  padding: 0; }
+  sidebar .custom-dropdown-menu .no-childs .fa:before {
+    display: none; }
+  sidebar .custom-dropdown-menu li {
+    list-style-type: none;
+    margin: 0; }
+    sidebar .custom-dropdown-menu li a {
+      color: #2d3237 !important;
+      cursor: pointer;
+      text-decoration: none;
+      display: block;
+      padding: 10px 25px 10px 10px; }
+      sidebar .custom-dropdown-menu li a:focus, sidebar .custom-dropdown-menu li a:visited {
+        color: #2d3237 !important;
+        text-decoration: none; }
+        sidebar .custom-dropdown-menu li a:focus span, sidebar .custom-dropdown-menu li a:visited span {
+          color: #fff !important; }
+      sidebar .custom-dropdown-menu li a:hover {
+        color: #fff !important;
+        cursor: pointer;
+        text-decoration: none; }
+        sidebar .custom-dropdown-menu li a:hover span {
+          color: #fff !important;
+          cursor: pointer; }
+      sidebar .custom-dropdown-menu li a:hover, sidebar .custom-dropdown-menu li a.active {
+        background-color: #D1D3D5;
+        color: #2d3237 !important; }
+        sidebar .custom-dropdown-menu li a:hover span.fa, sidebar .custom-dropdown-menu li a.active span.fa {
+          color: #fff !important; }
+      sidebar .custom-dropdown-menu li a span.fa {
+        color: #2d3237 !important;
+        cursor: pointer; }
+    sidebar .custom-dropdown-menu li.parent-item a {
+      position: relative;
+      border: none !important;
+       }
+      sidebar .custom-dropdown-menu li.parent-item a .fa {
+        padding: 5px;
+        position: absolute;
+        right: 5px;
+        top: 10px; }
+    sidebar .custom-dropdown-menu li.parent-item a.active .fa {
+      color: #fff !important;
+    }
+    sidebar .custom-dropdown-menu li.parent-item > a {
+      background-color: #D1D3D5;
+      color: #2d3237 !important;
+      }
+      sidebar .custom-dropdown-menu li.parent-item > a.active, sidebar .custom-dropdown-menu li.parent-item > a:hover {
+        background-color: #00AEFF;
+        color: #fff !important; }
+    sidebar .custom-dropdown-menu li.parent-item a.active {
+      background-color: #00AEFF;
+      color: #fff; }
+    sidebar .custom-dropdown-menu li ul {
+      background-color: #F0F2F4;
+      margin-left: 0 !important;
+      height: 0;
+      visibility: hidden; }
+      sidebar .custom-dropdown-menu li ul ul {
+        margin-top: 0; }
+    sidebar .custom-dropdown-menu li.menu-item-closed ul {
+      height: 0 !important;
+      visibility: hidden !important; }
+    sidebar .custom-dropdown-menu li li.second-level {
+      margin: 0; }
+      sidebar .custom-dropdown-menu li li.second-level a {
+        padding-left: 20px; }
+    sidebar .custom-dropdown-menu li.menu-item-open.parent-item > a {
+      background-color: #D1D3D5;
+      color: #2d3237 !important;
+     border-bottom: none !important;
+     }
+      sidebar .custom-dropdown-menu li.menu-item-open.parent-item > a, sidebar .custom-dropdown-menu li.menu-item-open.parent-item > a:hover {
+        background-color: #00AEFF;
+        color: #fff !important; }
+    sidebar .custom-dropdown-menu li.menu-item-open > ul{
+      height: auto;
+      padding: 0;
+      visibility: visible; }
+    sidebar .custom-dropdown-menu li.active a > .fa:before {
+      position: relative;
+      float: right;
+      top: -3px; }
+
+    sidebar .custom-dropdown-menu li.menu-item-open a > .fa {
+      color: #fff !important;
+    }
+
+   sidebar .custom-dropdown-menu li.menu-item-open li.child-item a:active {
+      color: #000 !important;
+    }
+
+   li.child-item > a.active {
+     background-color: #D1D3D5 !important;
+     color: #000 !important;
+     border-bottom: none !important;
+     border-right: 2px solid #00AEFF !important;
+  }
+
+  .main-content{
+    padding-top: 110px !important;
+  }
+
+#site-breadcrumb {
+  margin-bottom: 0px !important;
+}
+
+.region-content {
+  padding-top: 25px;
+  padding-bottom: 200px;
+}
+
+input[type=text] {
+  min-height: 46px !important;
+}
+
+button, .button, .btn, input[type=button],
+input[type=submit], input[type=reset]{
+  margin: 0px;
+}
+
+footer .menu-name-menu-social-media {
+    text-align: left;
+    margin-right: 15px;
+    position: absolute;
+    right: 0;
+    top: 25px;
+}

source/_themes/clearlinux/static/js/affix.js

@@ -1,162 +1,162 @@
-/* ========================================================================
- * Bootstrap: affix.js v3.3.5
- * http://getbootstrap.com/javascript/#affix
- * ========================================================================
- * Copyright 2011-2015 Twitter, Inc.
- * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
- * ======================================================================== */
-
-
-+function ($) {
-  'use strict';
-
-  // AFFIX CLASS DEFINITION
-  // ======================
-
-  var Affix = function (element, options) {
-    this.options = $.extend({}, Affix.DEFAULTS, options)
-
-    this.$target = $(this.options.target)
-      .on('scroll.bs.affix.data-api', $.proxy(this.checkPosition, this))
-      .on('click.bs.affix.data-api',  $.proxy(this.checkPositionWithEventLoop, this))
-
-    this.$element     = $(element)
-    this.affixed      = null
-    this.unpin        = null
-    this.pinnedOffset = null
-
-    this.checkPosition()
-  }
-
-  Affix.VERSION  = '3.3.5'
-
-  Affix.RESET    = 'affix affix-top affix-bottom'
-
-  Affix.DEFAULTS = {
-    offset: 0,
-    target: window
-  }
-
-  Affix.prototype.getState = function (scrollHeight, height, offsetTop, offsetBottom) {
-    var scrollTop    = this.$target.scrollTop()
-    var position     = this.$element.offset()
-    var targetHeight = this.$target.height()
-
-    if (offsetTop != null && this.affixed == 'top') return scrollTop < offsetTop ? 'top' : false
-
-    if (this.affixed == 'bottom') {
-      if (offsetTop != null) return (scrollTop + this.unpin <= position.top) ? false : 'bottom'
-      return (scrollTop + targetHeight <= scrollHeight - offsetBottom) ? false : 'bottom'
-    }
-
-    var initializing   = this.affixed == null
-    var colliderTop    = initializing ? scrollTop : position.top
-    var colliderHeight = initializing ? targetHeight : height
-
-    if (offsetTop != null && scrollTop <= offsetTop) return 'top'
-    if (offsetBottom != null && (colliderTop + colliderHeight >= scrollHeight - offsetBottom)) return 'bottom'
-
-    return false
-  }
-
-  Affix.prototype.getPinnedOffset = function () {
-    if (this.pinnedOffset) return this.pinnedOffset
-    this.$element.removeClass(Affix.RESET).addClass('affix')
-    var scrollTop = this.$target.scrollTop()
-    var position  = this.$element.offset()
-    return (this.pinnedOffset = position.top - scrollTop)
-  }
-
-  Affix.prototype.checkPositionWithEventLoop = function () {
-    setTimeout($.proxy(this.checkPosition, this), 1)
-  }
-
-  Affix.prototype.checkPosition = function () {
-    if (!this.$element.is(':visible')) return
-
-    var height       = this.$element.height()
-    var offset       = this.options.offset
-    var offsetTop    = offset.top
-    var offsetBottom = offset.bottom
-    var scrollHeight = Math.max($(document).height(), $(document.body).height())
-
-    if (typeof offset != 'object')         offsetBottom = offsetTop = offset
-    if (typeof offsetTop == 'function')    offsetTop    = offset.top(this.$element)
-    if (typeof offsetBottom == 'function') offsetBottom = offset.bottom(this.$element)
-
-    var affix = this.getState(scrollHeight, height, offsetTop, offsetBottom)
-
-    if (this.affixed != affix) {
-      if (this.unpin != null) this.$element.css('top', '')
-
-      var affixType = 'affix' + (affix ? '-' + affix : '')
-      var e         = $.Event(affixType + '.bs.affix')
-
-      this.$element.trigger(e)
-
-      if (e.isDefaultPrevented()) return
-
-      this.affixed = affix
-      this.unpin = affix == 'bottom' ? this.getPinnedOffset() : null
-
-      this.$element
-        .removeClass(Affix.RESET)
-        .addClass(affixType)
-        .trigger(affixType.replace('affix', 'affixed') + '.bs.affix')
-    }
-
-    if (affix == 'bottom') {
-      this.$element.offset({
-        top: scrollHeight - height - offsetBottom
-      })
-    }
-  }
-
-
-  // AFFIX PLUGIN DEFINITION
-  // =======================
-
-  function Plugin(option) {
-    return this.each(function () {
-      var $this   = $(this)
-      var data    = $this.data('bs.affix')
-      var options = typeof option == 'object' && option
-
-      if (!data) $this.data('bs.affix', (data = new Affix(this, options)))
-      if (typeof option == 'string') data[option]()
-    })
-  }
-
-  var old = $.fn.affix
-
-  $.fn.affix             = Plugin
-  $.fn.affix.Constructor = Affix
-
-
-  // AFFIX NO CONFLICT
-  // =================
-
-  $.fn.affix.noConflict = function () {
-    $.fn.affix = old
-    return this
-  }
-
-
-  // AFFIX DATA-API
-  // ==============
-
-  $(window).on('load', function () {
-    $('[data-spy="affix"]').each(function () {
-      var $spy = $(this)
-      var data = $spy.data()
-
-      data.offset = data.offset || {}
-
-      if (data.offsetBottom != null) data.offset.bottom = data.offsetBottom
-      if (data.offsetTop    != null) data.offset.top    = data.offsetTop
-
-      Plugin.call($spy, data)
-    })
-  })
-
-}(jQuery);
+/* ========================================================================
+ * Bootstrap: affix.js v3.3.5
+ * http://getbootstrap.com/javascript/#affix
+ * ========================================================================
+ * Copyright 2011-2015 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // AFFIX CLASS DEFINITION
+  // ======================
+
+  var Affix = function (element, options) {
+    this.options = $.extend({}, Affix.DEFAULTS, options)
+
+    this.$target = $(this.options.target)
+      .on('scroll.bs.affix.data-api', $.proxy(this.checkPosition, this))
+      .on('click.bs.affix.data-api',  $.proxy(this.checkPositionWithEventLoop, this))
+
+    this.$element     = $(element)
+    this.affixed      = null
+    this.unpin        = null
+    this.pinnedOffset = null
+
+    this.checkPosition()
+  }
+
+  Affix.VERSION  = '3.3.5'
+
+  Affix.RESET    = 'affix affix-top affix-bottom'
+
+  Affix.DEFAULTS = {
+    offset: 0,
+    target: window
+  }
+
+  Affix.prototype.getState = function (scrollHeight, height, offsetTop, offsetBottom) {
+    var scrollTop    = this.$target.scrollTop()
+    var position     = this.$element.offset()
+    var targetHeight = this.$target.height()
+
+    if (offsetTop != null && this.affixed == 'top') return scrollTop < offsetTop ? 'top' : false
+
+    if (this.affixed == 'bottom') {
+      if (offsetTop != null) return (scrollTop + this.unpin <= position.top) ? false : 'bottom'
+      return (scrollTop + targetHeight <= scrollHeight - offsetBottom) ? false : 'bottom'
+    }
+
+    var initializing   = this.affixed == null
+    var colliderTop    = initializing ? scrollTop : position.top
+    var colliderHeight = initializing ? targetHeight : height
+
+    if (offsetTop != null && scrollTop <= offsetTop) return 'top'
+    if (offsetBottom != null && (colliderTop + colliderHeight >= scrollHeight - offsetBottom)) return 'bottom'
+
+    return false
+  }
+
+  Affix.prototype.getPinnedOffset = function () {
+    if (this.pinnedOffset) return this.pinnedOffset
+    this.$element.removeClass(Affix.RESET).addClass('affix')
+    var scrollTop = this.$target.scrollTop()
+    var position  = this.$element.offset()
+    return (this.pinnedOffset = position.top - scrollTop)
+  }
+
+  Affix.prototype.checkPositionWithEventLoop = function () {
+    setTimeout($.proxy(this.checkPosition, this), 1)
+  }
+
+  Affix.prototype.checkPosition = function () {
+    if (!this.$element.is(':visible')) return
+
+    var height       = this.$element.height()
+    var offset       = this.options.offset
+    var offsetTop    = offset.top
+    var offsetBottom = offset.bottom
+    var scrollHeight = Math.max($(document).height(), $(document.body).height())
+
+    if (typeof offset != 'object')         offsetBottom = offsetTop = offset
+    if (typeof offsetTop == 'function')    offsetTop    = offset.top(this.$element)
+    if (typeof offsetBottom == 'function') offsetBottom = offset.bottom(this.$element)
+
+    var affix = this.getState(scrollHeight, height, offsetTop, offsetBottom)
+
+    if (this.affixed != affix) {
+      if (this.unpin != null) this.$element.css('top', '')
+
+      var affixType = 'affix' + (affix ? '-' + affix : '')
+      var e         = $.Event(affixType + '.bs.affix')
+
+      this.$element.trigger(e)
+
+      if (e.isDefaultPrevented()) return
+
+      this.affixed = affix
+      this.unpin = affix == 'bottom' ? this.getPinnedOffset() : null
+
+      this.$element
+        .removeClass(Affix.RESET)
+        .addClass(affixType)
+        .trigger(affixType.replace('affix', 'affixed') + '.bs.affix')
+    }
+
+    if (affix == 'bottom') {
+      this.$element.offset({
+        top: scrollHeight - height - offsetBottom
+      })
+    }
+  }
+
+
+  // AFFIX PLUGIN DEFINITION
+  // =======================
+
+  function Plugin(option) {
+    return this.each(function () {
+      var $this   = $(this)
+      var data    = $this.data('bs.affix')
+      var options = typeof option == 'object' && option
+
+      if (!data) $this.data('bs.affix', (data = new Affix(this, options)))
+      if (typeof option == 'string') data[option]()
+    })
+  }
+
+  var old = $.fn.affix
+
+  $.fn.affix             = Plugin
+  $.fn.affix.Constructor = Affix
+
+
+  // AFFIX NO CONFLICT
+  // =================
+
+  $.fn.affix.noConflict = function () {
+    $.fn.affix = old
+    return this
+  }
+
+
+  // AFFIX DATA-API
+  // ==============
+
+  $(window).on('load', function () {
+    $('[data-spy="affix"]').each(function () {
+      var $spy = $(this)
+      var data = $spy.data()
+
+      data.offset = data.offset || {}
+
+      if (data.offsetBottom != null) data.offset.bottom = data.offsetBottom
+      if (data.offsetTop    != null) data.offset.top    = data.offsetTop
+
+      Plugin.call($spy, data)
+    })
+  })
+
+}(jQuery);

source/_themes/clearlinux/static/js/project.js

@@ -1,70 +1,70 @@
-jQuery(document).ready(function($){
-
-  var classItem = $('.custom-dropdown-menu li.parent-item').attr('class');
-  if(classItem == 'menu-item-open parent-item') {
-    $('.custom-dropdown-menu li.parent-item a').append('<span class="fa fa-chevron-down"></span>');
-  } else {
-    $('.custom-dropdown-menu li.parent-item a').append('<span class="fa fa-chevron-up"></span>');
-  }
-
-  $('header .mobile-menu').click(function(){
-    $(this).parent().toggleClass('menu-open');
-    $('.o1-logo-container-mobile').toggleClass('menu-open');
-    $('body').toggleClass('menu-opened');
-  });
-
-  $('footer .mobile-menu').click(function(){
-    $(this).parent().toggleClass('menu-open');
-  });
-
-  $('#block-menu-menu-social-media, #block-menu-menu-get-involved').click(function(){
-    $(this).find('.menu').slideToggle();
-  });
-
-  $('.custom-dropdown-menu li.parent-item .fa').click(function(evt){
-   evt.stopPropagation();
-   $(this).toggleClass('fa-chevron-up fa-chevron-down');
-   $(this).closest('li').toggleClass('menu-item-closed menu-item-open');
-   return false;
-  });
-
-  $('div[id^=heading-]').click(function(){
-    var section = $(this).attr('id').replace('heading-', '');
-    $('#collapse-' + section).slideToggle();
-    $('#title-'+ section +' a i').toggleClass('fa-plus-square fa-minus-square');
-  });
-
-  $('header .mobile-menu').click(function(){
-    $(this).parent().toggleClass('menu-open');
-    $('.o1-logo-container-mobile').toggleClass('menu-open');
-    $('body').toggleClass('menu-opened');
-  });
-
-  $('footer .mobile-menu').click(function(){
-    $(this).parent().toggleClass('menu-open');
-  });
-
-  $('div[id^=heading-]').click(function(){
-    var section = $(this).attr('id').replace('heading-', '');
-    $('#collapse-' + section).slideToggle();
-    $('#title-'+ section +' a i').toggleClass('fa-plus-square fa-minus-square');
-  });
-
-  function onScroll(el) {
-    var $header = $('.project-header').first();
-    var scrollTop = $(el.currentTarget).scrollTop();
-
-    if (!$header.hasClass('scrolled') && scrollTop >= 200) {
-      $header.addClass('scrolled');
-    }
-
-    if ($header.hasClass('scrolled') && scrollTop < 200) {
-      $header.removeClass('scrolled');
-    }
-  }
-
-  //Animates logo on scroll
-  $('body, html').scroll(onScroll);
-  $(window).scroll(onScroll);
-
-});
+jQuery(document).ready(function($){
+
+  var classItem = $('.custom-dropdown-menu li.parent-item').attr('class');
+  if(classItem == 'menu-item-open parent-item') {
+    $('.custom-dropdown-menu li.parent-item a').append('<span class="fa fa-chevron-down"></span>');
+  } else {
+    $('.custom-dropdown-menu li.parent-item a').append('<span class="fa fa-chevron-up"></span>');
+  }
+
+  $('header .mobile-menu').click(function(){
+    $(this).parent().toggleClass('menu-open');
+    $('.o1-logo-container-mobile').toggleClass('menu-open');
+    $('body').toggleClass('menu-opened');
+  });
+
+  $('footer .mobile-menu').click(function(){
+    $(this).parent().toggleClass('menu-open');
+  });
+
+  $('#block-menu-menu-social-media, #block-menu-menu-get-involved').click(function(){
+    $(this).find('.menu').slideToggle();
+  });
+
+  $('.custom-dropdown-menu li.parent-item .fa').click(function(evt){
+   evt.stopPropagation();
+   $(this).toggleClass('fa-chevron-up fa-chevron-down');
+   $(this).closest('li').toggleClass('menu-item-closed menu-item-open');
+   return false;
+  });
+
+  $('div[id^=heading-]').click(function(){
+    var section = $(this).attr('id').replace('heading-', '');
+    $('#collapse-' + section).slideToggle();
+    $('#title-'+ section +' a i').toggleClass('fa-plus-square fa-minus-square');
+  });
+
+  $('header .mobile-menu').click(function(){
+    $(this).parent().toggleClass('menu-open');
+    $('.o1-logo-container-mobile').toggleClass('menu-open');
+    $('body').toggleClass('menu-opened');
+  });
+
+  $('footer .mobile-menu').click(function(){
+    $(this).parent().toggleClass('menu-open');
+  });
+
+  $('div[id^=heading-]').click(function(){
+    var section = $(this).attr('id').replace('heading-', '');
+    $('#collapse-' + section).slideToggle();
+    $('#title-'+ section +' a i').toggleClass('fa-plus-square fa-minus-square');
+  });
+
+  function onScroll(el) {
+    var $header = $('.project-header').first();
+    var scrollTop = $(el.currentTarget).scrollTop();
+
+    if (!$header.hasClass('scrolled') && scrollTop >= 200) {
+      $header.addClass('scrolled');
+    }
+
+    if ($header.hasClass('scrolled') && scrollTop < 200) {
+      $header.removeClass('scrolled');
+    }
+  }
+
+  //Animates logo on scroll
+  $('body, html').scroll(onScroll);
+  $(window).scroll(onScroll);
+
+});

source/_themes/clearlinux/static/js/theme.js

@@ -1,153 +1,153 @@
-require=(function e(t,n,r){function s(o,u){if(!n[o]){if(!t[o]){var a=typeof require=="function"&&require;if(!u&&a)return a(o,!0);if(i)return i(o,!0);var f=new Error("Cannot find module '"+o+"'");throw f.code="MODULE_NOT_FOUND",f}var l=n[o]={exports:{}};t[o][0].call(l.exports,function(e){var n=t[o][1][e];return s(n?n:e)},l,l.exports,e,t,n,r)}return n[o].exports}var i=typeof require=="function"&&require;for(var o=0;o<r.length;o++)s(r[o]);return s})({"sphinx-rtd-theme":[function(require,module,exports){
-var jQuery = (typeof(window) != 'undefined') ? window.jQuery : require('jquery');
-
-// Sphinx theme nav state
-function ThemeNav () {
-
-    var nav = {
-        navBar: null,
-        win: null,
-        winScroll: false,
-        winResize: false,
-        linkScroll: false,
-        winPosition: 0,
-        winHeight: null,
-        docHeight: null,
-        isRunning: null
-    };
-
-    nav.enable = function () {
-        var self = this;
-
-        jQuery(function ($) {
-            self.init($);
-
-            self.reset();
-            self.win.on('hashchange', self.reset);
-
-            // Set scroll monitor
-            self.win.on('scroll', function () {
-                if (!self.linkScroll) {
-                    self.winScroll = true;
-                }
-            });
-            setInterval(function () { if (self.winScroll) self.onScroll(); }, 25);
-
-            // Set resize monitor
-            self.win.on('resize', function () {
-                self.winResize = true;
-            });
-            setInterval(function () { if (self.winResize) self.onResize(); }, 25);
-            self.onResize();
-        });
-    };
-
-    nav.init = function ($) {
-        var doc = $(document),
-            self = this;
-
-        this.navBar = $('div.wy-side-scroll:first');
-        this.win = $(window);
-
-        // Set up javascript UX bits
-        $(document)
-            // Shift nav in mobile when clicking the menu.
-            .on('click', "[data-toggle='wy-nav-top']", function() {
-                $("[data-toggle='wy-nav-shift']").toggleClass("shift");
-                $("[data-toggle='rst-versions']").toggleClass("shift");
-            })
-
-            // Nav menu link click operations
-            .on('click', ".wy-menu-vertical .current ul li a", function() {
-                var target = $(this);
-                // Close menu when you click a link.
-                $("[data-toggle='wy-nav-shift']").removeClass("shift");
-                $("[data-toggle='rst-versions']").toggleClass("shift");
-                // Handle dynamic display of l3 and l4 nav lists
-                self.toggleCurrent(target);
-                self.hashChange();
-            })
-            .on('click', "[data-toggle='rst-current-version']", function() {
-                $("[data-toggle='rst-versions']").toggleClass("shift-up");
-            })
-
-        // Make tables responsive
-        $("table.docutils:not(.field-list)")
-            .wrap("<div class='wy-table-responsive'></div>");
-
-        // Add expand links to all parents of nested ul
-        $('.wy-menu-vertical ul').not('.simple').siblings('a').each(function () {
-            var link = $(this);
-                expand = $('<span class="toctree-expand"></span>');
-            expand.on('click', function (ev) {
-                self.toggleCurrent(link);
-                ev.stopPropagation();
-                return false;
-            });
-            link.prepend(expand);
-        });
-    };
-
-    nav.reset = function () {
-        // Get anchor from URL and open up nested nav
-        var anchor = encodeURI(window.location.hash);
-        if (anchor) {
-            try {
-                var link = $('.wy-menu-vertical')
-                    .find('[href="' + anchor + '"]');
-                $('.wy-menu-vertical li.toctree-l1 li.current')
-                    .removeClass('current');
-                link.closest('li.toctree-l2').addClass('current');
-                link.closest('li.toctree-l3').addClass('current');
-                link.closest('li.toctree-l4').addClass('current');
-            }
-            catch (err) {
-                console.log("Error expanding nav for anchor", err);
-            }
-        }
-    };
-
-    nav.onScroll = function () {
-        this.winScroll = false;
-        var newWinPosition = this.win.scrollTop(),
-            winBottom = newWinPosition + this.winHeight,
-            navPosition = this.navBar.scrollTop(),
-            newNavPosition = navPosition + (newWinPosition - this.winPosition);
-        if (newWinPosition < 0 || winBottom > this.docHeight) {
-            return;
-        }
-        this.navBar.scrollTop(newNavPosition);
-        this.winPosition = newWinPosition;
-    };
-
-    nav.onResize = function () {
-        this.winResize = false;
-        this.winHeight = this.win.height();
-        this.docHeight = $(document).height();
-    };
-
-    nav.hashChange = function () {
-        this.linkScroll = true;
-        this.win.one('hashchange', function () {
-            this.linkScroll = false;
-        });
-    };
-
-    nav.toggleCurrent = function (elem) {
-        var parent_li = elem.closest('li');
-        parent_li.siblings('li.current').removeClass('current');
-        parent_li.siblings().find('li.current').removeClass('current');
-        parent_li.find('> ul li.current').removeClass('current');
-        parent_li.toggleClass('current');
-    }
-
-    return nav;
-};
-
-module.exports.ThemeNav = ThemeNav();
-
-if (typeof(window) != 'undefined') {
-    window.SphinxRtdTheme = { StickyNav: module.exports.ThemeNav };
-}
-
-},{"jquery":"jquery"}]},{},["sphinx-rtd-theme"]);
+require=(function e(t,n,r){function s(o,u){if(!n[o]){if(!t[o]){var a=typeof require=="function"&&require;if(!u&&a)return a(o,!0);if(i)return i(o,!0);var f=new Error("Cannot find module '"+o+"'");throw f.code="MODULE_NOT_FOUND",f}var l=n[o]={exports:{}};t[o][0].call(l.exports,function(e){var n=t[o][1][e];return s(n?n:e)},l,l.exports,e,t,n,r)}return n[o].exports}var i=typeof require=="function"&&require;for(var o=0;o<r.length;o++)s(r[o]);return s})({"sphinx-rtd-theme":[function(require,module,exports){
+var jQuery = (typeof(window) != 'undefined') ? window.jQuery : require('jquery');
+
+// Sphinx theme nav state
+function ThemeNav () {
+
+    var nav = {
+        navBar: null,
+        win: null,
+        winScroll: false,
+        winResize: false,
+        linkScroll: false,
+        winPosition: 0,
+        winHeight: null,
+        docHeight: null,
+        isRunning: null
+    };
+
+    nav.enable = function () {
+        var self = this;
+
+        jQuery(function ($) {
+            self.init($);
+
+            self.reset();
+            self.win.on('hashchange', self.reset);
+
+            // Set scroll monitor
+            self.win.on('scroll', function () {
+                if (!self.linkScroll) {
+                    self.winScroll = true;
+                }
+            });
+            setInterval(function () { if (self.winScroll) self.onScroll(); }, 25);
+
+            // Set resize monitor
+            self.win.on('resize', function () {
+                self.winResize = true;
+            });
+            setInterval(function () { if (self.winResize) self.onResize(); }, 25);
+            self.onResize();
+        });
+    };
+
+    nav.init = function ($) {
+        var doc = $(document),
+            self = this;
+
+        this.navBar = $('div.wy-side-scroll:first');
+        this.win = $(window);
+
+        // Set up javascript UX bits
+        $(document)
+            // Shift nav in mobile when clicking the menu.
+            .on('click', "[data-toggle='wy-nav-top']", function() {
+                $("[data-toggle='wy-nav-shift']").toggleClass("shift");
+                $("[data-toggle='rst-versions']").toggleClass("shift");
+            })
+
+            // Nav menu link click operations
+            .on('click', ".wy-menu-vertical .current ul li a", function() {
+                var target = $(this);
+                // Close menu when you click a link.
+                $("[data-toggle='wy-nav-shift']").removeClass("shift");
+                $("[data-toggle='rst-versions']").toggleClass("shift");
+                // Handle dynamic display of l3 and l4 nav lists
+                self.toggleCurrent(target);
+                self.hashChange();
+            })
+            .on('click', "[data-toggle='rst-current-version']", function() {
+                $("[data-toggle='rst-versions']").toggleClass("shift-up");
+            })
+
+        // Make tables responsive
+        $("table.docutils:not(.field-list)")
+            .wrap("<div class='wy-table-responsive'></div>");
+
+        // Add expand links to all parents of nested ul
+        $('.wy-menu-vertical ul').not('.simple').siblings('a').each(function () {
+            var link = $(this);
+                expand = $('<span class="toctree-expand"></span>');
+            expand.on('click', function (ev) {
+                self.toggleCurrent(link);
+                ev.stopPropagation();
+                return false;
+            });
+            link.prepend(expand);
+        });
+    };
+
+    nav.reset = function () {
+        // Get anchor from URL and open up nested nav
+        var anchor = encodeURI(window.location.hash);
+        if (anchor) {
+            try {
+                var link = $('.wy-menu-vertical')
+                    .find('[href="' + anchor + '"]');
+                $('.wy-menu-vertical li.toctree-l1 li.current')
+                    .removeClass('current');
+                link.closest('li.toctree-l2').addClass('current');
+                link.closest('li.toctree-l3').addClass('current');
+                link.closest('li.toctree-l4').addClass('current');
+            }
+            catch (err) {
+                console.log("Error expanding nav for anchor", err);
+            }
+        }
+    };
+
+    nav.onScroll = function () {
+        this.winScroll = false;
+        var newWinPosition = this.win.scrollTop(),
+            winBottom = newWinPosition + this.winHeight,
+            navPosition = this.navBar.scrollTop(),
+            newNavPosition = navPosition + (newWinPosition - this.winPosition);
+        if (newWinPosition < 0 || winBottom > this.docHeight) {
+            return;
+        }
+        this.navBar.scrollTop(newNavPosition);
+        this.winPosition = newWinPosition;
+    };
+
+    nav.onResize = function () {
+        this.winResize = false;
+        this.winHeight = this.win.height();
+        this.docHeight = $(document).height();
+    };
+
+    nav.hashChange = function () {
+        this.linkScroll = true;
+        this.win.one('hashchange', function () {
+            this.linkScroll = false;
+        });
+    };
+
+    nav.toggleCurrent = function (elem) {
+        var parent_li = elem.closest('li');
+        parent_li.siblings('li.current').removeClass('current');
+        parent_li.siblings().find('li.current').removeClass('current');
+        parent_li.find('> ul li.current').removeClass('current');
+        parent_li.toggleClass('current');
+    }
+
+    return nav;
+};
+
+module.exports.ThemeNav = ThemeNav();
+
+if (typeof(window) != 'undefined') {
+    window.SphinxRtdTheme = { StickyNav: module.exports.ThemeNav };
+}
+
+},{"jquery":"jquery"}]},{},["sphinx-rtd-theme"]);

source/_themes/clearlinux/support.py

@@ -1,86 +1,86 @@
-from pygments.style import Style
-from pygments.token import Keyword, Name, Comment, String, Error, \
-     Number, Operator, Generic, Whitespace, Punctuation, Other, Literal
-
-
-# Originally based on FlaskyStyle which was based on 'tango'.
-class Alabaster(Style):
-    background_color = "#f8f8f8" # doesn't seem to override CSS 'pre' styling?
-    default_style = ""
-
-    styles = {
-        # No corresponding class for the following:
-        #Text:                     "", # class:  ''
-        Whitespace:                "underline #f8f8f8",      # class: 'w'
-        Error:                     "#a40000 border:#ef2929", # class: 'err'
-        Other:                     "#000000",                # class 'x'
-
-        Comment:                   "italic #8f5902", # class: 'c'
-        Comment.Preproc:           "noitalic",       # class: 'cp'
-
-        Keyword:                   "bold #004461",   # class: 'k'
-        Keyword.Constant:          "bold #004461",   # class: 'kc'
-        Keyword.Declaration:       "bold #004461",   # class: 'kd'
-        Keyword.Namespace:         "bold #004461",   # class: 'kn'
-        Keyword.Pseudo:            "bold #004461",   # class: 'kp'
-        Keyword.Reserved:          "bold #004461",   # class: 'kr'
-        Keyword.Type:              "bold #004461",   # class: 'kt'
-
-        Operator:                  "#582800",   # class: 'o'
-        Operator.Word:             "bold #004461",   # class: 'ow' - like keywords
-
-        Punctuation:               "bold #000000",   # class: 'p'
-
-        # because special names such as Name.Class, Name.Function, etc.
-        # are not recognized as such later in the parsing, we choose them
-        # to look the same as ordinary variables.
-        Name:                      "#000000",        # class: 'n'
-        Name.Attribute:            "#c4a000",        # class: 'na' - to be revised
-        Name.Builtin:              "#004461",        # class: 'nb'
-        Name.Builtin.Pseudo:       "#3465a4",        # class: 'bp'
-        Name.Class:                "#000000",        # class: 'nc' - to be revised
-        Name.Constant:             "#000000",        # class: 'no' - to be revised
-        Name.Decorator:            "#888",           # class: 'nd' - to be revised
-        Name.Entity:               "#ce5c00",        # class: 'ni'
-        Name.Exception:            "bold #cc0000",   # class: 'ne'
-        Name.Function:             "#000000",        # class: 'nf'
-        Name.Property:             "#000000",        # class: 'py'
-        Name.Label:                "#f57900",        # class: 'nl'
-        Name.Namespace:            "#000000",        # class: 'nn' - to be revised
-        Name.Other:                "#000000",        # class: 'nx'
-        Name.Tag:                  "bold #004461",   # class: 'nt' - like a keyword
-        Name.Variable:             "#000000",        # class: 'nv' - to be revised
-        Name.Variable.Class:       "#000000",        # class: 'vc' - to be revised
-        Name.Variable.Global:      "#000000",        # class: 'vg' - to be revised
-        Name.Variable.Instance:    "#000000",        # class: 'vi' - to be revised
-
-        Number:                    "#990000",        # class: 'm'
-
-        Literal:                   "#000000",        # class: 'l'
-        Literal.Date:              "#000000",        # class: 'ld'
-
-        String:                    "#4e9a06",        # class: 's'
-        String.Backtick:           "#4e9a06",        # class: 'sb'
-        String.Char:               "#4e9a06",        # class: 'sc'
-        String.Doc:                "italic #8f5902", # class: 'sd' - like a comment
-        String.Double:             "#4e9a06",        # class: 's2'
-        String.Escape:             "#4e9a06",        # class: 'se'
-        String.Heredoc:            "#4e9a06",        # class: 'sh'
-        String.Interpol:           "#4e9a06",        # class: 'si'
-        String.Other:              "#4e9a06",        # class: 'sx'
-        String.Regex:              "#4e9a06",        # class: 'sr'
-        String.Single:             "#4e9a06",        # class: 's1'
-        String.Symbol:             "#4e9a06",        # class: 'ss'
-
-        Generic:                   "#000000",        # class: 'g'
-        Generic.Deleted:           "#a40000",        # class: 'gd'
-        Generic.Emph:              "italic #000000", # class: 'ge'
-        Generic.Error:             "#ef2929",        # class: 'gr'
-        Generic.Heading:           "bold #000080",   # class: 'gh'
-        Generic.Inserted:          "#00A000",        # class: 'gi'
-        Generic.Output:            "#888",           # class: 'go'
-        Generic.Prompt:            "#745334",        # class: 'gp'
-        Generic.Strong:            "bold #000000",   # class: 'gs'
-        Generic.Subheading:        "bold #800080",   # class: 'gu'
-        Generic.Traceback:         "bold #a40000",   # class: 'gt'
-    }
+from pygments.style import Style
+from pygments.token import Keyword, Name, Comment, String, Error, \
+     Number, Operator, Generic, Whitespace, Punctuation, Other, Literal
+
+
+# Originally based on FlaskyStyle which was based on 'tango'.
+class Alabaster(Style):
+    background_color = "#f8f8f8" # doesn't seem to override CSS 'pre' styling?
+    default_style = ""
+
+    styles = {
+        # No corresponding class for the following:
+        #Text:                     "", # class:  ''
+        Whitespace:                "underline #f8f8f8",      # class: 'w'
+        Error:                     "#a40000 border:#ef2929", # class: 'err'
+        Other:                     "#000000",                # class 'x'
+
+        Comment:                   "italic #8f5902", # class: 'c'
+        Comment.Preproc:           "noitalic",       # class: 'cp'
+
+        Keyword:                   "bold #004461",   # class: 'k'
+        Keyword.Constant:          "bold #004461",   # class: 'kc'
+        Keyword.Declaration:       "bold #004461",   # class: 'kd'
+        Keyword.Namespace:         "bold #004461",   # class: 'kn'
+        Keyword.Pseudo:            "bold #004461",   # class: 'kp'
+        Keyword.Reserved:          "bold #004461",   # class: 'kr'
+        Keyword.Type:              "bold #004461",   # class: 'kt'
+
+        Operator:                  "#582800",   # class: 'o'
+        Operator.Word:             "bold #004461",   # class: 'ow' - like keywords
+
+        Punctuation:               "bold #000000",   # class: 'p'
+
+        # because special names such as Name.Class, Name.Function, etc.
+        # are not recognized as such later in the parsing, we choose them
+        # to look the same as ordinary variables.
+        Name:                      "#000000",        # class: 'n'
+        Name.Attribute:            "#c4a000",        # class: 'na' - to be revised
+        Name.Builtin:              "#004461",        # class: 'nb'
+        Name.Builtin.Pseudo:       "#3465a4",        # class: 'bp'
+        Name.Class:                "#000000",        # class: 'nc' - to be revised
+        Name.Constant:             "#000000",        # class: 'no' - to be revised
+        Name.Decorator:            "#888",           # class: 'nd' - to be revised
+        Name.Entity:               "#ce5c00",        # class: 'ni'
+        Name.Exception:            "bold #cc0000",   # class: 'ne'
+        Name.Function:             "#000000",        # class: 'nf'
+        Name.Property:             "#000000",        # class: 'py'
+        Name.Label:                "#f57900",        # class: 'nl'
+        Name.Namespace:            "#000000",        # class: 'nn' - to be revised
+        Name.Other:                "#000000",        # class: 'nx'
+        Name.Tag:                  "bold #004461",   # class: 'nt' - like a keyword
+        Name.Variable:             "#000000",        # class: 'nv' - to be revised
+        Name.Variable.Class:       "#000000",        # class: 'vc' - to be revised
+        Name.Variable.Global:      "#000000",        # class: 'vg' - to be revised
+        Name.Variable.Instance:    "#000000",        # class: 'vi' - to be revised
+
+        Number:                    "#990000",        # class: 'm'
+
+        Literal:                   "#000000",        # class: 'l'
+        Literal.Date:              "#000000",        # class: 'ld'
+
+        String:                    "#4e9a06",        # class: 's'
+        String.Backtick:           "#4e9a06",        # class: 'sb'
+        String.Char:               "#4e9a06",        # class: 'sc'
+        String.Doc:                "italic #8f5902", # class: 'sd' - like a comment
+        String.Double:             "#4e9a06",        # class: 's2'
+        String.Escape:             "#4e9a06",        # class: 'se'
+        String.Heredoc:            "#4e9a06",        # class: 'sh'
+        String.Interpol:           "#4e9a06",        # class: 'si'
+        String.Other:              "#4e9a06",        # class: 'sx'
+        String.Regex:              "#4e9a06",        # class: 'sr'
+        String.Single:             "#4e9a06",        # class: 's1'
+        String.Symbol:             "#4e9a06",        # class: 'ss'
+
+        Generic:                   "#000000",        # class: 'g'
+        Generic.Deleted:           "#a40000",        # class: 'gd'
+        Generic.Emph:              "italic #000000", # class: 'ge'
+        Generic.Error:             "#ef2929",        # class: 'gr'
+        Generic.Heading:           "bold #000080",   # class: 'gh'
+        Generic.Inserted:          "#00A000",        # class: 'gi'
+        Generic.Output:            "#888",           # class: 'go'
+        Generic.Prompt:            "#745334",        # class: 'gp'
+        Generic.Strong:            "bold #000000",   # class: 'gs'
+        Generic.Subheading:        "bold #800080",   # class: 'gu'
+        Generic.Traceback:         "bold #a40000",   # class: 'gt'
+    }

source/_themes/clearlinux/theme.conf

@@ -1,3 +1,3 @@
-[theme]
-inherit = basic
-stylesheet = css/main.css
+[theme]
+inherit = basic
+stylesheet = css/main.css

source/advanced/bulk-provisioning.rst

@@ -1,146 +1,146 @@
-.. _bulk_provisioning:
-
-Bulk Provisioning
-=================
-
-Data centers tend to land and install new machines in bulk. When dealing with
-large quantities of new machines or hardware upgrades, data center admins may need
-a way to install and configure with a minimal amount of effort. To support this 
-use case, the Clear Linux team has developed some tooling and instructions for
-how to bulk-load machines with Clear Linux using iPXE.
-
-This bulk provisioning scenario is a variation on the :ref:`network_boot` scenario, 
-with some alterations to facilitate installing and configuring many hosts. The Clear 
-Linux installer (``Ister``) was augmented to detect and find ``cloud-init`` configuration 
-data during the install. When this data is found, a :file:`cloud-init` file is fetched, 
-and the host, after being rebooted by ``ister``, uses micro-config drive (``ucf``) to
-configure the host as directed by the :file:`cloud-init` configuration file.
-
-In our pilot of this workflow, we used ``clear-cloud-init`` (which will become ucf - micro config drive) 
-to install the trust relationships for the host to be further managed by Ansible. The 
-:file:`cloud-init` configuration file was served by a simple little web application 
-that ``Ister`` knows how to query for host configuration data. This allowed us to 
-simultaneously power-on one hundred machines, each of which 
-* picked up the Clear Linux installer via PXE, 
-* installed Clear Linux, 
-* rebooted, and 
-* entered into a mode that can be managed through Ansible.
-
-The web application that serves cloud-init configurations to ``Ister`` is uninspiringly named 
-"Ister Cloud Init Service" (ICIS), and is available at github - https://github.com/clearlinux/ister-cloud-init-svc
-
-One nice attribute of this system is that once the iPXE bits are created, many installer 
-behaviors can be configured without having to regenerate the iPXE bits.
-
-System Architecture
-~~~~~~~~~~~~~~~~~~~
-
-The following diagrams illustrate the system architecture.
-
-.. image:: _static/images/icis_pxe_diagram.png
-    :align: center
-    :alt: pxe-server-overview
-
-As can be seen, ICIS is a web application (specifically a Flask application, hence managed by ``uwsgi`` 
-under nginx) that can run **anywhere** visible to hosts booting from PXE. In our example, we simply 
-hosted it on the same system serving the pxe content.
-
-The following diagram illustrates the flow of information between the pxe server and a host booting 
-into the installer via pxe. This diagram is intended to show the logical flow of information, and 
-is not a literal depiction of the protocol-level exchanges.
-
-.. image:: _static/images/icis_installer_workflow.png
-    :align: center
-    :alt: pxe-icis-install-workflow
-
-Configuration Overview
-~~~~~~~~~~~~~~~~~~~~~~
-
-Here is a high-level overview describing set up and configuration of a bulk-provisioning solution.
-
-* First, stand up an iPXE server as described in the :ref:`network_boot` docs. Note that you will
-  be generating your own artifacts to be served by PXE in a later step.
-
-* Land `Ister Cloud Init Service <https://github.com/clearlinux/ister-cloud-init-svc>`_ on the 
-  pxe server. The README in the ICIS github repo has directions on how to install and configure.
-
-* Generate the installer that will load and boot over PXE. Copy the relevant files into the 
-  appropriate location on the iPXE server.
-
-  A pxe installer is generated for every release of Clear Linux OS. It can be found alongside the 
-  published images in https://download.clearlinux.org/releases/XXXXX/clear/clear-XXXXX-pxe.tar.xz
-
-  Alternatively, use the `create_pxe.sh <https://github.com/bryteise/ister/blob/master/create_pxe.sh>`_ 
-  script to roll your own. Note this creates the pxe-installer from the "provisioning" installer in 
-  Clear Linux.  This is a touchless installer that takes all installation information from a config 
-  file. You can get this image from a given Clear Linux release by looking 
-  in https://download.clearlinux.org/releases/XXXX/clear/ where XXXX is a Clear Linux release number. 
-  Just download the image alongside the ``create_pxe.sh`` script and name it ``provision.img``.
-
-* Stage config files for ``ister`` that will govern Ister's behavior. This includes modifying the 
-  script for ipxe boot, getting it to pass an additional parameter to the kernel.
-
-  The magic that ties all of this together is that the pxe script conveys to ister the location of its configuration files via the kernel command line of the installer it kicks off. The kernel preserves its command line precisely, and ister inspects it via ``/proc/cmdline``.
-
-  Here is an example pxe script:
-
-  .. code-block:: console
-
-    #!ipxe
-    kernel linux quiet rdinit=/usr/lib/systemd/systemd-bootchart initcall_debug tsc=reliable 
-    no_timer_check noreplace-smp rw initrd=initrd isterconf=http://192.168.1.1/icis/static/ister/ister.conf
-    initrd initrd
-    boot
-
-  When the pxe installer kicks off ``ister``, it will make note of the location of the ``conf`` file 
-  that was given on the kernel command line, and fetch the file. This file then tells ``ister`` where 
-  to get the json template file that describes partition schemes, and which version of Clear Linux to 
-  install. This means that so long as the contents of a release are compatible with the version of 
-  software update (``swupd``) in the installer, this pxe installer can be told to install a newer 
-  version of Clear Linux simply by tweaking the json on the web server, rather than rolling an 
-  entirely new installer.
-
-  One other important piece of configuration data in the json configuration file is the location of 
-  an ICIS configuration service. Ister will query ICIS for a role using the MAC address of the network 
-  interface being used to communicate with the ICIS service. Ister will then fetch that specific 
-  :file:`cloud-init` file and ``configure ucd`` to run on first-boot against that config file.
-
-  The `Ister Cloud Init Service <https://github.com/clearlinux/ister-cloud-init-svc>`_ github repo 
-  has example ister configuration files under ``static/ister``.
-
-  Here is an example ister-template.json file.
-
-  .. code-block:: console
-
-    {
-      "DestinationType" : "phyiscal",
-      "PartitionLayout" : [ { "disk" : "/dev/sda", "partition" : 1,
-                              "size" : "64M", "type" : "EFI" },
-                            { "disk" : "/dev/sda", "partition" : 2,
-                              "size" : "2G", "type" : "linux" } ],
-      "FilesystemTypes" : [ { "disk" : "/dev/sda", "partition" : 1, "type" : "vfat" },
-                            { "disk" : "/dev/sda", "partition" : 2, "type" : "ext4" } ],
-      "PartitionMountPoints" : [ { "disk" : "/dev/sda", "partition" : 1,
-                                   "mount" : "/boot" },
-                                 { "disk" : "/dev/sda", "partition" : 2,
-                                   "mount" : "/" } ],
-      "Version": 6580,
-      "Bundles": ["kernel-native", "os-core-update", "os-core",
-                  "bootloader", "sysadmin-hostmgmt", "openssh-server"],
-      "PostNonChroot": ["./installation-image-post-update-version.py"],
-      "IsterCloudInitSvc": ["http://192.168.1.1/icis/"]
-    }
-
-* Configure ICIS to map MAC addresses to role files appropriately. Then create the role files, which 
-  are ``cloud-init`` configuration files. Note, it is possible to simply specify a "default" role for 
-  any unmatched MAC address; this may be handy when all install targets are to be configured identically.
-
-* Final pre-flight check. Assuming your iPXE server is at 192.168.1.1, all of the following urls need to be working.
-
-  - http://192.168.1.1/icis/static/ister/ister.conf
-  - http://192.168.1.1/icis/static/ister/ister_config.json
-  - http://192.168.1.1/icis/get_config/<MAC ADDR>
-  - http://192.168.1.1/icis/get_role/<role returned from previous url>
-  - http://192.168.1.1/ipxe_boot_script.txt
-
-* Boot an iPXE client and watch Clear Linux install.
+.. _bulk_provisioning:
+
+Bulk Provisioning
+=================
+
+Data centers tend to land and install new machines in bulk. When dealing with
+large quantities of new machines or hardware upgrades, data center admins may need
+a way to install and configure with a minimal amount of effort. To support this
+use case, the Clear Linux team has developed some tooling and instructions for
+how to bulk-load machines with Clear Linux using iPXE.
+
+This bulk provisioning scenario is a variation on the :ref:`network_boot` scenario,
+with some alterations to facilitate installing and configuring many hosts. The Clear
+Linux installer (``Ister``) was augmented to detect and find ``cloud-init`` configuration
+data during the install. When this data is found, a :file:`cloud-init` file is fetched,
+and the host, after being rebooted by ``ister``, uses micro-config drive (``ucf``) to
+configure the host as directed by the :file:`cloud-init` configuration file.
+
+In our pilot of this workflow, we used ``clear-cloud-init`` (which will become ucf - micro config drive)
+to install the trust relationships for the host to be further managed by Ansible. The
+:file:`cloud-init` configuration file was served by a simple little web application
+that ``Ister`` knows how to query for host configuration data. This allowed us to
+simultaneously power-on one hundred machines, each of which
+* picked up the Clear Linux installer via PXE,
+* installed Clear Linux,
+* rebooted, and
+* entered into a mode that can be managed through Ansible.
+
+The web application that serves cloud-init configurations to ``Ister`` is uninspiringly named
+"Ister Cloud Init Service" (ICIS), and is available at github - https://github.com/clearlinux/ister-cloud-init-svc
+
+One nice attribute of this system is that once the iPXE bits are created, many installer
+behaviors can be configured without having to regenerate the iPXE bits.
+
+System Architecture
+~~~~~~~~~~~~~~~~~~~
+
+The following diagrams illustrate the system architecture.
+
+.. image:: ../_static/images/advanced/icis_pxe_diagram.png
+    :align: center
+    :alt: pxe-server-overview
+
+As can be seen, ICIS is a web application (specifically a Flask application, hence managed by ``uwsgi``
+under nginx) that can run **anywhere** visible to hosts booting from PXE. In our example, we simply
+hosted it on the same system serving the pxe content.
+
+The following diagram illustrates the flow of information between the pxe server and a host booting
+into the installer via pxe. This diagram is intended to show the logical flow of information, and
+is not a literal depiction of the protocol-level exchanges.
+
+.. image:: ../_static/images/advanced/icis_installer_workflow.png
+    :align: center
+    :alt: pxe-icis-install-workflow
+
+Configuration Overview
+~~~~~~~~~~~~~~~~~~~~~~
+
+Here is a high-level overview describing set up and configuration of a bulk-provisioning solution.
+
+* First, stand up an iPXE server as described in the :ref:`network_boot` docs. Note that you will
+  be generating your own artifacts to be served by PXE in a later step.
+
+* Land `Ister Cloud Init Service <https://github.com/clearlinux/ister-cloud-init-svc>`_ on the
+  pxe server. The README in the ICIS github repo has directions on how to install and configure.
+
+* Generate the installer that will load and boot over PXE. Copy the relevant files into the
+  appropriate location on the iPXE server.
+
+  A pxe installer is generated for every release of Clear Linux OS. It can be found alongside the
+  published images in https://download.clearlinux.org/releases/XXXXX/clear/clear-XXXXX-pxe.tar.xz
+
+  Alternatively, use the `create_pxe.sh <https://github.com/bryteise/ister/blob/master/create_pxe.sh>`_
+  script to roll your own. Note this creates the pxe-installer from the "provisioning" installer in
+  Clear Linux.  This is a touchless installer that takes all installation information from a config
+  file. You can get this image from a given Clear Linux release by looking
+  in https://download.clearlinux.org/releases/XXXX/clear/ where XXXX is a Clear Linux release number.
+  Just download the image alongside the ``create_pxe.sh`` script and name it ``provision.img``.
+
+* Stage config files for ``ister`` that will govern Ister's behavior. This includes modifying the
+  script for ipxe boot, getting it to pass an additional parameter to the kernel.
+
+  The magic that ties all of this together is that the pxe script conveys to ister the location of its configuration files via the kernel command line of the installer it kicks off. The kernel preserves its command line precisely, and ister inspects it via ``/proc/cmdline``.
+
+  Here is an example pxe script:
+
+  .. code-block:: console
+
+    #!ipxe
+    kernel linux quiet rdinit=/usr/lib/systemd/systemd-bootchart initcall_debug tsc=reliable
+    no_timer_check noreplace-smp rw initrd=initrd isterconf=http://192.168.1.1/icis/static/ister/ister.conf
+    initrd initrd
+    boot
+
+  When the pxe installer kicks off ``ister``, it will make note of the location of the ``conf`` file
+  that was given on the kernel command line, and fetch the file. This file then tells ``ister`` where
+  to get the json template file that describes partition schemes, and which version of Clear Linux to
+  install. This means that so long as the contents of a release are compatible with the version of
+  software update (``swupd``) in the installer, this pxe installer can be told to install a newer
+  version of Clear Linux simply by tweaking the json on the web server, rather than rolling an
+  entirely new installer.
+
+  One other important piece of configuration data in the json configuration file is the location of
+  an ICIS configuration service. Ister will query ICIS for a role using the MAC address of the network
+  interface being used to communicate with the ICIS service. Ister will then fetch that specific
+  :file:`cloud-init` file and ``configure ucd`` to run on first-boot against that config file.
+
+  The `Ister Cloud Init Service <https://github.com/clearlinux/ister-cloud-init-svc>`_ github repo
+  has example ister configuration files under ``static/ister``.
+
+  Here is an example ister-template.json file.
+
+  .. code-block:: console
+
+    {
+      "DestinationType" : "phyiscal",
+      "PartitionLayout" : [ { "disk" : "/dev/sda", "partition" : 1,
+                              "size" : "64M", "type" : "EFI" },
+                            { "disk" : "/dev/sda", "partition" : 2,
+                              "size" : "2G", "type" : "linux" } ],
+      "FilesystemTypes" : [ { "disk" : "/dev/sda", "partition" : 1, "type" : "vfat" },
+                            { "disk" : "/dev/sda", "partition" : 2, "type" : "ext4" } ],
+      "PartitionMountPoints" : [ { "disk" : "/dev/sda", "partition" : 1,
+                                   "mount" : "/boot" },
+                                 { "disk" : "/dev/sda", "partition" : 2,
+                                   "mount" : "/" } ],
+      "Version": 6580,
+      "Bundles": ["kernel-native", "os-core-update", "os-core",
+                  "bootloader", "sysadmin-hostmgmt", "openssh-server"],
+      "PostNonChroot": ["./installation-image-post-update-version.py"],
+      "IsterCloudInitSvc": ["http://192.168.1.1/icis/"]
+    }
+
+* Configure ICIS to map MAC addresses to role files appropriately. Then create the role files, which
+  are ``cloud-init`` configuration files. Note, it is possible to simply specify a "default" role for
+  any unmatched MAC address; this may be handy when all install targets are to be configured identically.
+
+* Final pre-flight check. Assuming your iPXE server is at 192.168.1.1, all of the following urls need to be working.
+
+  - http://192.168.1.1/icis/static/ister/ister.conf
+  - http://192.168.1.1/icis/static/ister/ister_config.json
+  - http://192.168.1.1/icis/get_config/<MAC ADDR>
+  - http://192.168.1.1/icis/get_role/<role returned from previous url>
+  - http://192.168.1.1/ipxe_boot_script.txt
+
+* Boot an iPXE client and watch Clear Linux install.

source/advanced/clear-containers.rst

@@ -1,439 +1,439 @@
-.. _clear_containers.rst:
-
-Intel® Clear Containers
-#######################
-
-Introduction
-============
-
-Intel® Clear Containers is a collection of tools, configurations,
-and techniques anchored on an implementation that leverages Intel® 
-Architecture to optimize container launching and execution workflow. 
-These optimizations improve speed, size, and efficiency while offering 
-a number of benefits that can be derived only from hardware-backed 
-virtual machines (hardware-enforced isolation and security, for 
-example) on Intel® VT technology.
-
-These methods are applied across all levels of the host/virtual machine
-hierarchy: from the host-side userland software stack down through the host
-Linux* kernel, and into the client-side kernel and userland. 
-
-Although it is available as a standalone offering, the Clear Containers
-technology works best when it is able to leverage optimizations designed
-into the Clear Linux Project.
-
-Customers can integrate all or parts of Intel Clear Containers into a
-container infrastructure.
-
-.. _architecture_overview.rst:
-
-Architecture Overview
-=====================
-
-Intel Clear Containers are architected around the Linux 
-:abbr:`Kernel Virtual Machine (KVM)` virtualization infrastructure to
-make best use of Intel Architecture VT features. Operational speed
-gets improved and overhead gets reduced by optimizing existing code,
-removing redundant components, and implementing new techniques for
-containers with :abbr:`KVM (Kernel Virtual Machine)`.
-
-Version 1.0 of Clear Containers was designed as a lightweight container
-system based around `kvmtool`_'s ``lkvm``, 
-:abbr:`KVM (Kernel Virtual Machine)` and Intel VT-x features; the
-initial version was aimed primarily at Docker* integration.  Version
-2.0 replaces ``lkvm`` with a lightweight version of 
-:abbr:`QEMU (Quick EMUlator)` `(link) <http:www.qemu.org>`_.
-
-Version 2.0 also expands the feature set to include key technologies, such
-as `SR-IOV`_, and the :abbr:`Open Container Initiative (OCI)` runtime API.
-
-
-
-V1.0
-====
-
-V1.0 (also known as **Intel® Clear Containers for Docker
-Engine**) is based around `kvmtool`_, with example host integrations for
-Docker and `rkt`_.
-
-.. figure:: _static/images/clear-containers-v1.png
-   :align: center
-   :alt: Intel Clear Containers V1.0
-
-
-Host kernel optimizations
--------------------------
-
-Intel Clear Containers operate better when a number of host kernel features and
-optimizations are applied:
-
-* Enabling :abbr:`Kernel Samepage Merging (KSM)` in the host kernel
-  is recommended for efficient page sharing of VM pages. Kernel documentation
-  can be found in Documentation/vm/ksm.txt  Config symbol: ``CONFIG_KSM``
-* Using a kernel version >= v4.0 (or backporting appropriate
-  patches if your kernel version is less than v4.0), to get the best 
-  :abbr:`KVM (Kernel Virtual Machine)` VM startup times
-
-  .. note::
-
-     Intel :abbr:`Extended Page Table (EPT)` acceleration will be
-     automatically detected and used by your host kernel if supported
-     by your hardware. You can check whether this feature is present by
-     looking for the ``ept`` string in the :file:`/proc/cpuinfo` of your
-     system. See `mmu.txt`_ for more details.
-
-
-Host user space
----------------
-
-Intel Clear Containers V1.0 host user space is based around `kvmtool`_ as a fast
-and lightweight hypervisor. Optimizations to `kvmtool`_ include:
-
-* **File access**, enabling efficient *shmem* / *pci-bar* / :abbr:`Direct
-  Access (DAX)` file access to client.
-* **Less verbosity**.
-* **Minimal UART scanning** to improve speed.
-* **TSC timer functionality changes** passing the client apic timer
-  calibration step speeds up container creation time.
-* Adding ability to **skip unused features**, (such as creation of a
-  custom rootfs).
-* **Removing need for BIOS** saves boot time.
-* **No bootloader required** speeds up initial booting of a machine.
-* **Direct kernel boot** -- The hypervisor can boot the kernel directly as
-  an uncompressed ELF binary. Although the kernel image is slightly larger
-  than a compressed one, it is faster to read and boot the larger
-  file than it is to uncompress and boot the slightly smaller file.
-
-
-Client mini-OS
---------------
-
-Intel Clear Containers V1.0 uses an optimized client user space (mini-OS) as its
-primary launch vehicle to execute workload commands. The mini-OS is built
-with a Clear Linux distribution that has an optimized configuration for
-time and space efficiency. The mini-OS includes:
-
-* Minimized ``systemd`` configuration
-* Optimized ``libc``
-* Custom AutoFDO settings
-* Optimized multi-lib runtime support
-* Optimized kernel config (speed and size)
-
-The mini-OS configuration can be modified and rebuilt by customers for their
-own use cases, which may preclude the need to load further client images.
-
-
-Client customer images
-----------------------
-
-Intel Clear Containers V1.0 mini-OS workloads can be used to bootstrap further
-customer images. These customer images would generally be mapped into the
-client via the host filesystem using :abbr:`9p (Plan 9 9p remote filesystem
-protocol)`, :abbr:`DAX (Direct Access)` or other filesystem and virtual
-device interfaces. These customer images could, for example:
-
-* Mount a new subtree containing a payload and execute it.
-* Mount a new subsystem and chroot to it for contained execution.
-
-The mini-OS image has been optimized for size and speed. It may be replaced
-or superseded -- in whole or in part -- by customer-created images.  Keep
-in mind, of course, that any benefits the mini-OS provides may be lost
-unless equivalent optimizations exist in the customer-created image, or have
-been migrated into the image they create.
-
-
-
-V2.0
-====
-
-Intel Clear Containers V2.0 adopts an optimized version of the established `QEMU`_ 
-host virtualization engine, in order to support extra features not found in
-Clear Containers V1.0. Clear Containers. V2.0 is also compatible with the
-:abbr:`OCI (Open Container Initiative)` runtime-specification standard,
-introducing a host-side abstraction tool to ease host-side integration and to
-isolate integration instances from future changes to the underlying Clear
-Containers architecture.
-
-.. figure:: _static/images/clear-containers-v2.png
-   :align: center
-   :alt: Clear Containers V2.0
-
-Host kernel optimizations
--------------------------
-
-V2.0 host kernel optimizations are currently the same as
-the V1.0 optimizations.
-
-Host user space
----------------
-
-Host user space is based around an optimized version of `QEMU`_ called
-``qemu-lite``, with an :abbr:`OCI (Open Container Initiative)`
-runtime-compliant wrapper called ``cor``.
-
-Our version of ``qemu-lite`` has the following modifications:
-
-* :abbr:`DAX (Direct Access)` support, **enabling fast and space efficient**
-  file access through zero-copy mapping and multi-container sharing of raw
-  client filesystem images from the host filesystem.
-* **Reduced "slimline" PC model** to reduce startup costs in both `QEMU`_ 
-  and the client kernel.
-* **Removed need for BIOS**, saving boot time.
-* **No bootloader requirement**, to speed up boot.
-* **Reduced memory footprint** by disabling memory-hungry features that
-  are not required by the client system.
-* **Direct kernel boot**, allowing fast booting by loading the kernel as
-  an uncompressed ELF binary. Although the kernel image is slightly larger
-  than a compressed one, it is faster to read and boot the larger
-  file than it is to uncompress and boot the slightly smaller file.
-* **Added an** :abbr:`OCI (Open Container Initiative)` **runtime-compliant
-  wrapper**, AKA ``cor``, for easier integration with
-  :abbr:`OCI (Open Container Initiative)`-compliant host orchestration systems.
-
-Client mini-OS
---------------
-
-The Client mini-OS is based on the same Clear Linux OS-based system as
-used in Intel Clear Containers V1.0; however, it may be built from more
-recent versions and with more current components, such as the kernel version.
-
-Client customer images
-----------------------
-
-Client customer images are supported in the same manner as they are
-in V1.0.
-
-
-
-Architectural component details
-===============================
-
-Host kernel components
-----------------------
-
-:abbr:`Kernel SamePage Merging (KSM)`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Linux Kernel Documentation: Documentation/vm/ksm.txt
-
-:abbr:`KSM (Kernel Samepage Merging)` allows the kernel to locate
-and merge (share) identical memory pages within the system, even
-when they are not sourced from the same binary. When sourced from
-the same binary, the kernel will naturally share through the
-:abbr:`copy-on-write (COW)` method. 
-
-:abbr:`KSM (Kernel Samepage Merging)` also allows the kernel to
-localize and to coalesce pages from within virtual machine memory
-spaces that would not normally be shared, thus saving memory space.
-
-To enable :abbr:`KSM (Kernel Samepage Merging)`, check that your host kernel
-config includes ``CONFIG_KSM``, and that your host system is running the
-``ksmd`` daemon.
-
-:abbr:`EPT (Extended Page Tables)`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Linux Kernel Documentation: Documentation/virtual/kvm/mmu.txt
-
-:abbr:`EPT (Extended Page Tables)` is an acceleration technology for virtual
-machine memory mappings. It reduces the number of Virtual Machine Manager
-entry/exits from the host system, thus improving system performance. If your
-hardware system supports :abbr:`EPT (Extended Page Tables)`, you'll see the
-``ept`` feature listed in the ``/proc/cpuinfo`` information from your system.
-The kernel, :abbr:`KVM (Kernel Virtual Machine)` and `QEMU`_ will
-automatically use and benefit from :abbr:`EPT (Extended Page Tables)`
-when supported by your system hardware.
-
-You can also check on the `Intel ARK website`_ to see if your Intel CPU
-supports **Intel VT-x with Extended Page Tables**; check under the
-*Advanced Technologies* table on the specific page for your CPU.
-
-:abbr:`KVM (Kernel Virtual Machine)` startup optimizations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Host kernel startup was optimized before the Linux kernel v4.0
-release by removing some unnecessary ``synchronize_rcu()`` calls. You
-should ensure your kernel is at least v4.0, or that you have backported
-any appropriate patches to your host kernel:  the ``synchronize_rcu() opt``,
-at the very least.
-
-.. We should add a Persistent data (how do we do that on R/O or COW'd
-  filesystems for instance?
-  [do we have a standard pattern to do for these docs?]
-  Persistence
-  ~~~~~~~~~~~
-
-
-Host tooling
-------------
-
-Kvmtool
-~~~~~~~
-
-Kvmtool is used in Intel Clear Containers V1.0 for virtual machine
-configuration and management. It was chosen because it is lighter
-and faster than the alternatives, and it's also easy to modify.
-
-Modifications to `kvmtool`_ include:
-
-* Implementation of **copy-free** :abbr:`DAX (Direct Access)` **file-system
-  access**.
-* **Less verbosity**.
-* **Minimal UART scanning** to improve speed.
-* **TSC timer functionality changes** passing the client apic timer
-  calibration step speeds up container creation time.
-* Adding ability to **skip unused features**, (such as creation of a
-  custom rootfs).
-* **Removing need for BIOS** saves boot time.
-* **No bootloader required** speeds up initial booting of a machine.
-* **Direct kernel boot** -- The hypervisor can boot the kernel directly as
-  an uncompressed ELF binary. Although the kernel image is slightly larger
-  than a compressed one, it ends up being faster to read and boot the larger
-  file than it is to uncompress and boot the slightly smaller file.
-
-
-.. _qemu-lite:
-
-qemu-lite
-~~~~~~~~~
-
-``qemu-lite`` is a modified version of `QEMU`_ used for the virtual
-machine configuration and management in Intel Clear Containers 2.0.
-
-The modifications made beyond generic `QEMU`_ are described in the
-following sections:
-
-:abbr:`DAX (Direct Access)` enablement
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-:abbr:`DAX (Direct Access)` enablement under ``qemu-lite`` utilizes
-existing `QEMU`_ ``nvdimm memdev`` functionality.
-
-PC-lite
-^^^^^^^
-
-A new `QEMU`_ PC model, called ‘pc-lite’, has been added that removes
-all unused or unnecessary PC style elements from the machine emulation
-that are not required for the client VM. This improves both speed of
-execution and memory footprint.
-
-Cor
-^^^
-
-Cor (the Clear :abbr:`OCI (Open Container Initiative)` runtime manager)
-implements the :abbr:`OCI (Open Container Initiative)` runtime specification
-atop of the V2.0 infrastructure (such as ``qemu-lite``). By
-utilizing Cor, your :abbr:`OCI (Open Container Initiative)`-compliant system
-can be implemented with Clear Containers whilst also insulating
-the user against any future underlying changes in Clear Containers,
-thus allowing easier future integration of upgrades. Cor currently
-supports :abbr:`OCI (Open Container Initiative)` runtime version 0.6.0.
-
-Client components
-~~~~~~~~~~~~~~~~~
-
-The client-side components consist of the mini-OS kernel and root
-filesystem, and optionally further customer specific items, such as
-a further fuller distribution or system to load. The intention is
-that customers may either extend and expand the mini-OS as required,
-or they can use the mini-OS to further load a complete self-contained
-image of their choice.
-
-Client mini-OS
-^^^^^^^^^^^^^^
-
-The mini-OS is an optimized version of Clear Linux OS for Intel Architecture
-which has been designed for the fastest and smallest container boot. The
-mini-OS consists of a Linux kernel image and root filesystem image.
-
-* **Kernel** -- The mini-OS's kernel is a Clear Linux kernel containing
-  the minimum feature set required to boot the client container. The kernel
-  has optimized for space and speed. This kernel can be modified and
-  re-built as desired, for specific requirements.
-
-* **DAX** -- The :abbr:`Direct Access (DAX)` filesystem.
-  (Linux Kernel Documentation: ``Documentation/filesystems/dax.txt``). 
-  Mapping host-side files into the memory map of the client allows the use of
-  :abbr:`DAX (Direct Access)` to directly mount those files, bypassing the
-  client side page cache and the virtual device mechanisms between host and
-  client. This allows efficient zero-copy mapping and replaces costly virtual
-  device manipulations with efficient page fault handling, thus being faster
-  and more space-efficient than other filesystem mount methods. :abbr:`DAX
-  (Direct Access)` is enabled in Intel Clear Containers V1.0 using a shmem
-  PCI-BAR mechanism configured by `kvmtool`_.
-
-  .. figure:: _static/images/dax-v1.png
-  	 :align: center
-
-  :abbr:`DAX (Direct Access)` is enabled in Intel Clear Containers 
-  V2.0 using an   NVDIMM `QEMU`_ memdev mechanism:
-
-    .. figure:: _static/images/dax-v2.png
-  	 :align: center
-
-  :abbr:`DAX (Direct Access)` can only be used to mount single flat files
-  from the host side (such as uncompressed filesystems), and not trees of
-  files in the host filesystem. More than one :abbr:`DAX (Direct Access)`
-  mount can be utilized though. :abbr:`DAX (Direct Access)` is limited only
-  by the virtual address space available, so it can easily accommodate large
-  file mappings.
-
-  :abbr:`DAX (Direct Access)` support was introduced in v4.0 of the kernel.
-  Also see the `qemu-lite`_ section.
-
-* **Rootfs image** -- The mini-OS rootfs image is a Clear Linux
-  rootfs. It can execute the client workload and be modified and
-  extended using the bundle method to enable further features as
-  necessary. It can also be used to further execute another client
-  container image, such as a different Linux distribution.
-
-
-Customer Client images and workloads
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Customers may use their own client images by instructing
-the mini-OS to execute them using the mini-OS workload. Please
-refer to the `Intel Clear Containers integration guide`_ for
-further detail.
-
-.. removed this section since it is in the GSG 
-
-FAQ
-===
-
-**Q.** "Can I run Clear Containers on any host Linux?"
-
-**A.** Yes, any up-to-date or recent Linux host should be able to run Clear
-   Containers, as long as the host system kernel contains the necessary
-   features and is configured with the necessary support enabled.
-
-..   [to do: finish this section]
-
-**Q.** "Do I need to use all of Clear Containers, or can I cherry pick parts?"
-
-**A.** You can cherry pick the parts of Clear Containers you need. Some parts
-   will make your life generally easier (such as the `QEMU`_ wrapper tool
-   ``cor``) and will help insulate you from future development changes, so you
-   should consider which parts you need for which features. The client
-   side obviously can be quite flexible in its configuration depending
-   on the deployment environment.
-
-**Q.** "Can I use Clear Containers technology to run other VMs, not just
-   container style ones?"
-
-**A.** Yes, the underlying mechanisms and accelerations used for Clear
-   Containers can be applied to any Virtual Machine setup, not just
-   those that are based around a container style workflow.
-
-
-
-
-
-
-.. _SR-IOV: http://www.intel.com/content/www/us/en/pci-express/pci-sig-sr-iov-primer-sr-iov-technology-paper.html
-.. _QEMU: http://www.qemu.org
-.. _mmu.txt:  Documentation/virtual/kvm/mmu.txt
-.. _Intel ARK website: http://ark.intel.com
-.. _kvmtool: https://git.kernel.org/cgit/linux/kernel/git/will/kvmtool.git/
-.. _rkt: https://coreos.com/rkt/
+.. _clear_containers.rst:
+
+Intel® Clear Containers
+#######################
+
+Introduction
+============
+
+Intel® Clear Containers is a collection of tools, configurations,
+and techniques anchored on an implementation that leverages Intel®
+Architecture to optimize container launching and execution workflow.
+These optimizations improve speed, size, and efficiency while offering
+a number of benefits that can be derived only from hardware-backed
+virtual machines (hardware-enforced isolation and security, for
+example) on Intel® VT technology.
+
+These methods are applied across all levels of the host/virtual machine
+hierarchy: from the host-side userland software stack down through the host
+Linux* kernel, and into the client-side kernel and userland.
+
+Although it is available as a standalone offering, the Clear Containers
+technology works best when it is able to leverage optimizations designed
+into the Clear Linux Project.
+
+Customers can integrate all or parts of Intel Clear Containers into a
+container infrastructure.
+
+.. _architecture_overview.rst:
+
+Architecture Overview
+=====================
+
+Intel Clear Containers are architected around the Linux
+:abbr:`Kernel Virtual Machine (KVM)` virtualization infrastructure to
+make best use of Intel Architecture VT features. Operational speed
+gets improved and overhead gets reduced by optimizing existing code,
+removing redundant components, and implementing new techniques for
+containers with :abbr:`KVM (Kernel Virtual Machine)`.
+
+Version 1.0 of Clear Containers was designed as a lightweight container
+system based around `kvmtool`_'s ``lkvm``,
+:abbr:`KVM (Kernel Virtual Machine)` and Intel VT-x features; the
+initial version was aimed primarily at Docker* integration.  Version
+2.0 replaces ``lkvm`` with a lightweight version of
+:abbr:`QEMU (Quick EMUlator)` `(link) <http:www.qemu.org>`_.
+
+Version 2.0 also expands the feature set to include key technologies, such
+as `SR-IOV`_, and the :abbr:`Open Container Initiative (OCI)` runtime API.
+
+
+
+V1.0
+====
+
+V1.0 (also known as **Intel® Clear Containers for Docker
+Engine**) is based around `kvmtool`_, with example host integrations for
+Docker and `rkt`_.
+
+.. figure:: ../_static/images/advanced/clear-containers-v1.png
+   :align: center
+   :alt: Intel Clear Containers V1.0
+
+
+Host kernel optimizations
+-------------------------
+
+Intel Clear Containers operate better when a number of host kernel features and
+optimizations are applied:
+
+* Enabling :abbr:`Kernel Samepage Merging (KSM)` in the host kernel
+  is recommended for efficient page sharing of VM pages. Kernel documentation
+  can be found in Documentation/vm/ksm.txt  Config symbol: ``CONFIG_KSM``
+* Using a kernel version >= v4.0 (or backporting appropriate
+  patches if your kernel version is less than v4.0), to get the best
+  :abbr:`KVM (Kernel Virtual Machine)` VM startup times
+
+  .. note::
+
+     Intel :abbr:`Extended Page Table (EPT)` acceleration will be
+     automatically detected and used by your host kernel if supported
+     by your hardware. You can check whether this feature is present by
+     looking for the ``ept`` string in the :file:`/proc/cpuinfo` of your
+     system. See `mmu.txt`_ for more details.
+
+
+Host user space
+---------------
+
+Intel Clear Containers V1.0 host user space is based around `kvmtool`_ as a fast
+and lightweight hypervisor. Optimizations to `kvmtool`_ include:
+
+* **File access**, enabling efficient *shmem* / *pci-bar* / :abbr:`Direct
+  Access (DAX)` file access to client.
+* **Less verbosity**.
+* **Minimal UART scanning** to improve speed.
+* **TSC timer functionality changes** passing the client apic timer
+  calibration step speeds up container creation time.
+* Adding ability to **skip unused features**, (such as creation of a
+  custom rootfs).
+* **Removing need for BIOS** saves boot time.
+* **No bootloader required** speeds up initial booting of a machine.
+* **Direct kernel boot** -- The hypervisor can boot the kernel directly as
+  an uncompressed ELF binary. Although the kernel image is slightly larger
+  than a compressed one, it is faster to read and boot the larger
+  file than it is to uncompress and boot the slightly smaller file.
+
+
+Client mini-OS
+--------------
+
+Intel Clear Containers V1.0 uses an optimized client user space (mini-OS) as its
+primary launch vehicle to execute workload commands. The mini-OS is built
+with a Clear Linux distribution that has an optimized configuration for
+time and space efficiency. The mini-OS includes:
+
+* Minimized ``systemd`` configuration
+* Optimized ``libc``
+* Custom AutoFDO settings
+* Optimized multi-lib runtime support
+* Optimized kernel config (speed and size)
+
+The mini-OS configuration can be modified and rebuilt by customers for their
+own use cases, which may preclude the need to load further client images.
+
+
+Client customer images
+----------------------
+
+Intel Clear Containers V1.0 mini-OS workloads can be used to bootstrap further
+customer images. These customer images would generally be mapped into the
+client via the host filesystem using :abbr:`9p (Plan 9 9p remote filesystem
+protocol)`, :abbr:`DAX (Direct Access)` or other filesystem and virtual
+device interfaces. These customer images could, for example:
+
+* Mount a new subtree containing a payload and execute it.
+* Mount a new subsystem and chroot to it for contained execution.
+
+The mini-OS image has been optimized for size and speed. It may be replaced
+or superseded -- in whole or in part -- by customer-created images.  Keep
+in mind, of course, that any benefits the mini-OS provides may be lost
+unless equivalent optimizations exist in the customer-created image, or have
+been migrated into the image they create.
+
+
+
+V2.0
+====
+
+Intel Clear Containers V2.0 adopts an optimized version of the established `QEMU`_
+host virtualization engine, in order to support extra features not found in
+Clear Containers V1.0. Clear Containers. V2.0 is also compatible with the
+:abbr:`OCI (Open Container Initiative)` runtime-specification standard,
+introducing a host-side abstraction tool to ease host-side integration and to
+isolate integration instances from future changes to the underlying Clear
+Containers architecture.
+
+.. figure:: ../_static/images/advanced/clear-containers-v2.png
+   :align: center
+   :alt: Clear Containers V2.0
+
+Host kernel optimizations
+-------------------------
+
+V2.0 host kernel optimizations are currently the same as
+the V1.0 optimizations.
+
+Host user space
+---------------
+
+Host user space is based around an optimized version of `QEMU`_ called
+``qemu-lite``, with an :abbr:`OCI (Open Container Initiative)`
+runtime-compliant wrapper called ``cor``.
+
+Our version of ``qemu-lite`` has the following modifications:
+
+* :abbr:`DAX (Direct Access)` support, **enabling fast and space efficient**
+  file access through zero-copy mapping and multi-container sharing of raw
+  client filesystem images from the host filesystem.
+* **Reduced "slimline" PC model** to reduce startup costs in both `QEMU`_
+  and the client kernel.
+* **Removed need for BIOS**, saving boot time.
+* **No bootloader requirement**, to speed up boot.
+* **Reduced memory footprint** by disabling memory-hungry features that
+  are not required by the client system.
+* **Direct kernel boot**, allowing fast booting by loading the kernel as
+  an uncompressed ELF binary. Although the kernel image is slightly larger
+  than a compressed one, it is faster to read and boot the larger
+  file than it is to uncompress and boot the slightly smaller file.
+* **Added an** :abbr:`OCI (Open Container Initiative)` **runtime-compliant
+  wrapper**, AKA ``cor``, for easier integration with
+  :abbr:`OCI (Open Container Initiative)`-compliant host orchestration systems.
+
+Client mini-OS
+--------------
+
+The Client mini-OS is based on the same Clear Linux OS-based system as
+used in Intel Clear Containers V1.0; however, it may be built from more
+recent versions and with more current components, such as the kernel version.
+
+Client customer images
+----------------------
+
+Client customer images are supported in the same manner as they are
+in V1.0.
+
+
+
+Architectural component details
+===============================
+
+Host kernel components
+----------------------
+
+:abbr:`Kernel SamePage Merging (KSM)`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Linux Kernel Documentation: Documentation/vm/ksm.txt
+
+:abbr:`KSM (Kernel Samepage Merging)` allows the kernel to locate
+and merge (share) identical memory pages within the system, even
+when they are not sourced from the same binary. When sourced from
+the same binary, the kernel will naturally share through the
+:abbr:`copy-on-write (COW)` method.
+
+:abbr:`KSM (Kernel Samepage Merging)` also allows the kernel to
+localize and to coalesce pages from within virtual machine memory
+spaces that would not normally be shared, thus saving memory space.
+
+To enable :abbr:`KSM (Kernel Samepage Merging)`, check that your host kernel
+config includes ``CONFIG_KSM``, and that your host system is running the
+``ksmd`` daemon.
+
+:abbr:`EPT (Extended Page Tables)`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Linux Kernel Documentation: Documentation/virtual/kvm/mmu.txt
+
+:abbr:`EPT (Extended Page Tables)` is an acceleration technology for virtual
+machine memory mappings. It reduces the number of Virtual Machine Manager
+entry/exits from the host system, thus improving system performance. If your
+hardware system supports :abbr:`EPT (Extended Page Tables)`, you'll see the
+``ept`` feature listed in the ``/proc/cpuinfo`` information from your system.
+The kernel, :abbr:`KVM (Kernel Virtual Machine)` and `QEMU`_ will
+automatically use and benefit from :abbr:`EPT (Extended Page Tables)`
+when supported by your system hardware.
+
+You can also check on the `Intel ARK website`_ to see if your Intel CPU
+supports **Intel VT-x with Extended Page Tables**; check under the
+*Advanced Technologies* table on the specific page for your CPU.
+
+:abbr:`KVM (Kernel Virtual Machine)` startup optimizations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Host kernel startup was optimized before the Linux kernel v4.0
+release by removing some unnecessary ``synchronize_rcu()`` calls. You
+should ensure your kernel is at least v4.0, or that you have backported
+any appropriate patches to your host kernel:  the ``synchronize_rcu() opt``,
+at the very least.
+
+.. We should add a Persistent data (how do we do that on R/O or COW'd
+  filesystems for instance?
+  [do we have a standard pattern to do for these docs?]
+  Persistence
+  ~~~~~~~~~~~
+
+
+Host tooling
+------------
+
+Kvmtool
+~~~~~~~
+
+Kvmtool is used in Intel Clear Containers V1.0 for virtual machine
+configuration and management. It was chosen because it is lighter
+and faster than the alternatives, and it's also easy to modify.
+
+Modifications to `kvmtool`_ include:
+
+* Implementation of **copy-free** :abbr:`DAX (Direct Access)` **file-system
+  access**.
+* **Less verbosity**.
+* **Minimal UART scanning** to improve speed.
+* **TSC timer functionality changes** passing the client apic timer
+  calibration step speeds up container creation time.
+* Adding ability to **skip unused features**, (such as creation of a
+  custom rootfs).
+* **Removing need for BIOS** saves boot time.
+* **No bootloader required** speeds up initial booting of a machine.
+* **Direct kernel boot** -- The hypervisor can boot the kernel directly as
+  an uncompressed ELF binary. Although the kernel image is slightly larger
+  than a compressed one, it ends up being faster to read and boot the larger
+  file than it is to uncompress and boot the slightly smaller file.
+
+
+.. _qemu-lite:
+
+qemu-lite
+~~~~~~~~~
+
+``qemu-lite`` is a modified version of `QEMU`_ used for the virtual
+machine configuration and management in Intel Clear Containers 2.0.
+
+The modifications made beyond generic `QEMU`_ are described in the
+following sections:
+
+:abbr:`DAX (Direct Access)` enablement
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+:abbr:`DAX (Direct Access)` enablement under ``qemu-lite`` utilizes
+existing `QEMU`_ ``nvdimm memdev`` functionality.
+
+PC-lite
+^^^^^^^
+
+A new `QEMU`_ PC model, called ‘pc-lite’, has been added that removes
+all unused or unnecessary PC style elements from the machine emulation
+that are not required for the client VM. This improves both speed of
+execution and memory footprint.
+
+Cor
+^^^
+
+Cor (the Clear :abbr:`OCI (Open Container Initiative)` runtime manager)
+implements the :abbr:`OCI (Open Container Initiative)` runtime specification
+atop of the V2.0 infrastructure (such as ``qemu-lite``). By
+utilizing Cor, your :abbr:`OCI (Open Container Initiative)`-compliant system
+can be implemented with Clear Containers whilst also insulating
+the user against any future underlying changes in Clear Containers,
+thus allowing easier future integration of upgrades. Cor currently
+supports :abbr:`OCI (Open Container Initiative)` runtime version 0.6.0.
+
+Client components
+~~~~~~~~~~~~~~~~~
+
+The client-side components consist of the mini-OS kernel and root
+filesystem, and optionally further customer specific items, such as
+a further fuller distribution or system to load. The intention is
+that customers may either extend and expand the mini-OS as required,
+or they can use the mini-OS to further load a complete self-contained
+image of their choice.
+
+Client mini-OS
+^^^^^^^^^^^^^^
+
+The mini-OS is an optimized version of Clear Linux OS for Intel Architecture
+which has been designed for the fastest and smallest container boot. The
+mini-OS consists of a Linux kernel image and root filesystem image.
+
+* **Kernel** -- The mini-OS's kernel is a Clear Linux kernel containing
+  the minimum feature set required to boot the client container. The kernel
+  has optimized for space and speed. This kernel can be modified and
+  re-built as desired, for specific requirements.
+
+* **DAX** -- The :abbr:`Direct Access (DAX)` filesystem.
+  (Linux Kernel Documentation: ``Documentation/filesystems/dax.txt``).
+  Mapping host-side files into the memory map of the client allows the use of
+  :abbr:`DAX (Direct Access)` to directly mount those files, bypassing the
+  client side page cache and the virtual device mechanisms between host and
+  client. This allows efficient zero-copy mapping and replaces costly virtual
+  device manipulations with efficient page fault handling, thus being faster
+  and more space-efficient than other filesystem mount methods. :abbr:`DAX
+  (Direct Access)` is enabled in Intel Clear Containers V1.0 using a shmem
+  PCI-BAR mechanism configured by `kvmtool`_.
+
+  .. figure:: ../_static/images/advanced/dax-v1.png
+  	 :align: center
+
+  :abbr:`DAX (Direct Access)` is enabled in Intel Clear Containers
+  V2.0 using an   NVDIMM `QEMU`_ memdev mechanism:
+
+    .. figure:: ../_static/images/advanced/dax-v2.png
+  	 :align: center
+
+  :abbr:`DAX (Direct Access)` can only be used to mount single flat files
+  from the host side (such as uncompressed filesystems), and not trees of
+  files in the host filesystem. More than one :abbr:`DAX (Direct Access)`
+  mount can be utilized though. :abbr:`DAX (Direct Access)` is limited only
+  by the virtual address space available, so it can easily accommodate large
+  file mappings.
+
+  :abbr:`DAX (Direct Access)` support was introduced in v4.0 of the kernel.
+  Also see the `qemu-lite`_ section.
+
+* **Rootfs image** -- The mini-OS rootfs image is a Clear Linux
+  rootfs. It can execute the client workload and be modified and
+  extended using the bundle method to enable further features as
+  necessary. It can also be used to further execute another client
+  container image, such as a different Linux distribution.
+
+
+Customer Client images and workloads
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Customers may use their own client images by instructing
+the mini-OS to execute them using the mini-OS workload. Please
+refer to the `Intel Clear Containers integration guide`_ for
+further detail.
+
+.. removed this section since it is in the GSG
+
+FAQ
+===
+
+**Q.** "Can I run Clear Containers on any host Linux?"
+
+**A.** Yes, any up-to-date or recent Linux host should be able to run Clear
+   Containers, as long as the host system kernel contains the necessary
+   features and is configured with the necessary support enabled.
+
+..   [to do: finish this section]
+
+**Q.** "Do I need to use all of Clear Containers, or can I cherry pick parts?"
+
+**A.** You can cherry pick the parts of Clear Containers you need. Some parts
+   will make your life generally easier (such as the `QEMU`_ wrapper tool
+   ``cor``) and will help insulate you from future development changes, so you
+   should consider which parts you need for which features. The client
+   side obviously can be quite flexible in its configuration depending
+   on the deployment environment.
+
+**Q.** "Can I use Clear Containers technology to run other VMs, not just
+   container style ones?"
+
+**A.** Yes, the underlying mechanisms and accelerations used for Clear
+   Containers can be applied to any Virtual Machine setup, not just
+   those that are based around a container style workflow.
+
+
+
+
+
+
+.. _SR-IOV: http://www.intel.com/content/www/us/en/pci-express/pci-sig-sr-iov-primer-sr-iov-technology-paper.html
+.. _QEMU: http://www.qemu.org
+.. _mmu.txt:  Documentation/virtual/kvm/mmu.txt
+.. _Intel ARK website: http://ark.intel.com
+.. _kvmtool: https://git.kernel.org/cgit/linux/kernel/git/will/kvmtool.git/
+.. _rkt: https://coreos.com/rkt/
 .. _Intel Clear Containers integration guide: https://clearlinux.org/documentation/gs-clear-containers-getting-started.html

source/advanced/dpdk.rst

@@ -1,364 +1,364 @@
-.. _ac-dpdk:
-
-DPDK
-####
-
-Introduction
-============
-
-DPDK_ is a set of libraries and drivers for fast packet processing.
-This document describes how to run a basic use case for **l3fwd
-DPDK example**. The objective is to *send packages between two platforms* using a
-traffic generator called :ref:`pktgen <sec_pktgen>`, where the l3fwd example
-application will forward those packages. See (:ref:`f1`)
-
-.. _f1:
-
-.. figure:: _static/images/pktgen_lw3fd.png
-   :align: center
-   :alt: platform A and B
-
-   Figure 1: environment for l3fwd DPDK application.
-
-
-**Requirements:**
-
-* Two platforms using Clear Linux* for Intel® Architecture (recommended release `7160`_ or higher).
-* Both images have the **kernel-native bundle** added.
-* Installation of ``dpdk-dev``, ``os-core-dev`` and ``sysadmin-basic`` bundles:
-
-  .. code-block:: bash
-
-     # swupd bundle-add dpdk-dev os-core-dev sysadmin-basic
-
-* The platforms must have two NICs, at least one each. It's very important to check network card 
-  compatibility with the DPDK project. You can do this on the `dpdk.org NICS`_ site.
-* Two network cables.
-
-
-Disabling iommu on Clear Linux OS for Intel Architecture (Platforms A and B)
-============================================================================
-
-#. Mount the :abbr:`ESP (EFI system partition)`.
-
-   .. code-block:: bash
-
-      # systemctl start boot.mount
-
-#. Move to entries directory.
-
-   .. code-block:: bash
-
-      # cd /boot/loader/entries/
-
-#. Edit ``clear-linux-native.conf`` by adding ``intel_iommu=off`` after the last line.
-
-#. Umount ESP and reboot.
-
-   .. code-block:: bash
-
-      # cd /
-      # systemctl stop boot.mount
-      # reboot
-
-
-Installing dpdk and build l3fwd example (Platform B)
-====================================================
-
-#. Install ``dpdk`` bundle.
-
-   .. code-block:: bash
-
-      # swupd bundle-add dpdk-dev
-
-#. Move to ``l3fwd`` example.
-
-   .. code-block:: bash
-
-      # cd /usr/share/dpdk/examples/l3fwd
-
-#. Assign ``RTE_SDK var`` to the makefiles path.
-
-   .. code-block:: bash
-
-      # export RTE_SDK=/usr/share/dpdk/
-
-#. Assign ``RTE_TARGET var`` the value where the gcc config file is located.
-
-   .. code-block:: bash
-
-      # export RTE_TARGET=x86_64-native-linuxapp-gcc
-
-#. Build the ``l3fwd`` application, and add the configuration header to the ``CFLAGS`` var.
-
-   .. code-block:: bash
-
-      # make CFLAGS+="-include /usr/include/rte_config.h"
-
-
-
-.. _sec_pktgen:
-
-Building Pktgen (Platform A)
-============================
-
-Since the ``pktgen`` project is currently not included in Clear Linux OS for Intel 
-Architecture, you must download it from upstream and build it:
-
-#. Install ``dpdk`` bundle.
-
-   .. code-block:: bash
-
-      # swupd bundle-add dpdk-dev
-
-#. Download the `pktgen tar package 2.9.12`_.
-
-#. Decompress packages and move to uncompressed source directory.
-
-#. Assign ``RTE_SDK var`` the path where makefiles are located.
-
-   .. code-block:: bash
-
-      # export RTE_SDK=/usr/share/dpdk/
-
-#. Assign ``RTE_TARGET var`` the value where the gcc config file is located.
-
-   .. code-block:: bash
-
-      # export RTE_TARGET=x86_64-native-linuxapp-gcc
-
-#. Build pktgen project, and set the ``CONFIG_RTE_BUILD_SHARED_LIB`` variable with "n".
-
-   .. code-block:: bash
-
-      # make CONFIG_RTE_BUILD_SHARED_LIB=n
-
-Binding NICs to DPDK kernel drivers (Platforms A and B)
-=======================================================
-
-The ``l3fwd`` application uses two NICs. DPDK has useful tools for binding NICs to
-DPDK modules to run DPDK applications.
-
-#. Load the dpdk I/O kernel module
-
-   .. code-block:: bash
-
-      # modprobe igb_uio
-
-#. Check the status of your NICs; this will show which network cards are not busy. When
-   another application is using them, the status shows ``Active``, and those NICs cannot be
-   bound.
-
-   .. code-block:: bash
-
-      # dpdk_nic_bind.py --status
-
-#. Bind two available NICs. The general syntax for binding is
-   **dpdk_nic_bind.py --bind=igb_uio <device-entry>**,
-   and the following is a working example:
-
-   .. code-block:: bash
-
-      # dpdk_nic_bind.py --bind=igb_uio 01:00.0
-
-#. Check that your NICs binded correctly by checking the status; ``drv`` should have ``igb_uio``
-   value; at this point, the NICs are using the DPDK modules.
-
-
-Setting hugepages (platforms A and B)
-=====================================
-
-Clear Linux OS for Intel Architecture supports ``hugepages`` for the large memory pool
-allocation used for packet buffers.
-
-#. Set number of hugepages.
-
-   .. code-block:: bash
-
-      # echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
-
-#. Allocate pages on NUMA machines.
-
-   .. code-block:: bash
-
-      # echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
-      # echo 1024 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
-
-#. Make memory available for DPDK.
-   
-   .. code-block:: bash
-
-      # mkdir -p /mnt/huge $ mount -t hugetlbfs nodev /mnt/huge
-
-   If you would like to know more about this, refer to the `DPDK guide`_.
-
-
-Setting a physical environment (Platforms A and B)
-==================================================
-
-To achieve the model proposed in the introduction of this topic, (:ref:`f1`), we need
-to connect the first Grantley’s NICs to the second Grantley’s NICs using the network cables
-(:ref:`f2`).
-
-.. _f2:
-
-.. figure:: _static/images/pyshical_net.png
-
-    Figure 2: Physical network environment.
-
-
-Running l3fwd application (Platform B)
-======================================
-
-The ``l3fwd`` application is one of the DPDK examples available when you install the ``dpdk-dev``
-bundle; this application forwards packages from one NIC to another.
-
-#. Open the l3fwd example directory.
-
-   .. code-block:: bash
-
-      # cd  /usr/share/dpdk/examples/l3fwd
-
-#. **This step is very important.** DPDK needs poll drivers for work; these poll drivers are
-   shared objects in :file:`/usr/lib64`. DPDK supports some NICs. The full list available at the
-   `dpdk.org NICS`_ docs. You should know which kernel module the NIC is using and choose a poll
-   driver according to your NICs.
-
-#. At this point the system must have ``hugepages`` requirements. The NICs bound and the
-   configuration for running ``pktgen`` depends upon network use cases and available system
-   resources. Use the ``-d`` flag for setting the pull driver. For example, if the NICs are
-   using ``e1000`` network driver, they are going to use ``e1000`` poll driver
-   (``librte_pmd_e1000.so``); it should be in :file:`/usr/lib64` in Clear Linux OS for Intel Architecture, and it
-   should be enough to add the name. For example
-
-   .. code-block:: bash
-
-      # ./build/l3fwd -c 0x3 -n 2 -d librte_pmd_e1000.so -- -p 0x3 --config="(0,0,0),(1,0,1)"
-
-#. When the application starts to run, it will show information about the ``l3fwd`` running, so
-   pay attention when the application is Initializing ports. After port 0 initialization, you'll
-   see a MAC address and the same for port 1. Save this information for setting configuration
-   to `Pktgen` project.
-
-Running Pktgen application (Platform A)
-===========================================
-
-The `Pktgen` is network traffic generator. It measures the network packaging performance
-in a forwarding use case.
-
-#. At this point the system must have ``hugepages`` requirements and the NICs bound. The
-   configuration for running ``pktgen`` depends upon the network use case and the available
-   system resources. The following is a basic configuration.
-
-   .. code-block:: bash
-
-      # ./app/app/x86_64-native-linuxapp-gcc/pktgen -c 0xf -n 4 -- -p 0xf -P -m "1.0, 2.1"
-
-#. Enable active colorful output (optional).
-
-   .. code-block:: console
-
-      Pktgen> theme enable
-
-#. The ``l3fwd`` application showed a MAC address per-port initialized; this MAC addresses
-   should have been set in the pktgen environment::
-
-   > set mac <port number> <mac address>
-
-   And a working example:
-
-   .. code-block:: console
-
-      Pktgen> set mac 0 00:1E:67:CB:E8:C9
-      Pktgen> set mac 1 00:1E:67:CB:E8:C9
-
-#. Start to send packages using the next command:
-
-   .. code-block:: console
-
-      Pktgen> start 0-1
-
-#. If you followed these steps correctly, you'll see that ``pktgen`` is sending and receiving
-   packages. For more information, see the `Pktgen documentation`_.
-
-
-Annex A: Using pass-through for running on virtual machines
-===========================================================
-
-This section explains how to set up a virtual environment where virtual machines
-control the host's NICs.
-
-#. Create a new directory and move to it.
-
-#. Download or create a ``start_qemu.sh`` script for running a kvm virtual machine:
-
-   .. code-block:: bash
-
-      $ curl -O https://download.clearlinux.org/image/start_qemu.sh
-
-#. Download a bare-metal image of Clear Linux OS for Intel Architecture and rename it as ``clear.img``.
-
-#. Look for an entry for device and vendor & device ID:
-
-   .. code-block:: bash
-
-      $ lspci -nn | grep Ethernet
-
-   An output example from the last step::
-
-       03:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network Connection [8086:1521]
-
-   where ``8086:1521`` is ``vendor:device ID`` and ``03:00.0`` is the entry for device.  Make
-   note of this information; it is necessary for unbinding a host's NICs.
-
-#. Unbind NICs from host to do passthrough with virtual machines. Clear Linux OS for Intel Architecture 
-   currently supports this action. You can use the following commands::
-
-      echo "vendor device_ID" > /sys/bus/pci/drivers/pci-stub/new_id
-      echo "entry for device" > /sys/bus/pci/drivers/igb/unbind
-      echo "entry for device" > /sys/bus/pci/drivers/pci-stub/bind
-      echo "vendor device_ID" > /sys/bus/pci/drivers/pci-stub/remove_id
-
-   .. code-block:: bash
-
-      $ echo "8086 1521" > /sys/bus/pci/drivers/pci-stub/new_id
-      $ echo "0000:03:00.0" > /sys/bus/pci/drivers/igb/unbind
-      $ echo "0000:03:00.0" > /sys/bus/pci/drivers/pci-stub/bind
-      $ echo "8086 1521" > /sys/bus/pci/drivers/pci-stub/remove_id
-
-#. Assign to the KVM virtual machine (guest) the unbound NICs previously noted. Modify the
-   ``start_qemu.sh`` script in ``qemu-system-x86_64`` arguments, and add the lines with
-   the host's NICs information::
-
-   -device pci-assign,host="<entry for device>",id=passnic0,addr=03.0
-   -device pci-assign,host="<entry for device>",id=passnic1,addr=04.0
-
-   A working example:
-
-   .. code-block:: bash
-
-      -device pci-assign,host=03:00.0,id=passnic0,addr=03.0 \
-      -device pci-assign,host=03:00.3,id=passnic1,addr=04.0 \
-
-#. If you would like to add more NUMA machines to the virtual machine, you can add the next
-   line in the Makefile boot target::
-
-      -numa node,mem=<memory>,cpus=<number of cpus>
-
-   As a working example for a virtual machine with 4096 of memory and four CPUs, the configuration
-   would look like this::
-
-    -numa node,mem=2048,cpus=0-1 \
-    -numa node,mem=2048,cpus=2-3 \
-
-   This means that each NUMA machine has to use the same quantity of memory.
-
-#. Finally, run the ``start_qemu.sh`` script.
-
-
-.. _7160: https://download.clearlinux.org/releases/7160/
-.. _DPDK: http://dpdk.org
-.. _dpdk.org NICS: http://dpdk.org/doc/nics
-.. _pktgen tar package 2.9.12: http://dpdk.org/browse/apps/pktgen-dpdk/refs
-.. _DPDK guide: http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html
-.. _Pktgen documentation: `Pktgen documentation`_ https://media.readthedocs.org/pdf/pktgen/latest/pktgen.pdf
+.. _ac-dpdk:
+
+DPDK
+####
+
+Introduction
+============
+
+DPDK_ is a set of libraries and drivers for fast packet processing.
+This document describes how to run a basic use case for **l3fwd
+DPDK example**. The objective is to *send packages between two platforms* using a
+traffic generator called :ref:`pktgen <sec_pktgen>`, where the l3fwd example
+application will forward those packages. See (:ref:`f1`)
+
+.. _f1:
+
+.. figure:: ../_static/images/advanced/pktgen_lw3fd.png
+   :align: center
+   :alt: platform A and B
+
+   Figure 1: environment for l3fwd DPDK application.
+
+
+**Requirements:**
+
+* Two platforms using Clear Linux* for Intel® Architecture (recommended release `7160`_ or higher).
+* Both images have the **kernel-native bundle** added.
+* Installation of ``dpdk-dev``, ``os-core-dev`` and ``sysadmin-basic`` bundles:
+
+  .. code-block:: bash
+
+     # swupd bundle-add dpdk-dev os-core-dev sysadmin-basic
+
+* The platforms must have two NICs, at least one each. It's very important to check network card
+  compatibility with the DPDK project. You can do this on the `dpdk.org NICS`_ site.
+* Two network cables.
+
+
+Disabling iommu on Clear Linux OS for Intel Architecture (Platforms A and B)
+============================================================================
+
+#. Mount the :abbr:`ESP (EFI system partition)`.
+
+   .. code-block:: bash
+
+      # systemctl start boot.mount
+
+#. Move to entries directory.
+
+   .. code-block:: bash
+
+      # cd /boot/loader/entries/
+
+#. Edit ``clear-linux-native.conf`` by adding ``intel_iommu=off`` after the last line.
+
+#. Umount ESP and reboot.
+
+   .. code-block:: bash
+
+      # cd /
+      # systemctl stop boot.mount
+      # reboot
+
+
+Installing dpdk and build l3fwd example (Platform B)
+====================================================
+
+#. Install ``dpdk`` bundle.
+
+   .. code-block:: bash
+
+      # swupd bundle-add dpdk-dev
+
+#. Move to ``l3fwd`` example.
+
+   .. code-block:: bash
+
+      # cd /usr/share/dpdk/examples/l3fwd
+
+#. Assign ``RTE_SDK var`` to the makefiles path.
+
+   .. code-block:: bash
+
+      # export RTE_SDK=/usr/share/dpdk/
+
+#. Assign ``RTE_TARGET var`` the value where the gcc config file is located.
+
+   .. code-block:: bash
+
+      # export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+#. Build the ``l3fwd`` application, and add the configuration header to the ``CFLAGS`` var.
+
+   .. code-block:: bash
+
+      # make CFLAGS+="-include /usr/include/rte_config.h"
+
+
+
+.. _sec_pktgen:
+
+Building Pktgen (Platform A)
+============================
+
+Since the ``pktgen`` project is currently not included in Clear Linux OS for Intel
+Architecture, you must download it from upstream and build it:
+
+#. Install ``dpdk`` bundle.
+
+   .. code-block:: bash
+
+      # swupd bundle-add dpdk-dev
+
+#. Download the `pktgen tar package 2.9.12`_.
+
+#. Decompress packages and move to uncompressed source directory.
+
+#. Assign ``RTE_SDK var`` the path where makefiles are located.
+
+   .. code-block:: bash
+
+      # export RTE_SDK=/usr/share/dpdk/
+
+#. Assign ``RTE_TARGET var`` the value where the gcc config file is located.
+
+   .. code-block:: bash
+
+      # export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+#. Build pktgen project, and set the ``CONFIG_RTE_BUILD_SHARED_LIB`` variable with "n".
+
+   .. code-block:: bash
+
+      # make CONFIG_RTE_BUILD_SHARED_LIB=n
+
+Binding NICs to DPDK kernel drivers (Platforms A and B)
+=======================================================
+
+The ``l3fwd`` application uses two NICs. DPDK has useful tools for binding NICs to
+DPDK modules to run DPDK applications.
+
+#. Load the dpdk I/O kernel module
+
+   .. code-block:: bash
+
+      # modprobe igb_uio
+
+#. Check the status of your NICs; this will show which network cards are not busy. When
+   another application is using them, the status shows ``Active``, and those NICs cannot be
+   bound.
+
+   .. code-block:: bash
+
+      # dpdk_nic_bind.py --status
+
+#. Bind two available NICs. The general syntax for binding is
+   **dpdk_nic_bind.py --bind=igb_uio <device-entry>**,
+   and the following is a working example:
+
+   .. code-block:: bash
+
+      # dpdk_nic_bind.py --bind=igb_uio 01:00.0
+
+#. Check that your NICs binded correctly by checking the status; ``drv`` should have ``igb_uio``
+   value; at this point, the NICs are using the DPDK modules.
+
+
+Setting hugepages (platforms A and B)
+=====================================
+
+Clear Linux OS for Intel Architecture supports ``hugepages`` for the large memory pool
+allocation used for packet buffers.
+
+#. Set number of hugepages.
+
+   .. code-block:: bash
+
+      # echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
+
+#. Allocate pages on NUMA machines.
+
+   .. code-block:: bash
+
+      # echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
+      # echo 1024 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
+
+#. Make memory available for DPDK.
+
+   .. code-block:: bash
+
+      # mkdir -p /mnt/huge $ mount -t hugetlbfs nodev /mnt/huge
+
+   If you would like to know more about this, refer to the `DPDK guide`_.
+
+
+Setting a physical environment (Platforms A and B)
+==================================================
+
+To achieve the model proposed in the introduction of this topic, (:ref:`f1`), we need
+to connect the first Grantley’s NICs to the second Grantley’s NICs using the network cables
+(:ref:`f2`).
+
+.. _f2:
+
+.. figure:: ../_static/images/advanced/pyshical_net.png
+
+    Figure 2: Physical network environment.
+
+
+Running l3fwd application (Platform B)
+======================================
+
+The ``l3fwd`` application is one of the DPDK examples available when you install the ``dpdk-dev``
+bundle; this application forwards packages from one NIC to another.
+
+#. Open the l3fwd example directory.
+
+   .. code-block:: bash
+
+      # cd  /usr/share/dpdk/examples/l3fwd
+
+#. **This step is very important.** DPDK needs poll drivers for work; these poll drivers are
+   shared objects in :file:`/usr/lib64`. DPDK supports some NICs. The full list available at the
+   `dpdk.org NICS`_ docs. You should know which kernel module the NIC is using and choose a poll
+   driver according to your NICs.
+
+#. At this point the system must have ``hugepages`` requirements. The NICs bound and the
+   configuration for running ``pktgen`` depends upon network use cases and available system
+   resources. Use the ``-d`` flag for setting the pull driver. For example, if the NICs are
+   using ``e1000`` network driver, they are going to use ``e1000`` poll driver
+   (``librte_pmd_e1000.so``); it should be in :file:`/usr/lib64` in Clear Linux OS for Intel Architecture, and it
+   should be enough to add the name. For example
+
+   .. code-block:: bash
+
+      # ./build/l3fwd -c 0x3 -n 2 -d librte_pmd_e1000.so -- -p 0x3 --config="(0,0,0),(1,0,1)"
+
+#. When the application starts to run, it will show information about the ``l3fwd`` running, so
+   pay attention when the application is Initializing ports. After port 0 initialization, you'll
+   see a MAC address and the same for port 1. Save this information for setting configuration
+   to `Pktgen` project.
+
+Running Pktgen application (Platform A)
+===========================================
+
+The `Pktgen` is network traffic generator. It measures the network packaging performance
+in a forwarding use case.
+
+#. At this point the system must have ``hugepages`` requirements and the NICs bound. The
+   configuration for running ``pktgen`` depends upon the network use case and the available
+   system resources. The following is a basic configuration.
+
+   .. code-block:: bash
+
+      # ./app/app/x86_64-native-linuxapp-gcc/pktgen -c 0xf -n 4 -- -p 0xf -P -m "1.0, 2.1"
+
+#. Enable active colorful output (optional).
+
+   .. code-block:: console
+
+      Pktgen> theme enable
+
+#. The ``l3fwd`` application showed a MAC address per-port initialized; this MAC addresses
+   should have been set in the pktgen environment::
+
+   > set mac <port number> <mac address>
+
+   And a working example:
+
+   .. code-block:: console
+
+      Pktgen> set mac 0 00:1E:67:CB:E8:C9
+      Pktgen> set mac 1 00:1E:67:CB:E8:C9
+
+#. Start to send packages using the next command:
+
+   .. code-block:: console
+
+      Pktgen> start 0-1
+
+#. If you followed these steps correctly, you'll see that ``pktgen`` is sending and receiving
+   packages. For more information, see the `Pktgen documentation`_.
+
+
+Annex A: Using pass-through for running on virtual machines
+===========================================================
+
+This section explains how to set up a virtual environment where virtual machines
+control the host's NICs.
+
+#. Create a new directory and move to it.
+
+#. Download or create a ``start_qemu.sh`` script for running a kvm virtual machine:
+
+   .. code-block:: bash
+
+      $ curl -O https://download.clearlinux.org/image/start_qemu.sh
+
+#. Download a bare-metal image of Clear Linux OS for Intel Architecture and rename it as ``clear.img``.
+
+#. Look for an entry for device and vendor & device ID:
+
+   .. code-block:: bash
+
+      $ lspci -nn | grep Ethernet
+
+   An output example from the last step::
+
+       03:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network Connection [8086:1521]
+
+   where ``8086:1521`` is ``vendor:device ID`` and ``03:00.0`` is the entry for device.  Make
+   note of this information; it is necessary for unbinding a host's NICs.
+
+#. Unbind NICs from host to do passthrough with virtual machines. Clear Linux OS for Intel Architecture
+   currently supports this action. You can use the following commands::
+
+      echo "vendor device_ID" > /sys/bus/pci/drivers/pci-stub/new_id
+      echo "entry for device" > /sys/bus/pci/drivers/igb/unbind
+      echo "entry for device" > /sys/bus/pci/drivers/pci-stub/bind
+      echo "vendor device_ID" > /sys/bus/pci/drivers/pci-stub/remove_id
+
+   .. code-block:: bash
+
+      $ echo "8086 1521" > /sys/bus/pci/drivers/pci-stub/new_id
+      $ echo "0000:03:00.0" > /sys/bus/pci/drivers/igb/unbind
+      $ echo "0000:03:00.0" > /sys/bus/pci/drivers/pci-stub/bind
+      $ echo "8086 1521" > /sys/bus/pci/drivers/pci-stub/remove_id
+
+#. Assign to the KVM virtual machine (guest) the unbound NICs previously noted. Modify the
+   ``start_qemu.sh`` script in ``qemu-system-x86_64`` arguments, and add the lines with
+   the host's NICs information::
+
+   -device pci-assign,host="<entry for device>",id=passnic0,addr=03.0
+   -device pci-assign,host="<entry for device>",id=passnic1,addr=04.0
+
+   A working example:
+
+   .. code-block:: bash
+
+      -device pci-assign,host=03:00.0,id=passnic0,addr=03.0 \
+      -device pci-assign,host=03:00.3,id=passnic1,addr=04.0 \
+
+#. If you would like to add more NUMA machines to the virtual machine, you can add the next
+   line in the Makefile boot target::
+
+      -numa node,mem=<memory>,cpus=<number of cpus>
+
+   As a working example for a virtual machine with 4096 of memory and four CPUs, the configuration
+   would look like this::
+
+    -numa node,mem=2048,cpus=0-1 \
+    -numa node,mem=2048,cpus=2-3 \
+
+   This means that each NUMA machine has to use the same quantity of memory.
+
+#. Finally, run the ``start_qemu.sh`` script.
+
+
+.. _7160: https://download.clearlinux.org/releases/7160/
+.. _DPDK: http://dpdk.org
+.. _dpdk.org NICS: http://dpdk.org/doc/nics
+.. _pktgen tar package 2.9.12: http://dpdk.org/browse/apps/pktgen-dpdk/refs
+.. _DPDK guide: http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html
+.. _Pktgen documentation: `Pktgen documentation`_ https://media.readthedocs.org/pdf/pktgen/latest/pktgen.pdf

source/advanced/index.rst

@@ -5,11 +5,11 @@ Advanced configuration
    :maxdepth: 2
 
    clear-containers
-   network_boot
-   bulk_provisioning
+   network-boot
+   bulk-provisioning
    mixer
-   ac-dpdk
-   ac-ovs-dpdk
-   validate_sigs
+   dpdk
+   ovs-dpdk
+   validate-signs
    clear_linux_os_on_azure
 

source/advanced/mixer.rst

@@ -1,254 +1,254 @@
-.. _mixer_tool:
-
-Mixer Tool
-##########
-
-*Mixing* refers to composing an operating system for specific use cases.
-While the default Clear Linux* OS for Intel® Architecture provides options to install 
-bundles for various server capabilities, some developers may wish to 1) augment the 
-operating system itself with functionality from their own packages or 2) modify the 
-structure of current bundles to cater to their particular needs.
-
-
-Current Workflow
-================
-
-Prerequisites
--------------
-
-To start working with the Mixer tools, you'll need a recent image of Clear Linux OS for Intel Architecture
-with the following bundle installed. If you don't have it already,
-you can add it with the :command:`swupd bundle-add` command like so::
-
-  # swupd bundle-add mixer
-
-Mixing
-------
-
-#. **Create a workspace**. Create an empty directory in your Clear image to
-   use as a "workspace" for mixing. For these steps, we assume your workspace
-   location is :file:`/home/clr/mix`.
-
-#. **Configure builder.conf**. Copy the template conf file::
-
-    # cp /usr/share/defaults/bundle-chroot-builder/builder.conf /home/clr/mix/
-
-   The file ``builder.conf`` will be read automatically from the current workspace directory,
-   but all of the scripts accept a ``-c/--config`` option to specify where
-   the file is if you want to store it elsewhere. To use one in your current workspace,
-   copy the template to /home/clr/mix.
-   The :file:`.yum-mix.conf` file will be auto-generated for you, as will the :file:`ClearLinuxRoot.pem`. A yum configuration is needed for the chroot-builder to know where the RPMs are hosted, and the certificate file is needed to sign the root Manifest to provide security for content verification.
-
-   Note there are different sections to the builder.conf. The ``[Builder]`` section
-   provides the mixer tools with required configuration options, defining where
-   generated bundles and update metadata should get published. The ``[swupd]`` section
-   is used by swupd-server to create an update with specific update parameters.
-
-   Edit the template configuration file according to your needs. For this example,
-   your ``builder.conf`` should look like this, with the ``VER`` replaced by valid build
-   numbers, and both *URL variables set to the domain or IP of the update server::
-
-      # vim /etc/bundle-chroot-builder/builder.conf:
-
-      [Builder]
-      SERVER_STATE_DIR=/home/clr/mix/update
-      BUNDLE_DIR=/home/clr/mix/mix-bundles
-      YUM_CONF=/home/clr/mix/.yum-mix.conf
-      CERT=/home/clr/mix/ClearLinuxRoot.pem
-      CLEAR_VERSION=VER
-      MIX_VERSION=VER
-
-      [swupd]
-      BUNDLE=os-core-update
-      CONTENTURL=<URL where the content will be hosted>
-      VERSIONURL=<URL where the version of the mix will be hosted>
-      FORMAT=1
-
-
-   The SERVER_STATE_DIR is where the mix content will be outputted to, and it is automatically created for you by the mixer scripts. This can be set to any location, but for this example let us use the workspace directory. The same applies for BUNDLE_DIR; it will be generated for you in the location specified in the builder.conf, in this case - /home/clr/mix/mix-bundles. It is where the bundle definitions are stored for your mix, and where the chroot-builder looks in to know what bundles must be installed.
-
-   You may change the ``CERT=/path/to/cert`` line, which tells the chroot builder to insert the certificate
-   specified for the mix in ``/os-core-update/usr/share/clear/update-ca/``. This is the certificate used by 
-   the software update client to verify the Manifest.MoM signature. For now, it is `HIGHLY` recommended that 
-   you do not modify this line, as the certificate swupd expects needs a very specific configuration to sign 
-   and verify properly. The certificate will be automatically generated for you, and the Manifest.MoM will 
-   be signed automatically as well, providing security for the update content you create.
-
-   The CLEAR_VERSION is the upstream Clear Linux* OS for Intel® Architecture version that the mix will be based 
-   off of, and all required content (RPMs) not provided by the mixer will be downloaded from that release.
-   The MIX_VERSION is the version you want your mix to be.
-
-   For this example, set CLEAR_VERSION=11580 and MIX_VERSION=10. You can of course choose any numbers you like 
-   for the MIX_VERSION, but it is recommended to use the current latest version of upstream for the CLEAR_VERSION. 
-   The CLEAR_VERSION can be updated as new upstream versions are released if needed.
-
-   The CONTENTURL and VERSIONURL may be an IP address, or a domain name, which hosts the /home/clr/mix/update/www (SERVER_STATE_DIR) directory. Creating a symlink to the directory in your server webdir is an easy way to host the content. A client running the mix will look to that URL to figure out if there is a new version available, 
-   and where to download update content from.
-
-   To learn more about the FORMAT option, please refer to the bottom of this document "Format Version" and 
-   https://github.com/clearlinux/swupd-server/wiki/Format-Bumps. For now leave the FORMAT 
-   value alone and do not increment it.
-
-#. **Generate the starting point for your Mix**. In your workspace, run::
-   
-     # sudo mixer-init-mix.sh
-
-   *If you wish to just build a mix that includes all Clear bundles with no modifications, run*::
-
-    # sudo mixer-init-mix.sh --all-bundles
-   And skip to ``Creating an image``. All the required content will be automatically built, and this mix
-   will be identical to the version of Clear it is being composed from.
-
-#. **Create/locate RPMs for mix.**. (Steps 4-6 are necessary only if you
-   want to add your own RPMs to the Mix. If you are working only with Clear
-   bundles, then skip to Step 7.)
-
-   If you are creating RPMs from scratch, you may use ``autospec``,
-   ``mock``, ``rpmbuild``, etc. to build them. If they are not
-   built on Clear, make sure your configuration and toolchain builds them correctly for Clear.
-
-#. **Import RPMs into workspace**. The way to do this is to create an
-   ``rpms`` directory in your workspace (for example ``/home/clr/mix/rpms``),
-   and to copy the RPMs you want into that directory. The mixer script will
-   look here for RPMs in order to build a local RPM repo for yum to use.
-
-#. **Create a local RPM repo**. Create an empty directory in your workspace
-   named ``local`` and add the paths in your builder.conf::
-
-    RPMDIR=/home/clr/mix/rpms
-    REPODIR=/home/clr/mix/local
-
-    These variables are automatically read; you simply need to run::
-
-    # sudo mixer-add-rpms.sh
-
-   After the script exits, you should see your RPMs and a repodata directory in
-   ``/home/clr/mix/local``. If the RPMs are not all in the local directory, check
-   to make sure that they are indeed valid RPM files and not corrupt.
-
-#. **Update/Add bundle definitions**. The mixer uses a local clone of the
-   ``clr-bundles`` repo to define bundles for the mix.
-
-   To define your bundles:
-      #. Navigate to the ``mix-bundles/`` directory.
-      #. Make any needed modifications to the bundle set.
-      #. Commit the result::
-         
-         $ git add .
-         $ git commit -s -m 'Update bundles for mix #<VER>'
-
-   You can easily copy bundles over from the ``clr-bundles/bundles`` directory in
-   the case that you want to simply use existing bundle sets. Note that
-   ``mix-bundles`` should not have any folders inside of it, only bundle definitions.
-   Do *not* modify things in the clr-bundles dir, this is simply a mirror for you to
-   use or refer to the Clear Linux OS bundle definitions.
-
-   Why do this? With Git history, mixes are easy to revert to or refer
-   to in the future if something were to go wrong with a new mix. If
-   you're just testing this out, or if you really do not want to mess with Git,
-   you can ignore committing for now.
-
-   To add your own bundle, create a bundle definition file in ``mix-bundles/``
-   and refer to :file:`mix-bundles/os-core-update` for formatting, but be sure that
-   the name does not conflict with another bundle. Add your package
-   name(s) in that  bundle definition file to tell it what package(s)
-   must be installed as part of that bundle.
-
-#. **Build the bundle chroots** To build all of the ``chroots``
-   that are based on the bundles you defined, in your workspace run::
-   
-    # sudo mixer-build-chroots.sh
-
-   If you have many bundles defined for your mix, this step may take some time.
-
-#. **Create update**. In the workspace, run::
-
-    # sudo mixer-create-update.sh
-
-   When the script completes, you'll find your mix update content under
-   ``/home/clr/mix/update/www/VER``, in this example, it will be located in
-   ``/home/clr/mix/update//www/<MIXVERSION>``, where <MIXVERSION> is the mix version you
-   defined, or 10 by default.
-
-   All content to make a fully usable mix will be created by this step, but note that 
-   only zero packs are automatically generated. To create optional delta packs, run 
-   the pack-maker as follows::
-
-    # sudo mixer-pack-maker.sh --to <MIX_VERSION> --from <PAST_VERSION> -S /home/clr/mix/update
-
-   The pack-maker will generate all delta packs for changed bundles from PAST_VERSION 
-   to MIX_VERSION. If your STATE_DIR is in a different location be sure to specify where 
-   with the -S option.
-   For the first build, no delta packs can be created because the "update" is from version 0, which impicitly has no content, thus no deltas can be generated. For subsequent builds, mixer-pack-maker.sh can be run to generate delta content between them (i.e 10 to 20).
-
-#. **Creating an image**
-To create a bootable image from your update content, you will need the configuration file for
-ister to create images::
-
-    # curl -O https://raw.githubusercontent.com/clearlinux/ister/master/release-image-config.json
-
-Edit this to include  all the bundles you want pre-installed into your image. For a minimal, base
-image this would be::
-
-    "Bundles": ["os-core", "os-core-update", "kernel-native"]
-
-And lastly, set the "Version:" to say which mix version content the image should be built from,
-i.e. 10 for your first build. To build the image, run::
-
-    # sudo ister.py -t release-image-config.json -V file:///home/clr/mix/update/www/ -C file:///home/clr/mix/update/www/ -f 1
-
-The output from this should be an image that is bootable as a VM or installable to baremetal. *Note* that 
-you may need to pass in -f/--format <FORMAT_NUMBER> if the format you are building is different than the
-format of Clear Linux OS you are currently building on. Format version can be found via::
-    # cat /usr/share/defaults/swupd/format
-
-Creating your next Mix version
-#. **Initialize next Mix version info**. To update the versions and prep for your
-   next mix::
-
-   Update the MIX_VERSION in your builder.conf to the next version number you want to build. 
-   From this point you can iterate through, starting again at step 4 and doing modifications 
-   as needed. For example:
-
-   - Add/Remove/Modify Bundles
-   - sudo mixer-build-chroots.sh
-   - sudo mixer-create-update.sh
-   - (Optionally) sudo mixer-pack-maker.sh --to <NEWVERSION> --from <PREV_VERSION> -S /home/clr/mix/update
-   Next mix created.
-
-#. **Update Bundles (Optional)**.  Update ``clr-bundles``.  In the workspace,
-   run::
-
-    # sudo mixer-update-bundles.sh
-
-   This step is optional because the script is already called by mixer-init-mix.sh,
-   and only needs to be called again when you want to update the upstream clr-bundles
-   folder in your workspace. It also does not need to be called unless you are updating
-   the CLEAR_VERSION number as well to match the newest upstream release.
-
-
-
-Format Version
---------------------------
-
-The "format" used in ``builder.conf`` might be more precisely referred to as an
-OS "compatibility epoch". Versions of the OS within a given epoch are fully
-compatible with themselves and can update to any version in that epoch. Across
-the format boundary *something* has changed in the OS, such that updating from
-build M in format X, to build N in format Y will not work. Generally this occurs
-when the software updater or manifests changed in a way that is no longer
-compatible with the previous update scheme.
-
-A format increment is the way we insure pre- and co-requisite
-changes flow out with proper ordering. The update client will only ever update
-to the latest release in its respective format version (unless overridden by
-command line flags), thus we can guarantee all clients will update to the final
-version in their given format, which *must* contain all the changes needed
-to understand the content built in the following format. Only after reaching the
-final release in the old format will a client be able to continue to update to
-releases in the new format.
-
-For the creation of a custom mix, the format version should start at '1',
-or some known number, and increment only when a compatibility breakage is
-introduced. Normal updates (updating a software package for example)
-do not require a format increment.
+.. _mixer_tool:
+
+Mixer Tool
+##########
+
+*Mixing* refers to composing an operating system for specific use cases.
+While the default Clear Linux* OS for Intel® Architecture provides options to install 
+bundles for various server capabilities, some developers may wish to 1) augment the 
+operating system itself with functionality from their own packages or 2) modify the 
+structure of current bundles to cater to their particular needs.
+
+
+Current Workflow
+================
+
+Prerequisites
+-------------
+
+To start working with the Mixer tools, you'll need a recent image of Clear Linux OS for Intel Architecture
+with the following bundle installed. If you don't have it already,
+you can add it with the :command:`swupd bundle-add` command like so::
+
+  # swupd bundle-add mixer
+
+Mixing
+------
+
+#. **Create a workspace**. Create an empty directory in your Clear image to
+   use as a "workspace" for mixing. For these steps, we assume your workspace
+   location is :file:`/home/clr/mix`.
+
+#. **Configure builder.conf**. Copy the template conf file::
+
+    # cp /usr/share/defaults/bundle-chroot-builder/builder.conf /home/clr/mix/
+
+   The file ``builder.conf`` will be read automatically from the current workspace directory,
+   but all of the scripts accept a ``-c/--config`` option to specify where
+   the file is if you want to store it elsewhere. To use one in your current workspace,
+   copy the template to /home/clr/mix.
+   The :file:`.yum-mix.conf` file will be auto-generated for you, as will the :file:`ClearLinuxRoot.pem`. A yum configuration is needed for the chroot-builder to know where the RPMs are hosted, and the certificate file is needed to sign the root Manifest to provide security for content verification.
+
+   Note there are different sections to the builder.conf. The ``[Builder]`` section
+   provides the mixer tools with required configuration options, defining where
+   generated bundles and update metadata should get published. The ``[swupd]`` section
+   is used by swupd-server to create an update with specific update parameters.
+
+   Edit the template configuration file according to your needs. For this example,
+   your ``builder.conf`` should look like this, with the ``VER`` replaced by valid build
+   numbers, and both *URL variables set to the domain or IP of the update server::
+
+      # vim /etc/bundle-chroot-builder/builder.conf:
+
+      [Builder]
+      SERVER_STATE_DIR=/home/clr/mix/update
+      BUNDLE_DIR=/home/clr/mix/mix-bundles
+      YUM_CONF=/home/clr/mix/.yum-mix.conf
+      CERT=/home/clr/mix/ClearLinuxRoot.pem
+      CLEAR_VERSION=VER
+      MIX_VERSION=VER
+
+      [swupd]
+      BUNDLE=os-core-update
+      CONTENTURL=<URL where the content will be hosted>
+      VERSIONURL=<URL where the version of the mix will be hosted>
+      FORMAT=1
+
+
+   The SERVER_STATE_DIR is where the mix content will be outputted to, and it is automatically created for you by the mixer scripts. This can be set to any location, but for this example let us use the workspace directory. The same applies for BUNDLE_DIR; it will be generated for you in the location specified in the builder.conf, in this case - /home/clr/mix/mix-bundles. It is where the bundle definitions are stored for your mix, and where the chroot-builder looks in to know what bundles must be installed.
+
+   You may change the ``CERT=/path/to/cert`` line, which tells the chroot builder to insert the certificate
+   specified for the mix in ``/os-core-update/usr/share/clear/update-ca/``. This is the certificate used by 
+   the software update client to verify the Manifest.MoM signature. For now, it is `HIGHLY` recommended that 
+   you do not modify this line, as the certificate swupd expects needs a very specific configuration to sign 
+   and verify properly. The certificate will be automatically generated for you, and the Manifest.MoM will 
+   be signed automatically as well, providing security for the update content you create.
+
+   The CLEAR_VERSION is the upstream Clear Linux* OS for Intel® Architecture version that the mix will be based 
+   off of, and all required content (RPMs) not provided by the mixer will be downloaded from that release.
+   The MIX_VERSION is the version you want your mix to be.
+
+   For this example, set CLEAR_VERSION=11580 and MIX_VERSION=10. You can of course choose any numbers you like 
+   for the MIX_VERSION, but it is recommended to use the current latest version of upstream for the CLEAR_VERSION. 
+   The CLEAR_VERSION can be updated as new upstream versions are released if needed.
+
+   The CONTENTURL and VERSIONURL may be an IP address, or a domain name, which hosts the /home/clr/mix/update/www (SERVER_STATE_DIR) directory. Creating a symlink to the directory in your server webdir is an easy way to host the content. A client running the mix will look to that URL to figure out if there is a new version available, 
+   and where to download update content from.
+
+   To learn more about the FORMAT option, please refer to the bottom of this document "Format Version" and 
+   https://github.com/clearlinux/swupd-server/wiki/Format-Bumps. For now leave the FORMAT 
+   value alone and do not increment it.
+
+#. **Generate the starting point for your Mix**. In your workspace, run::
+   
+     # sudo mixer-init-mix.sh
+
+   *If you wish to just build a mix that includes all Clear bundles with no modifications, run*::
+
+    # sudo mixer-init-mix.sh --all-bundles
+   And skip to ``Creating an image``. All the required content will be automatically built, and this mix
+   will be identical to the version of Clear it is being composed from.
+
+#. **Create/locate RPMs for mix.**. (Steps 4-6 are necessary only if you
+   want to add your own RPMs to the Mix. If you are working only with Clear
+   bundles, then skip to Step 7.)
+
+   If you are creating RPMs from scratch, you may use ``autospec``,
+   ``mock``, ``rpmbuild``, etc. to build them. If they are not
+   built on Clear, make sure your configuration and toolchain builds them correctly for Clear.
+
+#. **Import RPMs into workspace**. The way to do this is to create an
+   ``rpms`` directory in your workspace (for example ``/home/clr/mix/rpms``),
+   and to copy the RPMs you want into that directory. The mixer script will
+   look here for RPMs in order to build a local RPM repo for yum to use.
+
+#. **Create a local RPM repo**. Create an empty directory in your workspace
+   named ``local`` and add the paths in your builder.conf::
+
+    RPMDIR=/home/clr/mix/rpms
+    REPODIR=/home/clr/mix/local
+
+    These variables are automatically read; you simply need to run::
+
+    # sudo mixer-add-rpms.sh
+
+   After the script exits, you should see your RPMs and a repodata directory in
+   ``/home/clr/mix/local``. If the RPMs are not all in the local directory, check
+   to make sure that they are indeed valid RPM files and not corrupt.
+
+#. **Update/Add bundle definitions**. The mixer uses a local clone of the
+   ``clr-bundles`` repo to define bundles for the mix.
+
+   To define your bundles:
+      #. Navigate to the ``mix-bundles/`` directory.
+      #. Make any needed modifications to the bundle set.
+      #. Commit the result::
+         
+         $ git add .
+         $ git commit -s -m 'Update bundles for mix #<VER>'
+
+   You can easily copy bundles over from the ``clr-bundles/bundles`` directory in
+   the case that you want to simply use existing bundle sets. Note that
+   ``mix-bundles`` should not have any folders inside of it, only bundle definitions.
+   Do *not* modify things in the clr-bundles dir, this is simply a mirror for you to
+   use or refer to the Clear Linux OS bundle definitions.
+
+   Why do this? With Git history, mixes are easy to revert to or refer
+   to in the future if something were to go wrong with a new mix. If
+   you're just testing this out, or if you really do not want to mess with Git,
+   you can ignore committing for now.
+
+   To add your own bundle, create a bundle definition file in ``mix-bundles/``
+   and refer to :file:`mix-bundles/os-core-update` for formatting, but be sure that
+   the name does not conflict with another bundle. Add your package
+   name(s) in that  bundle definition file to tell it what package(s)
+   must be installed as part of that bundle.
+
+#. **Build the bundle chroots** To build all of the ``chroots``
+   that are based on the bundles you defined, in your workspace run::
+   
+    # sudo mixer-build-chroots.sh
+
+   If you have many bundles defined for your mix, this step may take some time.
+
+#. **Create update**. In the workspace, run::
+
+    # sudo mixer-create-update.sh
+
+   When the script completes, you'll find your mix update content under
+   ``/home/clr/mix/update/www/VER``, in this example, it will be located in
+   ``/home/clr/mix/update//www/<MIXVERSION>``, where <MIXVERSION> is the mix version you
+   defined, or 10 by default.
+
+   All content to make a fully usable mix will be created by this step, but note that 
+   only zero packs are automatically generated. To create optional delta packs, run 
+   the pack-maker as follows::
+
+    # sudo mixer-pack-maker.sh --to <MIX_VERSION> --from <PAST_VERSION> -S /home/clr/mix/update
+
+   The pack-maker will generate all delta packs for changed bundles from PAST_VERSION 
+   to MIX_VERSION. If your STATE_DIR is in a different location be sure to specify where 
+   with the -S option.
+   For the first build, no delta packs can be created because the "update" is from version 0, which impicitly has no content, thus no deltas can be generated. For subsequent builds, mixer-pack-maker.sh can be run to generate delta content between them (i.e 10 to 20).
+
+#. **Creating an image**
+To create a bootable image from your update content, you will need the configuration file for
+ister to create images::
+
+    # curl -O https://raw.githubusercontent.com/clearlinux/ister/master/release-image-config.json
+
+Edit this to include  all the bundles you want pre-installed into your image. For a minimal, base
+image this would be::
+
+    "Bundles": ["os-core", "os-core-update", "kernel-native"]
+
+And lastly, set the "Version:" to say which mix version content the image should be built from,
+i.e. 10 for your first build. To build the image, run::
+
+    # sudo ister.py -t release-image-config.json -V file:///home/clr/mix/update/www/ -C file:///home/clr/mix/update/www/ -f 1
+
+The output from this should be an image that is bootable as a VM or installable to baremetal. *Note* that 
+you may need to pass in -f/--format <FORMAT_NUMBER> if the format you are building is different than the
+format of Clear Linux OS you are currently building on. Format version can be found via::
+    # cat /usr/share/defaults/swupd/format
+
+Creating your next Mix version
+#. **Initialize next Mix version info**. To update the versions and prep for your
+   next mix::
+
+   Update the MIX_VERSION in your builder.conf to the next version number you want to build. 
+   From this point you can iterate through, starting again at step 4 and doing modifications 
+   as needed. For example:
+
+   - Add/Remove/Modify Bundles
+   - sudo mixer-build-chroots.sh
+   - sudo mixer-create-update.sh
+   - (Optionally) sudo mixer-pack-maker.sh --to <NEWVERSION> --from <PREV_VERSION> -S /home/clr/mix/update
+   Next mix created.
+
+#. **Update Bundles (Optional)**.  Update ``clr-bundles``.  In the workspace,
+   run::
+
+    # sudo mixer-update-bundles.sh
+
+   This step is optional because the script is already called by mixer-init-mix.sh,
+   and only needs to be called again when you want to update the upstream clr-bundles
+   folder in your workspace. It also does not need to be called unless you are updating
+   the CLEAR_VERSION number as well to match the newest upstream release.
+
+
+
+Format Version
+--------------------------
+
+The "format" used in ``builder.conf`` might be more precisely referred to as an
+OS "compatibility epoch". Versions of the OS within a given epoch are fully
+compatible with themselves and can update to any version in that epoch. Across
+the format boundary *something* has changed in the OS, such that updating from
+build M in format X, to build N in format Y will not work. Generally this occurs
+when the software updater or manifests changed in a way that is no longer
+compatible with the previous update scheme.
+
+A format increment is the way we insure pre- and co-requisite
+changes flow out with proper ordering. The update client will only ever update
+to the latest release in its respective format version (unless overridden by
+command line flags), thus we can guarantee all clients will update to the final
+version in their given format, which *must* contain all the changes needed
+to understand the content built in the following format. Only after reaching the
+final release in the old format will a client be able to continue to update to
+releases in the new format.
+
+For the creation of a custom mix, the format version should start at '1',
+or some known number, and increment only when a compatibility breakage is
+introduced. Normal updates (updating a software package for example)
+do not require a format increment.

source/advanced/ovs-dpdk.rst

@@ -1,327 +1,327 @@
-.. _ac-ovs-dpdk:
-
-OpenvSwitch and DPDK
-####################
-
-Introduction
-============
-
-Enabling `DPDK`_ support on the **OpenvSwitch project** can yield significant
-network performance improvements. To illustrate one such example, we'll 
-cover a simple use case with :ref:`f1ovs`, where one virtual machine sends
-1,000,000 HTTP requests to another virtual machine using 
-* *Linux bridges**
-* **OpenvSwitch bridges**
-* And custom-built **OpenvSwitch-DPDK bridges** as the network link.
-
-.. _f1ovs:
-
-.. figure:: _static/images/use_case.png
-
-   Figure 1: Basic virtual network environment.
-
-**Requirements:**
-
-To follow along with this example, you will need:
-
-* At least one platform using Clear Linux* OS for Intel® Architecture 
-  (recommended release >= ``7160``) as Host,
-* The ``kernel-native`` bundle enabled on that particular Host, 
-* And the ``network-advanced``, and ``os-clr-on-clr`` bundles installed.
-
- .. code-block:: bash
-	
-		# swupd bundle-add network-advanced os-clr-on-clr
-
-You'll also need two `kvm`_ images (recommended release  >= ``7160``).
-These images will create the guest virtual machines A and B. These virtual machines
-must also have ``network-basic`` and ``lamp-basic`` bundles installed.
- 
- .. code-block:: bash
-
-    # swupd bundle-add network-basic lamp-basic
-
-
-Using Linux Bridges
-===================
-
-#. Create a script named **qemu-ifup** for a linux bridge in a virtual machine.
-
-   .. code-block:: bash
-
-      #!/bin/bash
-	    set -x
-	    switch=br0
-	     if [ -n "$1" ];then
-	     	tunctl -u whoami -t $1
-	     	ip link set $1 up
-	     	sleep 0.5s
-	     	brctl addif $switch $1
-	     	exit 0
-	     else
-	        echo "Error: no interface specified"
-	        exit 1
-	     fi
-	
-#. Enable execute permission on the script, preserving its group permissions with
-   respect to other files.
-
-   .. code-block:: bash
-
-      # chmod a+x qemu-ifup
-
-#. Create a bridge using the OpenvSwitch tool; you can verify whether the bridge
-   was successfully created by using ip tool.
-
-   .. code-block:: bash
-
-      # brctl addbr br0
-
- Note: At this point, you have the option to add a NIC with ``brctl addif br0 <network interface>``.  Sample interface below should be replaced with your local
- NIC's designation.
-
-.. code-block:: bash
-
-   # brctl addif br0 enp3s0f0
-
-When the above option is used, and the NIC is connected to DHCP server, so Steps
-1 and 2 under the `Setting IP address`_ section.
-
-#. Set up the Linux bridge.
-
-   .. code-block:: bash
-
-      # ip link set dev br0 up
-
-#. Run guest virtual machine A using the next configuration as reference, where
-   the **$IMAGE** var is the Clear Linux image name.
-
-   .. code-block:: bash
-
-	  qemu-system-x86_64 \
-	    -enable-kvm -m 1024 \
-	    -bios OVMF.fd \
-	    -smp cpus=2,cores=1 -cpu host \
-	    -vga none -nographic \
-	    -drive file="$IMAGE",if=virtio,aio=threads \
-	    -net nic,macaddr=00:11:22:33:44:55,model=virtio -net tap,script=qemu-ifup \
-	    -debugcon file:debug.log -global isa-debugcon.iobase=0x402
-
-
-#. Run guest virtual machine B using the configuration from the previous step; 
-   take care to update the MAC address.
-
-#. Follow the instructions from the `Setting IP Address`_ section.
-
-#. And to clean the previous environment, turn off the virtual machines and delete
-   the bridge.
-
-   .. code-block:: bash
-
-	  # ip link set dev br0 down
-	  # brctl delbr br0
-
-
-Using OpenvSwitch
-=================
-
-#. Start the OpenvSwitch service.
-
-   .. code-block:: bash
-
-      # systemctl start openvswitch.service
-
-#. Create a bridge using the OpenvSwitch tool; you can verify whether or not the
-   bridge was successfully created by running ip tool.
-
-   .. code-block:: bash
-
-	  # ovs-vsctl add-br br0
-	  # ip a
-
-#. Create **UP-DOWN** scripts which can bring up the tap devices through the
-   bridge we created in Step 2. 
-
-   The **ovs-ifdown** script should look something like:
-
-   .. code-block:: bash
-
-	  #!/bin/sh
-	   switch="br0"
-	   /usr/bin/ifconfig $1 0.0.0.0 down
-	   ovs-vsctl del-port ${switch} $1
-
-   And the **ovs-ifup script** should look something like:
-
-   .. code-block:: bash
-
-	  #!/bin/sh
-	   switch="br0"
-	   /usr/bin/ifconfig $1 0.0.0.0 up
-	   ovs-vsctl add-port ${switch} $1
-
-#. Enable execute permission on the scripts, preserving their group permissions
-   with respect to other files.
-
-   .. code-block:: bash
-
-	  # chmod a+x ovs-ifdown
-	  # chmod a+x ovs-ifup
-
-#. Run guest virtual machine A using the next configuration as reference, where
-   **$IMAGE** var is the name of the Clear Linux* OS for Intel Architecture image. 
-   Notice the network configuration uses the up-down scripts.
-
-   .. code-block:: bash
-
-      qemu-system-x86_64 \
-          -enable-kvm -m 1024 \
-          -bios OVMF.fd \
-          -smp cpus=2,cores=1 -cpu host \
-          -vga none -nographic \
-          -drive file="$IMAGE",if=virtio,aio=threads \
-          -net nic,model=virtio,macaddr=00:11:22:33:44:55 -net tap,script=ovs-ifup,downscript=ovs-ifdown \
-          -debugcon file:debug.log -global isa-debugcon.iobase=0x402
-
-#. Run guest virtual machine B using the configuration from step 5, only
-   it's necessary to change the MAC address to something like *00:11:22:33:44:56*
-
-#. Follow the instructions in the `Setting IP address`_ section.
-
-
-Using Linux OpenvSwitch-DPDK
-============================
-
-#. Create a new environment and add **iommu=pt intel_iommu=on**  to the kernel
-   command line.
-
-   .. code-block:: bash
-
-      # systemctl start boot.mount
-      # cd /boot/loader/entries/
-
-#. Edit :file:`clear-linux-native-<kernel-version>.conf`, and add 
-   **iommu=pt intel_iommu=on** to the end of the line.  
-
-#. Then ``umount`` and reboot the machine.
-   
-   .. code-block:: bash
-
-      # cd /
-      # systemctl stop boot.mount
-      # reboot
-    
-#. Set number of hugepages.
-
-   .. code-block:: bash
-
-	  # echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
-
-#. Allocate pages on NUMA machines.
-
-   .. code-block:: bash
-
-	  # echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
-	  # echo 1024 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
-
-#. Making memory available for DPDK.
-
-   .. code-block:: bash
-
-	  # mkdir -p /mnt/huge
-	  # mount -t hugetlbfs nodev /mnt/huge
-
-#. Add cores and memory configuration to the OpenvSwitch example; the
-   :file:`/usr/share/openvswitch/scripts/ovs-ctl` file can be edited on line 256
-   and DPDK configuration can be added. 
-
-   It should look something like:  
-   ``set ovs-vswitchd --dpdk -c 0x2 -n 4 --socket-mem 2048 -- unix:"$DB_SOCK"``
-
-   The next regular expression could be helpful:
-
-   .. code-block:: bash
-
-      # sed -i s/"set ovs-vswitchd unix:"/"set ovs-vswitchd --dpdk -c 0x2 -n 4 --socket-mem 2048 -- unix:"/g /usr/share/openvswitch/scripts/ovs-ctl
-
-#. Start the OpenvSwitch service:
-   
-   .. code-block:: bash
-
-      # systemctl start openvswitch.service
-
-#. Create a virtual bridge using openvswitch:
-   
-   .. code-block:: bash
-
-	  # ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
-
-#. Add dpdk ports to the bridge:
-   
-   .. code-block:: bash
-
-      # ovs-vsctl add-port br0 vhost-user1 -- set Interface vhost-user1 type=dpdkvhostuser
-	  # ovs-vsctl add-port br0 vhost-user2 -- set Interface vhost-user2 type=dpdkvhostuser
-
-#. Run guest virtual machine A using the next configuration as reference, where
-   **$IMAGE** var is the name of the Clear Linux* OS for Intel Architecture image.
-
-   .. code-block:: bash
- 
-      qemu-system-x86_64 \
-          -enable-kvm -m 1024 \
-          -bios OVMF.fd \
-          -smp 4 -cpu host \
-          -vga none -nographic \
-          -drive file="$IMAGE",if=virtio,aio=threads \
-          -chardev socket,id=char1,path=/run/openvswitch/vhost-user1 \
-          -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce \
-          -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1 \
-          -object memory-backend-file,id=mem,size=1024M,mem-path=/dev/ hugepages,share=on \
-          -numa node,memdev=mem -mem-prealloc \
-          -debugcon file:debug.log -global isa-debugcon.iobase=0x402
-
-#. Run guest virtual machine B, use the configuration from the previous step; 
-   simply change the MAC address and the port socket. You can use 00:00:00:00:00:02 as a 
-   MAC address and vhost-user2 as a socket.
-
-#. Follow the instructions from the `Setting IP address`_ section.
-
-
-
-.. _Setting IP address:
-
-Setting IP address
-==================
-
-#. Set an IP address to virtual machine for virtual machine A:
-   
-   .. code-block:: bash
-
-      # ip addr add dev enp0s2 10.0.0.5/24
-
-   for virtual machine B:
-
-   .. code-block:: bash
-
-      # ip addr add dev enp0s2 10.0.0.6/24
-
-#. Check if there is communication between both virtual machines using ping tool.
-
-#. Verify that Apache service is running:
-
-   .. code-block:: bash
-
-      # systemctl status httpd.service
-      # systemctl start httpd.service 
-
-   Start httpd service only if it is inactive. Use apache benchmark to get
-   information about the network performance between both virtual machines.
-
-   .. code-block:: bash
-
-      # ab -n 1000000 -c 100 http://10.0.0.6/
-
-
-.. _DPDK: http://dpdk.org/
-.. _kvm: https://download.clearlinux.org/releases/
+.. _ac-ovs-dpdk:
+
+OpenvSwitch and DPDK
+####################
+
+Introduction
+============
+
+Enabling `DPDK`_ support on the **OpenvSwitch project** can yield significant
+network performance improvements. To illustrate one such example, we'll
+cover a simple use case with :ref:`f1ovs`, where one virtual machine sends
+1,000,000 HTTP requests to another virtual machine using
+* *Linux bridges**
+* **OpenvSwitch bridges**
+* And custom-built **OpenvSwitch-DPDK bridges** as the network link.
+
+.. _f1ovs:
+
+.. figure:: ../_static/images/advanced/use_case.png
+
+   Figure 1: Basic virtual network environment.
+
+**Requirements:**
+
+To follow along with this example, you will need:
+
+* At least one platform using Clear Linux* OS for Intel® Architecture
+  (recommended release >= ``7160``) as Host,
+* The ``kernel-native`` bundle enabled on that particular Host,
+* And the ``network-advanced``, and ``os-clr-on-clr`` bundles installed.
+
+ .. code-block:: bash
+
+		# swupd bundle-add network-advanced os-clr-on-clr
+
+You'll also need two `kvm`_ images (recommended release  >= ``7160``).
+These images will create the guest virtual machines A and B. These virtual machines
+must also have ``network-basic`` and ``lamp-basic`` bundles installed.
+
+ .. code-block:: bash
+
+    # swupd bundle-add network-basic lamp-basic
+
+
+Using Linux Bridges
+===================
+
+#. Create a script named **qemu-ifup** for a linux bridge in a virtual machine.
+
+   .. code-block:: bash
+
+      #!/bin/bash
+	    set -x
+	    switch=br0
+	     if [ -n "$1" ];then
+	     	tunctl -u whoami -t $1
+	     	ip link set $1 up
+	     	sleep 0.5s
+	     	brctl addif $switch $1
+	     	exit 0
+	     else
+	        echo "Error: no interface specified"
+	        exit 1
+	     fi
+
+#. Enable execute permission on the script, preserving its group permissions with
+   respect to other files.
+
+   .. code-block:: bash
+
+      # chmod a+x qemu-ifup
+
+#. Create a bridge using the OpenvSwitch tool; you can verify whether the bridge
+   was successfully created by using ip tool.
+
+   .. code-block:: bash
+
+      # brctl addbr br0
+
+ Note: At this point, you have the option to add a NIC with ``brctl addif br0 <network interface>``.  Sample interface below should be replaced with your local
+ NIC's designation.
+
+.. code-block:: bash
+
+   # brctl addif br0 enp3s0f0
+
+When the above option is used, and the NIC is connected to DHCP server, so Steps
+1 and 2 under the `Setting IP address`_ section.
+
+#. Set up the Linux bridge.
+
+   .. code-block:: bash
+
+      # ip link set dev br0 up
+
+#. Run guest virtual machine A using the next configuration as reference, where
+   the **$IMAGE** var is the Clear Linux image name.
+
+   .. code-block:: bash
+
+	  qemu-system-x86_64 \
+	    -enable-kvm -m 1024 \
+	    -bios OVMF.fd \
+	    -smp cpus=2,cores=1 -cpu host \
+	    -vga none -nographic \
+	    -drive file="$IMAGE",if=virtio,aio=threads \
+	    -net nic,macaddr=00:11:22:33:44:55,model=virtio -net tap,script=qemu-ifup \
+	    -debugcon file:debug.log -global isa-debugcon.iobase=0x402
+
+
+#. Run guest virtual machine B using the configuration from the previous step;
+   take care to update the MAC address.
+
+#. Follow the instructions from the `Setting IP Address`_ section.
+
+#. And to clean the previous environment, turn off the virtual machines and delete
+   the bridge.
+
+   .. code-block:: bash
+
+	  # ip link set dev br0 down
+	  # brctl delbr br0
+
+
+Using OpenvSwitch
+=================
+
+#. Start the OpenvSwitch service.
+
+   .. code-block:: bash
+
+      # systemctl start openvswitch.service
+
+#. Create a bridge using the OpenvSwitch tool; you can verify whether or not the
+   bridge was successfully created by running ip tool.
+
+   .. code-block:: bash
+
+	  # ovs-vsctl add-br br0
+	  # ip a
+
+#. Create **UP-DOWN** scripts which can bring up the tap devices through the
+   bridge we created in Step 2.
+
+   The **ovs-ifdown** script should look something like:
+
+   .. code-block:: bash
+
+	  #!/bin/sh
+	   switch="br0"
+	   /usr/bin/ifconfig $1 0.0.0.0 down
+	   ovs-vsctl del-port ${switch} $1
+
+   And the **ovs-ifup script** should look something like:
+
+   .. code-block:: bash
+
+	  #!/bin/sh
+	   switch="br0"
+	   /usr/bin/ifconfig $1 0.0.0.0 up
+	   ovs-vsctl add-port ${switch} $1
+
+#. Enable execute permission on the scripts, preserving their group permissions
+   with respect to other files.
+
+   .. code-block:: bash
+
+	  # chmod a+x ovs-ifdown
+	  # chmod a+x ovs-ifup
+
+#. Run guest virtual machine A using the next configuration as reference, where
+   **$IMAGE** var is the name of the Clear Linux* OS for Intel Architecture image.
+   Notice the network configuration uses the up-down scripts.
+
+   .. code-block:: bash
+
+      qemu-system-x86_64 \
+          -enable-kvm -m 1024 \
+          -bios OVMF.fd \
+          -smp cpus=2,cores=1 -cpu host \
+          -vga none -nographic \
+          -drive file="$IMAGE",if=virtio,aio=threads \
+          -net nic,model=virtio,macaddr=00:11:22:33:44:55 -net tap,script=ovs-ifup,downscript=ovs-ifdown \
+          -debugcon file:debug.log -global isa-debugcon.iobase=0x402
+
+#. Run guest virtual machine B using the configuration from step 5, only
+   it's necessary to change the MAC address to something like *00:11:22:33:44:56*
+
+#. Follow the instructions in the `Setting IP address`_ section.
+
+
+Using Linux OpenvSwitch-DPDK
+============================
+
+#. Create a new environment and add **iommu=pt intel_iommu=on**  to the kernel
+   command line.
+
+   .. code-block:: bash
+
+      # systemctl start boot.mount
+      # cd /boot/loader/entries/
+
+#. Edit :file:`clear-linux-native-<kernel-version>.conf`, and add
+   **iommu=pt intel_iommu=on** to the end of the line.
+
+#. Then ``umount`` and reboot the machine.
+
+   .. code-block:: bash
+
+      # cd /
+      # systemctl stop boot.mount
+      # reboot
+
+#. Set number of hugepages.
+
+   .. code-block:: bash
+
+	  # echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
+
+#. Allocate pages on NUMA machines.
+
+   .. code-block:: bash
+
+	  # echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
+	  # echo 1024 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
+
+#. Making memory available for DPDK.
+
+   .. code-block:: bash
+
+	  # mkdir -p /mnt/huge
+	  # mount -t hugetlbfs nodev /mnt/huge
+
+#. Add cores and memory configuration to the OpenvSwitch example; the
+   :file:`/usr/share/openvswitch/scripts/ovs-ctl` file can be edited on line 256
+   and DPDK configuration can be added.
+
+   It should look something like:
+   ``set ovs-vswitchd --dpdk -c 0x2 -n 4 --socket-mem 2048 -- unix:"$DB_SOCK"``
+
+   The next regular expression could be helpful:
+
+   .. code-block:: bash
+
+      # sed -i s/"set ovs-vswitchd unix:"/"set ovs-vswitchd --dpdk -c 0x2 -n 4 --socket-mem 2048 -- unix:"/g /usr/share/openvswitch/scripts/ovs-ctl
+
+#. Start the OpenvSwitch service:
+
+   .. code-block:: bash
+
+      # systemctl start openvswitch.service
+
+#. Create a virtual bridge using openvswitch:
+
+   .. code-block:: bash
+
+	  # ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
+
+#. Add dpdk ports to the bridge:
+
+   .. code-block:: bash
+
+      # ovs-vsctl add-port br0 vhost-user1 -- set Interface vhost-user1 type=dpdkvhostuser
+	  # ovs-vsctl add-port br0 vhost-user2 -- set Interface vhost-user2 type=dpdkvhostuser
+
+#. Run guest virtual machine A using the next configuration as reference, where
+   **$IMAGE** var is the name of the Clear Linux* OS for Intel Architecture image.
+
+   .. code-block:: bash
+
+      qemu-system-x86_64 \
+          -enable-kvm -m 1024 \
+          -bios OVMF.fd \
+          -smp 4 -cpu host \
+          -vga none -nographic \
+          -drive file="$IMAGE",if=virtio,aio=threads \
+          -chardev socket,id=char1,path=/run/openvswitch/vhost-user1 \
+          -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce \
+          -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1 \
+          -object memory-backend-file,id=mem,size=1024M,mem-path=/dev/ hugepages,share=on \
+          -numa node,memdev=mem -mem-prealloc \
+          -debugcon file:debug.log -global isa-debugcon.iobase=0x402
+
+#. Run guest virtual machine B, use the configuration from the previous step;
+   simply change the MAC address and the port socket. You can use 00:00:00:00:00:02 as a
+   MAC address and vhost-user2 as a socket.
+
+#. Follow the instructions from the `Setting IP address`_ section.
+
+
+
+.. _Setting IP address:
+
+Setting IP address
+==================
+
+#. Set an IP address to virtual machine for virtual machine A:
+
+   .. code-block:: bash
+
+      # ip addr add dev enp0s2 10.0.0.5/24
+
+   for virtual machine B:
+
+   .. code-block:: bash
+
+      # ip addr add dev enp0s2 10.0.0.6/24
+
+#. Check if there is communication between both virtual machines using ping tool.
+
+#. Verify that Apache service is running:
+
+   .. code-block:: bash
+
+      # systemctl status httpd.service
+      # systemctl start httpd.service
+
+   Start httpd service only if it is inactive. Use apache benchmark to get
+   information about the network performance between both virtual machines.
+
+   .. code-block:: bash
+
+      # ab -n 1000000 -c 100 http://10.0.0.6/
+
+
+.. _DPDK: http://dpdk.org/
+.. _kvm: https://download.clearlinux.org/releases/

source/advanced/validate-signs.rst

@@ -1,137 +1,137 @@
-.. _validate_sigs:
-
-Validating Signatures
-#####################
-
-Clear Linux* OS for Intel® Architecture offers a way to validate signatures
-to create verified build artifacts. Validations can be obtained by users and
-by code to confirm that we are indeed dealing with official outputs.
-
-Multiple types of artifacts have signing/verifying:
-
-* Image checksums files; for example,  `release 8890`_ has 
-    * ``clear-*.img.xz`` image files, 
-    * ``clear-*.img.xz-SHA512SUMS`` checksum files, and
-    * ``clear-*.img.xz-SHA512SUMS.sig`` signature files.
-* The :command:`swupd` Manifest of Manifests (aka :abbr:`MoM (Manifest of Manifests)`)
-  ``https://download.clearlinux.org/update/8890/`` has ``Manifest.MoM``
-  and ``Manifest.MoM.sig`` signature file.
-
-Verifying a Clear Linux OS for Intel Architecture image
-=======================================================
-
-Verification of images is done by humans when they download an image via the following steps:
-
-#. Download the current ``ClearLinuxRoot.pem`` certificate; this is provided
-   with the release being downloaded. For example, if you're interested in verifying
-   the ``8970`` release, obtain the certificate from https://download.clearlinux.org/releases/8970/clear/ClearLinuxRoot.pem.
-#. Download the desired OS image, as well as the ``[image]-SHA512SUMS.sig`` file.
-#. Download and validate the release's OS ``ClearLinuxRoot.pem`` certificate:
-
-     * Validate the certificate by comparing the downloaded certificate's
-       ``sha256sum`` hash with what is published here:
-
-        .. code-block:: console
-
-           $ sha256sum ClearLinuxRoot.pem
-
-        You should see this (accurate as of 2016-06-16 00:00 UTC):
-
-        .. code-block:: console
-
-           4b0ca67300727477913c331ff124928a98bcf2fb12c011a855f17cd73137a890  ClearLinuxRoot.pem
-
-     * Now we verify that the signature file is valid, which also proves
-       the OS image tarball is as trusted as the ``ClearLinuxRoot`` certificate. 
-       To do this, create the **SHA512SUMS** file of the tarball. This is the
-       content which is actually signed by the release team.
-
-        .. code-block:: console
-
-           $ sha512sum ./[image-####].img.xz > sha512sum.out
-
-     * Finally, we can use :command:`openssl` to validate the signed
-       :file:`SHA512SUMS.sig` was signed by the ``ClearLinuxRoot`` certificate:
-
-        .. code-block:: console
-
-            $ openssl smime -verify -in [image]-SHA512SUMS.sig -inform der -content sha512sum.out -CAfile ClearLinuxRoot.pem -out /dev/null
-
-        After running this, you should see: :code:`Verification successful`.
-        If you do not see this, you cannot be certain the OS you downloaded
-        can be trusted.
-
-
-Verification of the signed MoM
-==============================
-
-An overview of the mechanism used internal to :command:`swupd` 
-(implemented in C calls to the openssl library API) is as follows:
-
-#. A trusted certificate is distributed with all Clear Linux
-   OS for Intel Architecture releases in :file:`/usr/share/clear/update-ca/ClearLinuxRoot.pem`.
-
-#. :command:`swupd` downloads the top-level manifest (MoM), as
-   well as the signed :file:`MoM.sig` for the currently-installed
-   image, and for the release being updated to in the case of an update.
-
-#. :command:`swupd` generates a ``sha256sum`` of the MoM.
-
-#. :command:`swupd` uses the :file:`MoM.sig` downloaded in step 1,
-   as well as the ``sha256sum``; and, using the openssl API, it makes
-   an equivalent call to the verification command:
-
-   .. code-block:: c
-
-      openssl smime -verify -in sha256sums.sig -inform der -content sha512sum.out -CAfile ClearLinuxRoot.pem
-
-   Note that the actual API call is to ``PKCS7_verify())``.
-
-#. With a successful verification, we can proceed to trust this
-   MoM and its contents, which consist of hashes of the contents
-   of all bundle manifests.
-
-   * **Success** When a successful signature verification occurs, you
-     should see the following message as part of the :command:`swupd`
-     output:
-
-     .. code-block:: console
-
-        Signature check succeeded
-
-   * **Fail** Should verification fail, you will see:
-
-     .. code-block:: console
-
-        WARNING!!! FAILED TO VERIFY SIGNATURE OF Manifest.MoM
-
-#. As :command:`swupd` then uses or installs bundle manifests, that
-   bundle manifest hash is matched to the trusted MoM, extending the
-   chain of trust from the MoM, to the bundle manifests, and out to
-   every file installed. 
-
-Clear Linux* OS for Intel® Architecture Public Key as of 06/16/2016 00:00 UTC
------------------------------------------------------------------------------
-
-.. code-block:: raw  
-
-  -----BEGIN PUBLIC KEY-----
-  MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwfnY2m665SwYxr4/R+8L
-  X1IMAkVYmvNiI5KmV815WvVQwUQDDCY1HUag+wb2BhTxkotKUdm6LGY1ck+Eb742
-  rdICMToX+32vFM3XvIK16TKM6ficPsGA4xmbE/9qp01bn0O4MCwKjPAmxJkW+UOO
-  L5u8p9VBZ1MYMnsRkECPZif/fULqIU73aYD3HYtcYEk1+N8n1AcNkpRY9p3Qd92M
-  9aRlCNl1sb2g5DwSx9G0dWTS+YPchpclV7fBGQUiTuxb72hpVRE66CfR8tTd14np
-  IbsKGq0S5PzkR9ubilDywFQ/6XPc1Rur/4g0rm6pPPx7DLQK3EqC8d4Z/C2nywje
-  PwIDAQAB
-  -----END PUBLIC KEY-----
-
-
-You can re-create this when given a cert with the command:
-
-.. code-block:: console
-
-   $ openssl x509 -pubkey -noout -in ClearLinuxRoot.pem
-
-
-
+.. _validate_sigs:
+
+Validating Signatures
+#####################
+
+Clear Linux* OS for Intel® Architecture offers a way to validate signatures
+to create verified build artifacts. Validations can be obtained by users and
+by code to confirm that we are indeed dealing with official outputs.
+
+Multiple types of artifacts have signing/verifying:
+
+* Image checksums files; for example,  `release 8890`_ has
+    * ``clear-*.img.xz`` image files,
+    * ``clear-*.img.xz-SHA512SUMS`` checksum files, and
+    * ``clear-*.img.xz-SHA512SUMS.sig`` signature files.
+* The :command:`swupd` Manifest of Manifests (aka :abbr:`MoM (Manifest of Manifests)`)
+  ``https://download.clearlinux.org/update/8890/`` has ``Manifest.MoM``
+  and ``Manifest.MoM.sig`` signature file.
+
+Verifying a Clear Linux OS for Intel Architecture image
+=======================================================
+
+Verification of images is done by humans when they download an image via the following steps:
+
+#. Download the current ``ClearLinuxRoot.pem`` certificate; this is provided
+   with the release being downloaded. For example, if you're interested in verifying
+   the ``8970`` release, obtain the certificate from https://download.clearlinux.org/releases/8970/clear/ClearLinuxRoot.pem.
+#. Download the desired OS image, as well as the ``[image]-SHA512SUMS.sig`` file.
+#. Download and validate the release's OS ``ClearLinuxRoot.pem`` certificate:
+
+     * Validate the certificate by comparing the downloaded certificate's
+       ``sha256sum`` hash with what is published here:
+
+        .. code-block:: console
+
+           $ sha256sum ClearLinuxRoot.pem
+
+        You should see this (accurate as of 2016-06-16 00:00 UTC):
+
+        .. code-block:: console
+
+           4b0ca67300727477913c331ff124928a98bcf2fb12c011a855f17cd73137a890  ClearLinuxRoot.pem
+
+     * Now we verify that the signature file is valid, which also proves
+       the OS image tarball is as trusted as the ``ClearLinuxRoot`` certificate.
+       To do this, create the **SHA512SUMS** file of the tarball. This is the
+       content which is actually signed by the release team.
+
+        .. code-block:: console
+
+           $ sha512sum ./[image-####].img.xz > sha512sum.out
+
+     * Finally, we can use :command:`openssl` to validate the signed
+       :file:`SHA512SUMS.sig` was signed by the ``ClearLinuxRoot`` certificate:
+
+        .. code-block:: console
+
+            $ openssl smime -verify -in [image]-SHA512SUMS.sig -inform der -content sha512sum.out -CAfile ClearLinuxRoot.pem -out /dev/null
+
+        After running this, you should see: :code:`Verification successful`.
+        If you do not see this, you cannot be certain the OS you downloaded
+        can be trusted.
+
+
+Verification of the signed MoM
+==============================
+
+An overview of the mechanism used internal to :command:`swupd`
+(implemented in C calls to the openssl library API) is as follows:
+
+#. A trusted certificate is distributed with all Clear Linux
+   OS for Intel Architecture releases in :file:`/usr/share/clear/update-ca/ClearLinuxRoot.pem`.
+
+#. :command:`swupd` downloads the top-level manifest (MoM), as
+   well as the signed :file:`MoM.sig` for the currently-installed
+   image, and for the release being updated to in the case of an update.
+
+#. :command:`swupd` generates a ``sha256sum`` of the MoM.
+
+#. :command:`swupd` uses the :file:`MoM.sig` downloaded in step 1,
+   as well as the ``sha256sum``; and, using the openssl API, it makes
+   an equivalent call to the verification command:
+
+   .. code-block:: c
+
+      openssl smime -verify -in sha256sums.sig -inform der -content sha512sum.out -CAfile ClearLinuxRoot.pem
+
+   Note that the actual API call is to ``PKCS7_verify())``.
+
+#. With a successful verification, we can proceed to trust this
+   MoM and its contents, which consist of hashes of the contents
+   of all bundle manifests.
+
+   * **Success** When a successful signature verification occurs, you
+     should see the following message as part of the :command:`swupd`
+     output:
+
+     .. code-block:: console
+
+        Signature check succeeded
+
+   * **Fail** Should verification fail, you will see:
+
+     .. code-block:: console
+
+        WARNING!!! FAILED TO VERIFY SIGNATURE OF Manifest.MoM
+
+#. As :command:`swupd` then uses or installs bundle manifests, that
+   bundle manifest hash is matched to the trusted MoM, extending the
+   chain of trust from the MoM, to the bundle manifests, and out to
+   every file installed.
+
+Clear Linux* OS for Intel® Architecture Public Key as of 06/16/2016 00:00 UTC
+-----------------------------------------------------------------------------
+
+.. code-block:: raw
+
+  -----BEGIN PUBLIC KEY-----
+  MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwfnY2m665SwYxr4/R+8L
+  X1IMAkVYmvNiI5KmV815WvVQwUQDDCY1HUag+wb2BhTxkotKUdm6LGY1ck+Eb742
+  rdICMToX+32vFM3XvIK16TKM6ficPsGA4xmbE/9qp01bn0O4MCwKjPAmxJkW+UOO
+  L5u8p9VBZ1MYMnsRkECPZif/fULqIU73aYD3HYtcYEk1+N8n1AcNkpRY9p3Qd92M
+  9aRlCNl1sb2g5DwSx9G0dWTS+YPchpclV7fBGQUiTuxb72hpVRE66CfR8tTd14np
+  IbsKGq0S5PzkR9ubilDywFQ/6XPc1Rur/4g0rm6pPPx7DLQK3EqC8d4Z/C2nywje
+  PwIDAQAB
+  -----END PUBLIC KEY-----
+
+
+You can re-create this when given a cert with the command:
+
+.. code-block:: console
+
+   $ openssl x509 -pubkey -noout -in ClearLinuxRoot.pem
+
+
+
 .. _release 8890: https://download.clearlinux.org/releases/8890/clear/

source/bundles/basic-containers.rst

@@ -1,85 +1,85 @@
-.. _bdl-containers-basic:
-
-containers-basic
-################
-
-This bundle provides container applications
-
-Multiple runtime support for Docker
-===================================
-
-Docker\* 1.12+ provides a way to execute containers using different **"oci
-runtimes"**. An **"oci runtime"** is  software compatible with :abbr:`OCI 
-(Open Containers Initiative)` specification that is responsible to create
-a container.
-
-.. note:: Docker in Clear Linux is configured to use 2 runtimes:
-
-**cc-oci-runtime**: This is the default runtime used by docker in Clear Linux (if
-Vt-x support is enabled). This runtime provides the capability to create secure
-containers using Clear Containers (based VM containers).
-
-**runc**: This runtime is used to spawn and run containers using namespaces and
-cgroups (this is the traditional way to create containers used by docker).
-
-In Clear Linux, each time a container is created it uses cc-oci-runtime (*A.K.A*
-**cor**). 
-
-To start a secure container with cc-oci-runtime aka cor::
-
-  docker run -ti debian sh 
-
-In the case you want to start a non secure container. You can
-use the option **--runtime=runc** in the docker command **"run"**
-
-To start an non-secure container using runc runtime::
-
-  docker run --runtime=runc -ti debian sh
-
-Change default runtime
-======================
-
-To modify the default runtime you can override
-the stateless docker daemon configuration
-creating the file :file:`/etc/systemd/system/docker-cor.service.d/docker.conf`
-and adding **--default-runtinme=runc**::
-
-  [Service]                                                  
-  ExecStart=/usr/bin/dockerd -H fd:// --storage-driver=overlay --add runtime cor=cc-oci-runtime --default-runtime=runc    
-
-HTTP proxy
-==========
-
-If you are behind an HTTP proxy server, for example in corporate settings, you
-will need to add this configuration in the Docker systemd service file.
-
-First, create a systemd drop-in directory for the docker service::
-
-  mkdir /etc/systemd/system/docker-cor.service.d
-
-Now create a file called :file:`/etc/systemd/system/docker-cor.service.d/http-proxy.conf`
-that adds the HTTP_PROXY environment variable::
-
-  [Service]
-  Environment="HTTP_PROXY=http://proxy.example.com:80/"
-
-If you have internal Docker registries that you need to contact without proxying
-you can specify them via the NO_PROXY environment variable::
-
-  Environment="HTTP_PROXY=http://proxy.example.com:80/" "NO_PROXY=localhost,127.0.0.1,docker-registry.somecorporation.com"
-
-Flush changes::
-
-  $ sudo systemctl daemon-reload
-
-Verify that the configuration has been loaded::
-
-  $ systemctl show --property=Environment docker-cor
-  Environment=HTTP_PROXY=http://proxy.example.com:80/
-
-Restart Docker::
-
-  $ sudo systemctl restart docker-cor
-
-To get more info you can view https://docs.docker.com/engine/admin/systemd/
-
+.. _bdl-containers-basic:
+
+containers-basic
+################
+
+This bundle provides container applications
+
+Multiple runtime support for Docker
+===================================
+
+Docker\* 1.12+ provides a way to execute containers using different **"oci
+runtimes"**. An **"oci runtime"** is  software compatible with :abbr:`OCI 
+(Open Containers Initiative)` specification that is responsible to create
+a container.
+
+.. note:: Docker in Clear Linux is configured to use 2 runtimes:
+
+**cc-oci-runtime**: This is the default runtime used by docker in Clear Linux (if
+Vt-x support is enabled). This runtime provides the capability to create secure
+containers using Clear Containers (based VM containers).
+
+**runc**: This runtime is used to spawn and run containers using namespaces and
+cgroups (this is the traditional way to create containers used by docker).
+
+In Clear Linux, each time a container is created it uses cc-oci-runtime (*A.K.A*
+**cor**). 
+
+To start a secure container with cc-oci-runtime aka cor::
+
+  docker run -ti debian sh 
+
+In the case you want to start a non secure container. You can
+use the option **--runtime=runc** in the docker command **"run"**
+
+To start an non-secure container using runc runtime::
+
+  docker run --runtime=runc -ti debian sh
+
+Change default runtime
+======================
+
+To modify the default runtime you can override
+the stateless docker daemon configuration
+creating the file :file:`/etc/systemd/system/docker-cor.service.d/docker.conf`
+and adding **--default-runtinme=runc**::
+
+  [Service]                                                  
+  ExecStart=/usr/bin/dockerd -H fd:// --storage-driver=overlay --add runtime cor=cc-oci-runtime --default-runtime=runc    
+
+HTTP proxy
+==========
+
+If you are behind an HTTP proxy server, for example in corporate settings, you
+will need to add this configuration in the Docker systemd service file.
+
+First, create a systemd drop-in directory for the docker service::
+
+  mkdir /etc/systemd/system/docker-cor.service.d
+
+Now create a file called :file:`/etc/systemd/system/docker-cor.service.d/http-proxy.conf`
+that adds the HTTP_PROXY environment variable::
+
+  [Service]
+  Environment="HTTP_PROXY=http://proxy.example.com:80/"
+
+If you have internal Docker registries that you need to contact without proxying
+you can specify them via the NO_PROXY environment variable::
+
+  Environment="HTTP_PROXY=http://proxy.example.com:80/" "NO_PROXY=localhost,127.0.0.1,docker-registry.somecorporation.com"
+
+Flush changes::
+
+  $ sudo systemctl daemon-reload
+
+Verify that the configuration has been loaded::
+
+  $ systemctl show --property=Environment docker-cor
+  Environment=HTTP_PROXY=http://proxy.example.com:80/
+
+Restart Docker::
+
+  $ sudo systemctl restart docker-cor
+
+To get more info you can view https://docs.docker.com/engine/admin/systemd/
+

source/bundles/index.rst

@@ -0,0 +1,10 @@
+Bundles
+#######
+
+.. toctree::
+   :maxdepth: 2
+
+   overview
+   basic-containers
+   openssh-server
+   os-core

source/bundles/openssh-server.rst

@@ -1,40 +1,40 @@
-.. _bdl-openssh-server:
-
-openssh-server
-##############
-
-This bundle provides an ssh server.
-
-SFTP
-====
-
-Clear Linux *disables* sftp subsystem by default for security reasons.
-To enable sftp subsystem you will need to add this configuration in the sshd
-service file.
-
-First, create a systemd drop-in directory for the sshd service::
-
-  # mkdir /etc/systemd/system/sshd@.service.d
-
-Now create a file called :file:`/etc/systemd/system/sshd@.service.d/sftp.conf`
-that adds the OPTIONS environment variable::
-
-  [Service]
-  Environment="OPTIONS=-o Subsystem=\"sftp /usr/libexec/sftp-server\""
-
-Now, sftp subsystem is enabled.
-
-Root login
-==========
-
-To enable root login via ssh, you should do the following:
-
-#. Create a *ssh* directory in /etc (if not exist)::
-
-   # mkdir /etc/ssh
-
-#. Set config variable::
-
-   # echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
-
-
+.. _bdl-openssh-server:
+
+openssh-server
+##############
+
+This bundle provides an ssh server.
+
+SFTP
+====
+
+Clear Linux *disables* sftp subsystem by default for security reasons.
+To enable sftp subsystem you will need to add this configuration in the sshd
+service file.
+
+First, create a systemd drop-in directory for the sshd service::
+
+  # mkdir /etc/systemd/system/sshd@.service.d
+
+Now create a file called :file:`/etc/systemd/system/sshd@.service.d/sftp.conf`
+that adds the OPTIONS environment variable::
+
+  [Service]
+  Environment="OPTIONS=-o Subsystem=\"sftp /usr/libexec/sftp-server\""
+
+Now, sftp subsystem is enabled.
+
+Root login
+==========
+
+To enable root login via ssh, you should do the following:
+
+#. Create a *ssh* directory in /etc (if not exist)::
+
+   # mkdir /etc/ssh
+
+#. Set config variable::
+
+   # echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
+
+

source/bundles/os-core.rst

@@ -1,83 +1,83 @@
-.. _bdl-os-core:
-
-os-core
-#######
-
-This bundle contains the basic core OS components.
-
-Static IP
-=========
-
-To configure a static IP you should follow the next steps:
-
-#. Create file :file:`/etc/systemd/network/50-static.network`. If a directory
-   does not exist, please create it.
-
-#. The minimum lines the :file:`50-static.network` file should contain are::
-   
-     [Match]
-     Name=<device_name>
-
-     [Network]
-     Address=<A static IPv4 or IPv6 address and its prefix length, separated by a "/" character>
-     Gateway=<The gateway address>
-
-   The *<device_name>* is your network device name (i.e. enp1s0 or enp0s25).
-
-#. If you want to add more options you can consult the
-   `systemd network configuration`_ manual.
-
-#. Restart *systemd-networkd* service using:: 
-
-     # systemctl restart systemd-networkd
-
-   or restart Clear Linux.
-
-#. Check new IP with::
-  
-     # ip addr
-
-
-Setting Time
-============
-
-Clear Linux utilizes **systemd-timesyncd.service** to sync time. 
-Default :abbr:`NTP (Network Time Protocol)` servers are
-configured as *time1.google.com, time2.google.com, time3.google.com, and
-time4.google.com*. It is not possible to set the time manually, via
-*timedatectl*
-or to use RTC mode. In the event that those servers cannot be reached and the
-time is incorrect on your system, try these steps:
-
-#. Make sure that you've set your timezone:
-
-   * If you at Pacific time::
-
-       timedatectl set-timezone America/Los_Angeles
-
-     or you can choose a preferred timezone
-
-   * To see a list of timezones, do::
-
-       timedatectl list-timezones | grep <locale>
-
-#. Create :file:`/etc/systemd/` directory
-
-#. Open your chosen editor and type into the
-   :file:`/etc/systemd/timesyncd.conf` file::
-
-    [Time]
-    NTP=<Preferred Server>
-    FallbackNTP=<backup server 1> <backup server 2>
-
-#. Restart timesync daemon::
-
-    # systemctl  restart systemd-timesyncd
-
-.. note:: Check to make sure your time is correctly set: date
-
-
-
-
-
-.. _systemd network configuration: https://www.freedesktop.org/software/systemd/man/systemd.network.html
+.. _bdl-os-core:
+
+os-core
+#######
+
+This bundle contains the basic core OS components.
+
+Static IP
+=========
+
+To configure a static IP you should follow the next steps:
+
+#. Create file :file:`/etc/systemd/network/50-static.network`. If a directory
+   does not exist, please create it.
+
+#. The minimum lines the :file:`50-static.network` file should contain are::
+   
+     [Match]
+     Name=<device_name>
+
+     [Network]
+     Address=<A static IPv4 or IPv6 address and its prefix length, separated by a "/" character>
+     Gateway=<The gateway address>
+
+   The *<device_name>* is your network device name (i.e. enp1s0 or enp0s25).
+
+#. If you want to add more options you can consult the
+   `systemd network configuration`_ manual.
+
+#. Restart *systemd-networkd* service using:: 
+
+     # systemctl restart systemd-networkd
+
+   or restart Clear Linux.
+
+#. Check new IP with::
+  
+     # ip addr
+
+
+Setting Time
+============
+
+Clear Linux utilizes **systemd-timesyncd.service** to sync time. 
+Default :abbr:`NTP (Network Time Protocol)` servers are
+configured as *time1.google.com, time2.google.com, time3.google.com, and
+time4.google.com*. It is not possible to set the time manually, via
+*timedatectl*
+or to use RTC mode. In the event that those servers cannot be reached and the
+time is incorrect on your system, try these steps:
+
+#. Make sure that you've set your timezone:
+
+   * If you at Pacific time::
+
+       timedatectl set-timezone America/Los_Angeles
+
+     or you can choose a preferred timezone
+
+   * To see a list of timezones, do::
+
+       timedatectl list-timezones | grep <locale>
+
+#. Create :file:`/etc/systemd/` directory
+
+#. Open your chosen editor and type into the
+   :file:`/etc/systemd/timesyncd.conf` file::
+
+    [Time]
+    NTP=<Preferred Server>
+    FallbackNTP=<backup server 1> <backup server 2>
+
+#. Restart timesync daemon::
+
+    # systemctl  restart systemd-timesyncd
+
+.. note:: Check to make sure your time is correctly set: date
+
+
+
+
+
+.. _systemd network configuration: https://www.freedesktop.org/software/systemd/man/systemd.network.html

source/ciao/deploy-ubuntu.rst

@@ -1,220 +1,220 @@
-.. _ciao-deploy:
-
-.. contents::
-
-Deploying ciao via automation -- Ubuntu 16.04
-#############################################
-
-Cloud Integrated Advanced Orchestrator (``ciao``) is a new workload
-scheduler designed to address limitations of current cloud OS projects.
-Ciao provides a lightweight, fully TLS-based minimal config, is
-workload-agnostic, easy to update, offers an optimized-for-speed
-scheduler, and is currently optimized for OpenStack*.
-
-For more information, see https://clearlinux.org/ciao.
-
-Environment
-===========
-
-For this example, we'll use a total of five nodes:
- - A deployment machine which will be used to run the playbooks.
- - A `controller`_ node which will be used to communicate with Keystone.
- - Two `compute nodes`_, which will spawn the VMs and containers.
- - A `network node`_ which will handle the networking for the workloads.
-
- Note: The deployment machine is not a necessary part of the cluster; it could be
- the sysadmin's computer or a CI/CD server.
-
-.. _prerequisites:
-
-Prerequisites
-=============
-
-Ansible* uses :command:`ssh` to run commands on the remote nodes. In 
-order to do that, the nodes must be configured to allow passwordless SSH 
-connections from the deployment machine to the cluster nodes. The user 
-should also have sudo privileges on the cluster nodes.
-
-The deployment machine needs::
-
-  Python 2.7
-  Ansible >= 2.1
-  Golang >= 1.7
-  qemu-utils
-  python-docker
-  python-openstackclient
-  Ansible ciao roles from ansible-galaxy
-
-The managed nodes need::
-  
-  python 2.6 >=
-
-
-Proxy
-=====
-
-If you are running behind a proxy, the following additional steps are needed:
-
-In the deployment node
-----------------------
-
-Make sure apt can run. Edit ``/etc/apt/apt.conf`` (to install ansible and 
-dependencies), appending it with::
-
-  Acquire::http::Proxy "http://yourproxyaddress:proxyport";
-  Install the CIAO roles from ansible-galaxy:
-  $ sudo -E ansible-galaxy -r requirements --ignore-certs
-
-In the managed nodes
---------------------
-
-Make sure apt can run. Edit ``/etc/apt/apt.conf``, appending it with::
-
-  Acquire::http::Proxy "http://yourproxyaddress:proxyport";
-  
-Install Docker and make sure you can pull images. Edit 
-``/etc/systemd/system/docker.service.d/http-proxy.conf``, appending it 
-with::
-
-  [Service]
-  Environment="HTTP_PROXY=http://hostname:port/"
-  Environment="HTTPS_PROXY=http://hostname:port/"
-  Environment=”NO_PROXY=localhost,127.0.0.1,.example.com”
-
-Note: replace the hostname and port of your proxy server and append your local domain name.
-
-Reload and restart the docker daemon::
-
-  $ sudo systemctl daemon-reload && sudo systemctl restart docker
-
-  (OPTIONAL): You can download the docker images used in the CIAO deployment.
-  $ sudo docker pull clearlinux/keystone
-  $ sudo docker pull clearlinux/ciao-webui
-
-
-Install the software
-====================
-
-Install ansible from ubuntu packages if the package version is >= 2.1.0; 
-otherwise, install it from pip (``pip install ansible``).
-
-Install Dependencies in the deployment machine
-----------------------------------------------
-
-::
-
-  python-docker (apt-get) or docker-py (pip)
-  python-openstackclient (apt-get)
-  qemu-utils (apt-get)
-
-Download the ``clear-config-management`` project from github::
-
-  $ git clone https://github.com/clearlinux/clear-config-management.git
-
-
-Create the playbook
-===================
-
-The ``clear-config-management`` project includes some sample playbooks that 
-you may use and customize for your own needs. Start by making a copy of the 
-sample playbook into your home folder::
-
-  # cp -r clear-config-management/examples/ciao ~/
-
-
-Note: These files are also hosted in github
-
-The relevant files in the playbook are the following:
-
-  * The `ciao.yml`_ file is the master playbook file and includes a playbook
-    for each component of the cluster.
-
-  * The `hosts`_ file is the hosts inventory file and contains the IP
-    addresses/FQDN of your nodes, grouped under the roles they will serve
-
-  * The `groups_vars/all`_ file contains variables that will be applied
-    to your ciao setup. The mandatory variables are already there; be
-    sure to change the values accordingly to fit your environment
-
-  * The ``ciao_guest_key`` value in :file:`groups_var/all` is the key 
-    to be used to connect to the VMs created by ciao; you can use the 
-    ``ssh-keygen`` command to create one.
-
-A full list of available variables can be found in the :file:`defaults/main.yml` 
-file of each role at https://github.com/clearlinux/clear-config-management/tree/master/roles
-
-
-Install the required ansible-roles
-==================================
-
-.. code-block:: console
-
-   # ansible-galaxy install -r requirements.yml
-
-
-Run the playbook
-================
-
-Once you have your variables and hosts file configured, the deployment can
-be started with the following command:
-
-.. code-block:: console
-
-   $ ansible-playbook -i hosts ciao.yml --private-key=<ssh_key>
-
-Note: If you want the latest CIAO changes, change the  ``ciao_dev`` 
-variable to ``True`` in the :file:`group_vars/all` file In the 
-``clear-config-management`` project.
-
-
-Verify
-======
-
-After ansible is done with the setup, you can verify the cluster is ready
-by running the following command on the controller node. Change the **username**,
-**password**, **controller**, and **identity** values to match your setup, as
-was specified in the ``groups_var/all`` file:
-
-.. code-block:: console
-
-   # ciao-cli -identity=https://ciao-controller.example.com:35357 \
-   -username admin \ 
-   -password secret \ 
-   -controller=ciao-controller.example.com 
-   # node status
-   Total Nodes 3
-    Ready 0
-    Full 3
-    Offline 0
-    Maintenance 0
-
-You could also take a look at the :file:`./ciaorc` file created on your
-deployment node, which contains the following environment variables:
-
-.. code-block:: console
-
-   # cat ciaorc
-   export CIAO_CONTROLLER=ciao-controller.example.com
-   export CIAO_IDENTITY=https://ciao-controller.example.com:35357
-   export CIAO_USERNAME=csr
-   export CIAO_PASSWORD=secret
-
-then you could verify with the following command:
-
-.. code-block:: console
-
-   # source ciaorc
-   # ciao-cli node status
-   Total Nodes 3
-    Ready 0
-    Full 3
-    Offline 0
-    Maintenance 0
-
-.. _controller: https://github.com/01org/ciao/tree/master/ciao-controller
-.. _compute nodes: https://github.com/01org/ciao/tree/master/ciao-launcher
-.. _network node: https://github.com/01org/ciao/tree/master/ciao-launcher
-.. _ciao.yml: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/ciao.yml
-.. _hosts: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/hosts
-.. _groups_vars/all: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/group_vars/all
-.. _github: https://github.com/clearlinux/clear-config-management/tree/master/examples/ciao
+.. _ciao-deploy:
+
+.. contents::
+
+Deploying ciao via automation -- Ubuntu 16.04
+#############################################
+
+Cloud Integrated Advanced Orchestrator (``ciao``) is a new workload
+scheduler designed to address limitations of current cloud OS projects.
+Ciao provides a lightweight, fully TLS-based minimal config, is
+workload-agnostic, easy to update, offers an optimized-for-speed
+scheduler, and is currently optimized for OpenStack*.
+
+For more information, see https://clearlinux.org/ciao.
+
+Environment
+===========
+
+For this example, we'll use a total of five nodes:
+ - A deployment machine which will be used to run the playbooks.
+ - A `controller`_ node which will be used to communicate with Keystone.
+ - Two `compute nodes`_, which will spawn the VMs and containers.
+ - A `network node`_ which will handle the networking for the workloads.
+
+ Note: The deployment machine is not a necessary part of the cluster; it could be
+ the sysadmin's computer or a CI/CD server.
+
+.. _prerequisites:
+
+Prerequisites
+=============
+
+Ansible* uses :command:`ssh` to run commands on the remote nodes. In 
+order to do that, the nodes must be configured to allow passwordless SSH 
+connections from the deployment machine to the cluster nodes. The user 
+should also have sudo privileges on the cluster nodes.
+
+The deployment machine needs::
+
+  Python 2.7
+  Ansible >= 2.1
+  Golang >= 1.7
+  qemu-utils
+  python-docker
+  python-openstackclient
+  Ansible ciao roles from ansible-galaxy
+
+The managed nodes need::
+  
+  python 2.6 >=
+
+
+Proxy
+=====
+
+If you are running behind a proxy, the following additional steps are needed:
+
+In the deployment node
+----------------------
+
+Make sure apt can run. Edit ``/etc/apt/apt.conf`` (to install ansible and 
+dependencies), appending it with::
+
+  Acquire::http::Proxy "http://yourproxyaddress:proxyport";
+  Install the CIAO roles from ansible-galaxy:
+  $ sudo -E ansible-galaxy -r requirements --ignore-certs
+
+In the managed nodes
+--------------------
+
+Make sure apt can run. Edit ``/etc/apt/apt.conf``, appending it with::
+
+  Acquire::http::Proxy "http://yourproxyaddress:proxyport";
+  
+Install Docker and make sure you can pull images. Edit 
+``/etc/systemd/system/docker.service.d/http-proxy.conf``, appending it 
+with::
+
+  [Service]
+  Environment="HTTP_PROXY=http://hostname:port/"
+  Environment="HTTPS_PROXY=http://hostname:port/"
+  Environment=”NO_PROXY=localhost,127.0.0.1,.example.com”
+
+Note: replace the hostname and port of your proxy server and append your local domain name.
+
+Reload and restart the docker daemon::
+
+  $ sudo systemctl daemon-reload && sudo systemctl restart docker
+
+  (OPTIONAL): You can download the docker images used in the CIAO deployment.
+  $ sudo docker pull clearlinux/keystone
+  $ sudo docker pull clearlinux/ciao-webui
+
+
+Install the software
+====================
+
+Install ansible from ubuntu packages if the package version is >= 2.1.0; 
+otherwise, install it from pip (``pip install ansible``).
+
+Install Dependencies in the deployment machine
+----------------------------------------------
+
+::
+
+  python-docker (apt-get) or docker-py (pip)
+  python-openstackclient (apt-get)
+  qemu-utils (apt-get)
+
+Download the ``clear-config-management`` project from github::
+
+  $ git clone https://github.com/clearlinux/clear-config-management.git
+
+
+Create the playbook
+===================
+
+The ``clear-config-management`` project includes some sample playbooks that 
+you may use and customize for your own needs. Start by making a copy of the 
+sample playbook into your home folder::
+
+  # cp -r clear-config-management/examples/ciao ~/
+
+
+Note: These files are also hosted in github
+
+The relevant files in the playbook are the following:
+
+  * The `ciao.yml`_ file is the master playbook file and includes a playbook
+    for each component of the cluster.
+
+  * The `hosts`_ file is the hosts inventory file and contains the IP
+    addresses/FQDN of your nodes, grouped under the roles they will serve
+
+  * The `groups_vars/all`_ file contains variables that will be applied
+    to your ciao setup. The mandatory variables are already there; be
+    sure to change the values accordingly to fit your environment
+
+  * The ``ciao_guest_key`` value in :file:`groups_var/all` is the key 
+    to be used to connect to the VMs created by ciao; you can use the 
+    ``ssh-keygen`` command to create one.
+
+A full list of available variables can be found in the :file:`defaults/main.yml` 
+file of each role at https://github.com/clearlinux/clear-config-management/tree/master/roles
+
+
+Install the required ansible-roles
+==================================
+
+.. code-block:: console
+
+   # ansible-galaxy install -r requirements.yml
+
+
+Run the playbook
+================
+
+Once you have your variables and hosts file configured, the deployment can
+be started with the following command:
+
+.. code-block:: console
+
+   $ ansible-playbook -i hosts ciao.yml --private-key=<ssh_key>
+
+Note: If you want the latest CIAO changes, change the  ``ciao_dev`` 
+variable to ``True`` in the :file:`group_vars/all` file In the 
+``clear-config-management`` project.
+
+
+Verify
+======
+
+After ansible is done with the setup, you can verify the cluster is ready
+by running the following command on the controller node. Change the **username**,
+**password**, **controller**, and **identity** values to match your setup, as
+was specified in the ``groups_var/all`` file:
+
+.. code-block:: console
+
+   # ciao-cli -identity=https://ciao-controller.example.com:35357 \
+   -username admin \ 
+   -password secret \ 
+   -controller=ciao-controller.example.com 
+   # node status
+   Total Nodes 3
+    Ready 0
+    Full 3
+    Offline 0
+    Maintenance 0
+
+You could also take a look at the :file:`./ciaorc` file created on your
+deployment node, which contains the following environment variables:
+
+.. code-block:: console
+
+   # cat ciaorc
+   export CIAO_CONTROLLER=ciao-controller.example.com
+   export CIAO_IDENTITY=https://ciao-controller.example.com:35357
+   export CIAO_USERNAME=csr
+   export CIAO_PASSWORD=secret
+
+then you could verify with the following command:
+
+.. code-block:: console
+
+   # source ciaorc
+   # ciao-cli node status
+   Total Nodes 3
+    Ready 0
+    Full 3
+    Offline 0
+    Maintenance 0
+
+.. _controller: https://github.com/01org/ciao/tree/master/ciao-controller
+.. _compute nodes: https://github.com/01org/ciao/tree/master/ciao-launcher
+.. _network node: https://github.com/01org/ciao/tree/master/ciao-launcher
+.. _ciao.yml: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/ciao.yml
+.. _hosts: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/hosts
+.. _groups_vars/all: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/group_vars/all
+.. _github: https://github.com/clearlinux/clear-config-management/tree/master/examples/ciao

source/ciao/deploy.rst

@@ -1,178 +1,178 @@
-.. _ciao-deploy:
-
-.. contents::
-
-Deploying ciao via automation
-#############################
-
-Cloud Integrated Advanced Orchestrator (``ciao``) is a new workload
-scheduler designed to address limitations of current cloud OS projects.
-Ciao provides a lightweight, fully TLS-based minimal config, is
-workload-agnostic, easy to update, offers an optimized-for-speed
-scheduler, and is currently optimized for OpenStack*.
-
-For more information, see https://clearlinux.org/ciao.
-
-Environment
-===========
-
-For this example, we'll use a total of five nodes:
- - A deployment machine which will be used to run the playbooks.
- - A `controller`_ node which will be used to communicate with Keystone.
- - Two `compute nodes`_, which will spawn the VMs and containers.
- - A `network node`_ which will handle the networking for the workloads.
-
-.. note::
-
-  The deployment machine is not a necessary part of the cluster; it could be
-  the sysadmin's computer or a CI/CD server.
-
-.. _prerequisites:
-
-Prerequisites
-=============
-Ansible* uses :command:`ssh` to run commands on the remote nodes. In order to do
-that, configure a user for passwordless SSH connections from the deployment
-container to the cluster nodes. This user must also have passwordless sudo
-privileges on the cluster nodes.
-
-This guide uses a Docker* container to provide all the needed deployment tools;
-in order to use it, you will need Docker in the machine you're using to orchestrate
-your deployment.
-
-
-Configure your cluster setup
-============================
-You will need to download the ciao example deployment as follows:
-
-.. code-block:: console
-
-  $ git clone https://github.com/01org/ciao.git
-
-Once you're cloned the repo, continue working in the
-`ciao/_DeploymentAndDistroPackaging/ansible/` directory
-
-.. code-block:: console
-
-   # cd $(pwd)/ciao/_DeploymentAndDistroPackaging/ansible/
-
-Next, edit the configuration files for the cluster:
-
-  * The `hosts`_ file is the hosts inventory file which contains the IP
-    addresses/FQDN of your nodes, grouped under the roles they will serve.
-
-  * The `groups_vars/all`_ file contains variables that will be applied
-    to your ciao setup. The mandatory variables are already there; be
-    sure to change the values accordingly to fit your environment.
-
-  * The ``ciao_guest_key`` value in :file:`groups_var/all` is the key to be
-    used to connect to the VMs created by ciao; you can use the
-    ``ssh-keygen`` command to create one.
-
-A full list of available variables can be found in the
-:file:`defaults/main.yml` file of each role at
-https://github.com/01org/ciao/tree/master/_DeploymentAndDistroPackaging/ansible/roles.
-
-To start your cluster setup, we provide a ready-to-use Docker container.
-Simply download it and run your setup:
-
-.. code-block:: console
-
-   $ docker pull clearlinux/ciao-deploy
-
-
-You can later launch the container with:
-
-.. code-block:: console
-
-   $ docker run --privileged -v /dev/:/dev/
-                -v /path/to/your/.ssh/key:/root/.ssh/id_rsa \
-                -v $(pwd)/ciao:/root/ciao \
-                -it clearlinux/ciao-deploy
-
-.. note::
-
-  The cotainer needs `--privileged -v /dev/:/dev/` in order to
-  install your certificates in the `CNCI image`_.
-  To learn more about the Docker options used, please refer to the
-  `Docker* documentation`_.
-
-
-Run the playbook
-================
-Once the variables and hosts file are configured, continue in the
-`/root/ciao/_DeploymentAndDistroPackaging/ansible` directory and
-start the deployment:
-
-.. code-block:: console
-
-   # cd /root/ciao/_DeploymentAndDistroPackaging/ansible
-
-   # ansible-playbook -i hosts ciao.yml \
-       --private-key=~/.ssh/id_rsa \
-       --user=<REMOTE_USER>
-
-.. note::
-
-  Note: The playbook will create the following files in the current folder of
-  the machine running the playbooks.
-
-    * ``./certificates``: This directory contains the certificates
-      that where created and copied to the cluster nodes.
-
-    * ``./images``: This directory contains the images used by the
-      ciao cluster (fedora, clearlinux, cnci, ovmf.fd).
-
-    * ``./ciaorc``: This file contains environment variables needed
-      by ciao cli to authenticate to the ciao cluster.
-
-    * ``./openrc``: This file contains environment variables needed by
-      openstack cli to authenticate with the ciao cluster.
-
-Verify
-======
-After Ansible is done with the setup, you can verify the cluster is ready
-by running the following command on the controller node. Change the **username**,
-**password**, **controller**, and **identity** values to match your setup, as
-was specified in the ``groups_var/all`` file:
-
-.. code-block:: console
-
-   # ciao-cli -identity=https://ciao-controller.example.com:35357 -username ciao -password ciaoUserPassword -controller=ciao-controller.example.com node status
-   Total Nodes 3
-    Ready 0
-    Full 3
-    Offline 0
-    Maintenance 0
-
-You could also take a look at the ``./ciaorc`` file created on your
-deployment node, which contains the following environment variables:
-
-.. code-block:: console
-
-   # cat ciaorc
-   export CIAO_CONTROLLER=ciao-controller.example.com
-   export CIAO_IDENTITY=https://ciao-controller.example.com:35357
-   export CIAO_USERNAME=ciao
-   export CIAO_PASSWORD=ciaoUserPassword
-
-Then you could verify with the following command:
-
-.. code-block:: console
-
-   # source ciaorc
-   # ciao-cli node status
-   Total Nodes 3
-    Ready 0
-    Full 3
-    Offline 0
-    Maintenance 0
-
-.. _controller: https://github.com/01org/ciao/tree/master/ciao-controller
-.. _compute nodes: https://github.com/01org/ciao/tree/master/ciao-launcher
-.. _network node: https://github.com/01org/ciao/tree/master/ciao-launcher
-.. _hosts: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/hosts
-.. _groups_vars/all: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/group_vars/all
-.. _github: https://github.com/clearlinux/clear-config-management/tree/master/examples/ciao
-.. _CNCI image: https://github.com/01org/ciao/tree/master/networking/ciao-cnci-agent#cnci-agent
-.. _Docker* documentation: https://docs.docker.com/engine/reference/commandline/run/
+.. _ciao-deploy:
+
+.. contents::
+
+Deploying ciao via automation
+#############################
+
+Cloud Integrated Advanced Orchestrator (``ciao``) is a new workload
+scheduler designed to address limitations of current cloud OS projects.
+Ciao provides a lightweight, fully TLS-based minimal config, is
+workload-agnostic, easy to update, offers an optimized-for-speed
+scheduler, and is currently optimized for OpenStack*.
+
+For more information, see https://clearlinux.org/ciao.
+
+Environment
+===========
+
+For this example, we'll use a total of five nodes:
+ - A deployment machine which will be used to run the playbooks.
+ - A `controller`_ node which will be used to communicate with Keystone.
+ - Two `compute nodes`_, which will spawn the VMs and containers.
+ - A `network node`_ which will handle the networking for the workloads.
+
+.. note::
+
+  The deployment machine is not a necessary part of the cluster; it could be
+  the sysadmin's computer or a CI/CD server.
+
+.. _prerequisites:
+
+Prerequisites
+=============
+Ansible* uses :command:`ssh` to run commands on the remote nodes. In order to do
+that, configure a user for passwordless SSH connections from the deployment
+container to the cluster nodes. This user must also have passwordless sudo
+privileges on the cluster nodes.
+
+This guide uses a Docker* container to provide all the needed deployment tools;
+in order to use it, you will need Docker in the machine you're using to orchestrate
+your deployment.
+
+
+Configure your cluster setup
+============================
+You will need to download the ciao example deployment as follows:
+
+.. code-block:: console
+
+  $ git clone https://github.com/01org/ciao.git
+
+Once you're cloned the repo, continue working in the
+`ciao/_DeploymentAndDistroPackaging/ansible/` directory
+
+.. code-block:: console
+
+   # cd $(pwd)/ciao/_DeploymentAndDistroPackaging/ansible/
+
+Next, edit the configuration files for the cluster:
+
+  * The `hosts`_ file is the hosts inventory file which contains the IP
+    addresses/FQDN of your nodes, grouped under the roles they will serve.
+
+  * The `groups_vars/all`_ file contains variables that will be applied
+    to your ciao setup. The mandatory variables are already there; be
+    sure to change the values accordingly to fit your environment.
+
+  * The ``ciao_guest_key`` value in :file:`groups_var/all` is the key to be
+    used to connect to the VMs created by ciao; you can use the
+    ``ssh-keygen`` command to create one.
+
+A full list of available variables can be found in the
+:file:`defaults/main.yml` file of each role at
+https://github.com/01org/ciao/tree/master/_DeploymentAndDistroPackaging/ansible/roles.
+
+To start your cluster setup, we provide a ready-to-use Docker container.
+Simply download it and run your setup:
+
+.. code-block:: console
+
+   $ docker pull clearlinux/ciao-deploy
+
+
+You can later launch the container with:
+
+.. code-block:: console
+
+   $ docker run --privileged -v /dev/:/dev/
+                -v /path/to/your/.ssh/key:/root/.ssh/id_rsa \
+                -v $(pwd)/ciao:/root/ciao \
+                -it clearlinux/ciao-deploy
+
+.. note::
+
+  The cotainer needs `--privileged -v /dev/:/dev/` in order to
+  install your certificates in the `CNCI image`_.
+  To learn more about the Docker options used, please refer to the
+  `Docker* documentation`_.
+
+
+Run the playbook
+================
+Once the variables and hosts file are configured, continue in the
+`/root/ciao/_DeploymentAndDistroPackaging/ansible` directory and
+start the deployment:
+
+.. code-block:: console
+
+   # cd /root/ciao/_DeploymentAndDistroPackaging/ansible
+
+   # ansible-playbook -i hosts ciao.yml \
+       --private-key=~/.ssh/id_rsa \
+       --user=<REMOTE_USER>
+
+.. note::
+
+  Note: The playbook will create the following files in the current folder of
+  the machine running the playbooks.
+
+    * ``./certificates``: This directory contains the certificates
+      that where created and copied to the cluster nodes.
+
+    * ``./images``: This directory contains the images used by the
+      ciao cluster (fedora, clearlinux, cnci, ovmf.fd).
+
+    * ``./ciaorc``: This file contains environment variables needed
+      by ciao cli to authenticate to the ciao cluster.
+
+    * ``./openrc``: This file contains environment variables needed by
+      openstack cli to authenticate with the ciao cluster.
+
+Verify
+======
+After Ansible is done with the setup, you can verify the cluster is ready
+by running the following command on the controller node. Change the **username**,
+**password**, **controller**, and **identity** values to match your setup, as
+was specified in the ``groups_var/all`` file:
+
+.. code-block:: console
+
+   # ciao-cli -identity=https://ciao-controller.example.com:35357 -username ciao -password ciaoUserPassword -controller=ciao-controller.example.com node status
+   Total Nodes 3
+    Ready 0
+    Full 3
+    Offline 0
+    Maintenance 0
+
+You could also take a look at the ``./ciaorc`` file created on your
+deployment node, which contains the following environment variables:
+
+.. code-block:: console
+
+   # cat ciaorc
+   export CIAO_CONTROLLER=ciao-controller.example.com
+   export CIAO_IDENTITY=https://ciao-controller.example.com:35357
+   export CIAO_USERNAME=ciao
+   export CIAO_PASSWORD=ciaoUserPassword
+
+Then you could verify with the following command:
+
+.. code-block:: console
+
+   # source ciaorc
+   # ciao-cli node status
+   Total Nodes 3
+    Ready 0
+    Full 3
+    Offline 0
+    Maintenance 0
+
+.. _controller: https://github.com/01org/ciao/tree/master/ciao-controller
+.. _compute nodes: https://github.com/01org/ciao/tree/master/ciao-launcher
+.. _network node: https://github.com/01org/ciao/tree/master/ciao-launcher
+.. _hosts: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/hosts
+.. _groups_vars/all: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/group_vars/all
+.. _github: https://github.com/clearlinux/clear-config-management/tree/master/examples/ciao
+.. _CNCI image: https://github.com/01org/ciao/tree/master/networking/ciao-cnci-agent#cnci-agent
+.. _Docker* documentation: https://docs.docker.com/engine/reference/commandline/run/

source/ciao/index.rst

@@ -0,0 +1,10 @@
+CIAO
+####
+
+.. toctree::
+   :maxdepth: 2
+
+   deploy
+   deploy-ubuntu
+   quick-cluster-setup.rst
+   cluster-setup

source/ciao/quick-cluster-setup.rst

@@ -1,12 +1,12 @@
-.. _ciao-cluster-setup-quick:
-
-Easy ciao development cluster setup
-###################################
-
-For quick ciao development cluster setup, see:
-
-    https://github.com/01org/ciao/wiki/Single-Machine-Development-Environment
-
-For more detailed and configurable manual setup of ciao, see:
-
-    https://clearlinux.org/documentation/ciao-cluster-setup.html
+.. _ciao-cluster-setup-quick:
+
+Easy ciao development cluster setup
+###################################
+
+For quick ciao development cluster setup, see:
+
+    https://github.com/01org/ciao/wiki/Single-Machine-Development-Environment
+
+For more detailed and configurable manual setup of ciao, see:
+
+    https://clearlinux.org/documentation/ciao-cluster-setup.html

source/conf.py

@@ -1,297 +1,297 @@
-# -*- coding: utf-8 -*-
-#
-# Clear Linux documentation build configuration file, created by
-# sphinx-quickstart on Fri May  8 11:43:01 2015.
-#
-# This file is execfile()d with the current directory set to its
-# containing dir.
-#
-# Note that not all possible configuration values are present in this
-# autogenerated file.
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
-
-import sys
-import os
-import shlex
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-#sys.path.insert(0, os.path.abspath('.'))
-
-# -- General configuration ------------------------------------------------
-
-# If your documentation needs a minimal Sphinx version, state it here.
-#needs_sphinx = '1.0'
-
-# Add any Sphinx extension module names here, as strings. They can be
-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
-# ones.
-#extensions = [
-#    'sphinx.ext.autodoc', 'breathe', 'sphinx.ext.todo'
-#]
-
-extensions = [
-    'sphinx.ext.autodoc', 'sphinx.ext.todo'
-]
-
-# Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
-
-# The suffix(es) of source filenames.
-# You can specify multiple suffix as a list of string:
-# source_suffix = ['.rst', '.md']
-source_suffix = '.rst'
-
-# The encoding of source files.
-#source_encoding = 'utf-8-sig'
-
-# The master toctree document.
-master_doc = 'index'
-
-# General information about the project.
-project = u'Clear Linux* Project for Intel® Architecture'
-copyright = u'2016, many'
-author = u'many'
-
-# The version info for the project you're documenting, acts as replacement for
-# |version| and |release|, also used in various other places throughout the
-# built documents.
-#
-# The short X.Y version.
-version = '0.1'
-# The full version, including alpha/beta/rc tags.
-release = '0.1'
-
-# The language for content autogenerated by Sphinx. Refer to documentation
-# for a list of supported languages.
-#
-# This is also used if you do content translation via gettext catalogs.
-# Usually you set "language" from the command line for these cases.
-language = None
-
-# There are two options for replacing |today|: either, you set today to some
-# non-false value, then it is used:
-#today = ''
-# Else, today_fmt is used as the format for a strftime call.
-#today_fmt = '%B %d, %Y'
-
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-exclude_patterns = ['_build']
-
-# The reST default role (used for this markup: `text`) to use for all
-# documents.
-#default_role = None
-
-# If true, '()' will be appended to :func: etc. cross-reference text.
-#add_function_parentheses = True
-
-# If true, the current module name will be prepended to all description
-# unit titles (such as .. function::).
-#add_module_names = True
-
-# If true, sectionauthor and moduleauthor directives will be shown in the
-# output. They are ignored by default.
-#show_authors = False
-
-# The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
-
-# A list of ignored prefixes for module index sorting.
-#modindex_common_prefix = []
-
-# If true, keep warnings as "system message" paragraphs in the built documents.
-#keep_warnings = False
-
-# If true, `todo` and `todoList` produce output, else they produce nothing.
-todo_include_todos = False
-
-rst_epilog = """
-.. include:: /substitutions.rst
-"""
-
-# -- Options for HTML output ----------------------------------------------
-
-# The theme to use for HTML and HTML Help pages.  See the documentation for
-# a list of builtin themes.
-html_theme = 'clearlinux'
-#html_theme = 'zephyr'
-
-# Theme options are theme-specific and customize the look and feel of a theme
-# further.  For a list of options available for each theme, see the
-# documentation.
-#html_theme_options = {}
-
-# Add any paths that contain custom themes here, relative to this directory.
-html_theme_path = ['_themes']
-
-# The name for this set of Sphinx documents.  If None, it defaults to
-# "<project> v<release> documentation".
-html_title = "Documentation for Clear Linux* Project for Intel(r) Architecture"
-
-# A shorter title for the navigation bar.  Default is the same as html_title.
-#html_short_title = None
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-#html_logo = None
-
-# The name of an image file (within the static path) to use as favicon of the
-# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
-# pixels large.
-#html_favicon = None
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
-
-# Add any extra paths that contain custom files (such as robots.txt or
-# .htaccess) here, relative to this directory. These files are copied
-# directly to the root of the documentation.
-#html_extra_path = []
-
-# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
-# using the given strftime format.
-html_last_updated_fmt = '%b %d, %Y'
-
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-#html_use_smartypants =
-
-# Custom sidebar templates, maps document names to template names.
-#html_sidebars = {}
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-#html_additional_pages = {}
-
-# If false, no module index is generated.
-html_domain_indices = False
-
-# If false, no index is generated.
-html_use_index = True
-
-# If true, the index is split into individual pages for each letter.
-html_split_index = True
-
-# If true, links to the reST sources are added to the pages.
-#html_show_sourcelink =
-
-# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
-#html_show_sphinx = True
-
-# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
-html_show_copyright = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a <link> tag referring to it.  The value of this option must be the
-# base URL from which the finished HTML is served.
-#html_use_opensearch = ''
-
-# This is the file name suffix for HTML files (e.g. ".xhtml").
-#html_file_suffix = None
-
-# Language to be used for generating the HTML full-text search index.
-# Sphinx supports the following languages:
-#   'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'
-#   'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr'
-#html_search_language = 'en'
-
-# A dictionary with options for the search language support, empty by default.
-# Now only 'ja' uses this config value
-#html_search_options = {'type': 'default'}
-
-# The name of a javascript file (relative to the configuration directory) that
-# implements a search results scorer. If empty, the default will be used.
-#html_search_scorer = 'scorer.js'
-
-# Output file base name for HTML help builder.
-htmlhelp_basename = 'clrdoc'
-
-# -- Options for LaTeX output ---------------------------------------------
-
-latex_elements = {
-# The paper size ('letterpaper' or 'a4paper').
-#'papersize': 'letterpaper',
-
-# The font size ('10pt', '11pt' or '12pt').
-#'pointsize': '10pt',
-
-# Additional stuff for the LaTeX preamble.
-#'preamble': '',
-
-# Latex figure (float) alignment
-#'figure_align': 'htbp',
-}
-
-# Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title,
-#  author, documentclass [howto, manual, or own class]).
-latex_documents = [
-  (master_doc, 'clr.tex', u'Documentation for Clear Linux* Project for Intel® Architecture',
-   u'many', 'manual'),
-]
-
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-#latex_logo = None
-
-# For "manual" documents, if this is true, then toplevel headings are parts,
-# not chapters.
-#latex_use_parts = False
-
-# If true, show page references after internal links.
-#latex_show_pagerefs = False
-
-# If true, show URL addresses after external links.
-#latex_show_urls = False
-
-# Documents to append as an appendix to all manuals.
-#latex_appendices = []
-
-# If false, no module index is generated.
-#latex_domain_indices = True
-
-
-# -- Options for manual page output ---------------------------------------
-
-# One entry per manual page. List of tuples
-# (source start file, name, description, authors, manual section).
-man_pages = [
-    (master_doc, 'clearlinux', u'Documentation for Clear Linux* Project for Intel® Architecture',
-     [author], 1)
-]
-
-# If true, show URL addresses after external links.
-#man_show_urls = False
-
-
-# -- Options for Texinfo output -------------------------------------------
-
-# Grouping the document tree into Texinfo files. List of tuples
-# (source start file, target name, title, author,
-#  dir menu entry, description, category)
-texinfo_documents = [
-  (master_doc, 'clearlinux', u'Documentation for Clear Linux* Project for Intel® Architecture',
-   author, 'Clear Linux', 'One line description of project.',
-   'Miscellaneous'),
-]
-
-# Documents to append as an appendix to all manuals.
-#texinfo_appendices = []
-
-# If false, no module index is generated.
-#texinfo_domain_indices = True
-
-# How to display URL addresses: 'footnote', 'no', or 'inline'.
-#texinfo_show_urls = 'footnote'
-
-# If true, do not generate a @detailmenu in the "Top" node's menu.
-#texinfo_no_detailmenu = False
-
-# If true, generates permalinks on the HTML output.
+# -*- coding: utf-8 -*-
+#
+# Clear Linux documentation build configuration file, created by
+# sphinx-quickstart on Fri May  8 11:43:01 2015.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys
+import os
+import shlex
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#sys.path.insert(0, os.path.abspath('.'))
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+#extensions = [
+#    'sphinx.ext.autodoc', 'breathe', 'sphinx.ext.todo'
+#]
+
+extensions = [
+    'sphinx.ext.autodoc', 'sphinx.ext.todo'
+]
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+# source_suffix = ['.rst', '.md']
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'Clear Linux* Project for Intel® Architecture'
+copyright = u'2016, many'
+author = u'many'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = '0.1'
+# The full version, including alpha/beta/rc tags.
+release = '0.1'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = ['_build']
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+#keep_warnings = False
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = False
+
+rst_epilog = """
+.. include:: /substitutions.rst
+"""
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+html_theme = 'clearlinux'
+#html_theme = 'zephyr'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+html_theme_path = ['_themes']
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+html_title = "Documentation for Clear Linux* Project for Intel(r) Architecture"
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# Add any extra paths that contain custom files (such as robots.txt or
+# .htaccess) here, relative to this directory. These files are copied
+# directly to the root of the documentation.
+#html_extra_path = []
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants =
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+html_domain_indices = False
+
+# If false, no index is generated.
+html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+html_split_index = True
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink =
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+#html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = None
+
+# Language to be used for generating the HTML full-text search index.
+# Sphinx supports the following languages:
+#   'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'
+#   'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr'
+#html_search_language = 'en'
+
+# A dictionary with options for the search language support, empty by default.
+# Now only 'ja' uses this config value
+#html_search_options = {'type': 'default'}
+
+# The name of a javascript file (relative to the configuration directory) that
+# implements a search results scorer. If empty, the default will be used.
+#html_search_scorer = 'scorer.js'
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'clrdoc'
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+#'papersize': 'letterpaper',
+
+# The font size ('10pt', '11pt' or '12pt').
+#'pointsize': '10pt',
+
+# Additional stuff for the LaTeX preamble.
+#'preamble': '',
+
+# Latex figure (float) alignment
+#'figure_align': 'htbp',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+#  author, documentclass [howto, manual, or own class]).
+latex_documents = [
+  (master_doc, 'clr.tex', u'Documentation for Clear Linux* Project for Intel® Architecture',
+   u'many', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# If true, show page references after internal links.
+#latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+#latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_domain_indices = True
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    (master_doc, 'clearlinux', u'Documentation for Clear Linux* Project for Intel® Architecture',
+     [author], 1)
+]
+
+# If true, show URL addresses after external links.
+#man_show_urls = False
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+#  dir menu entry, description, category)
+texinfo_documents = [
+  (master_doc, 'clearlinux', u'Documentation for Clear Linux* Project for Intel® Architecture',
+   author, 'Clear Linux', 'One line description of project.',
+   'Miscellaneous'),
+]
+
+# Documents to append as an appendix to all manuals.
+#texinfo_appendices = []
+
+# If false, no module index is generated.
+#texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+#texinfo_no_detailmenu = False
+
+# If true, generates permalinks on the HTML output.
 html_add_permalinks = False

source/disclaimers.rst

@@ -1,10 +1,11 @@
-.. _disclaimers:
-
-
-.. rubric:: Disclaimer
-
-.. important::
-   This documentation is a work in progress and is being provided for
-   informative purposes only. Because it is a work in progress, there are
-   parts that are either missing or will be revised as code development
-   continues.
+.. _disclaimers:
+
+
+Disclaimers
+###########
+
+.. important::
+   This documentation is a work in progress and is being provided for
+   informative purposes only. Because it is a work in progress, there are
+   parts that are either missing or will be revised as code development
+   continues.

source/documentation_license.rst

@@ -1,10 +1,15 @@
-.. raw:: html
-
-   <a rel="license"
-   href="http://creativecommons.org/licenses/by/4.0/"><img
-   alt="Creative Commons License" style="border-width:0"
-   src="https://i.creativecommons.org/l/by/4.0/88x31.png" /></a><br
-   />This work is licensed under a <a rel="license"
-   href="http://creativecommons.org/licenses/by/4.0/">Creative Commons
-   Attribution 4.0 International License</a>
-
+.. _license:
+
+License
+#######
+
+.. raw:: html
+
+   <a rel="license"
+   href="http://creativecommons.org/licenses/by/4.0/"><img
+   alt="Creative Commons License" style="border-width:0"
+   src="https://i.creativecommons.org/l/by/4.0/88x31.png" /></a><br
+   />This work is licensed under a <a rel="license"
+   href="http://creativecommons.org/licenses/by/4.0/">Creative Commons
+   Attribution 4.0 International License</a>
+

source/gs/boot-usb.rst

@@ -1,78 +1,78 @@
-.. _gs_creating_bootable_usb:
-
-Creating a bootable USB to install the OS
-##########################################
-
-Here's how to create a USB drive that initiates the process for
-:ref:`gs_installing_clr_as_host`. Alternatively, you can test the 
-OS by :ref:`vm-kvm`.
-
-
-What you need
-=============
-
-* A USB stick, formatted as ``ext4``. Remember that the process of 
-  flashing data to a USB completely deletes the contents of the
-  drive; as always, run ``dd`` with caution.
-* A Clear Linux* OS for Intel® Architecture image; the most current
-  release versions can be found at the following link:
-  `https://download.clearlinux.org/image <https://download.clearlinux.org/image>`_
-* Older versions can be found on our `downloads page`_.
-
-
-Download and checksum
-=====================
-
-::
-
-  $ wget https://download.clearlinux.org/image/clear-[release_number]-installer.img.xz
-  $ sha512sum clear-[release_number]-installer.img.xz
-
-
-Confirm the mount point on the USB drive
-========================================
-
-Using ``$ lsblk`` is helpful to show the block-level devices; 
-a USB drive usually shows up under ``/sdb`` or ``/sdc`` (almost never
-under ``/sda``), and should indicate disk space approximately the 
-size of the USB drive::
-
-	$ lsblk /dev/sdb
-	NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
-	?? sdb  8:16 1 14.9G 0
-	?? sdb1 8:17 1 14.9G 0 part
-
-Make sure the drive isn't already mounted. The easiest way is with 
-``umount`` or
-
-::
-
-	# df
-
-
-Flash the image to the USB
-==========================
-
-Flash the image with the following command, adding the ``-v`` option 
-for verbose mode (recommended), as the image file may be large, and the 
-write can take a while. This may need to be done as root or with sudo::
-
-  $ xzcat -v clear-[release_number]-installer.img.xz | dd of=/dev/sdb
-
-
-Wait for the final confirmation
-===============================
-
-This example shows ``clear-9130-installer.img.xz`` flashed to a 16GB 
-USB drive mounted on ``/sdb``.
-
-.. image:: _static/images/gs_confirmation_screen.png
-   :align: center
-   :alt: confirmation
-
-Success!  Your USB stick is now ready to boot and initiate the process for
-:ref:`gs_installing_clr_as_host`.
-
-
-
-.. _downloads page: https://download.clearlinux.org
+.. _gs_creating_bootable_usb:
+
+Creating a bootable USB to install the OS
+##########################################
+
+Here's how to create a USB drive that initiates the process for
+:ref:`gs_installing_clr_as_host`. Alternatively, you can test the
+OS by :ref:`vm-kvm`.
+
+
+What you need
+=============
+
+* A USB stick, formatted as ``ext4``. Remember that the process of
+  flashing data to a USB completely deletes the contents of the
+  drive; as always, run ``dd`` with caution.
+* A Clear Linux* OS for Intel® Architecture image; the most current
+  release versions can be found at the following link:
+  `https://download.clearlinux.org/image <https://download.clearlinux.org/image>`_
+* Older versions can be found on our `downloads page`_.
+
+
+Download and checksum
+=====================
+
+::
+
+  $ wget https://download.clearlinux.org/image/clear-[release_number]-installer.img.xz
+  $ sha512sum clear-[release_number]-installer.img.xz
+
+
+Confirm the mount point on the USB drive
+========================================
+
+Using ``$ lsblk`` is helpful to show the block-level devices;
+a USB drive usually shows up under ``/sdb`` or ``/sdc`` (almost never
+under ``/sda``), and should indicate disk space approximately the
+size of the USB drive::
+
+	$ lsblk /dev/sdb
+	NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
+	?? sdb  8:16 1 14.9G 0
+	?? sdb1 8:17 1 14.9G 0 part
+
+Make sure the drive isn't already mounted. The easiest way is with
+``umount`` or
+
+::
+
+	# df
+
+
+Flash the image to the USB
+==========================
+
+Flash the image with the following command, adding the ``-v`` option
+for verbose mode (recommended), as the image file may be large, and the
+write can take a while. This may need to be done as root or with sudo::
+
+  $ xzcat -v clear-[release_number]-installer.img.xz | dd of=/dev/sdb
+
+
+Wait for the final confirmation
+===============================
+
+This example shows ``clear-9130-installer.img.xz`` flashed to a 16GB
+USB drive mounted on ``/sdb``.
+
+.. image:: ../_static/images/gs/gs_confirmation_screen.png
+   :align: center
+   :alt: confirmation
+
+Success!  Your USB stick is now ready to boot and initiate the process for
+:ref:`gs_installing_clr_as_host`.
+
+
+
+.. _downloads page: https://download.clearlinux.org

source/gs/clear-containers.rst

@@ -1,47 +1,47 @@
-.. _gs-clear-containers-getting-started:
-
-Clear Containers getting started guide
-######################################
-
-
-Introduction
-============
-
-Intel® Clear Containers v2.0 beta release is now available for evaluation.
-This enables executing existing Docker applications in the secure
-and fast Intel Clear Containers environment under Docker* 1.12 and beyond
-via an :abbr:`Open Container Initiative (OCI)` compatible `runtime`.
-
-Installation instructions
-=========================
-
-The primary host platform is Clear Linux* Project for Intel® 
-Architecture. For instructions on installing Docker and Clear Containers under
-Clear Linux, please refer to instructions from the runtime source tree:
-
-	•	https://github.com/01org/cc-oci-runtime/wiki/Installation
-
-If you have any feedback, questions, or would like to participate and
-contribute, then  please consult the contact details (mailing list, IRC etc.)
-in the document at:
-
-- https://github.com/01org/cc-oci-runtime/blob/master/CONTRIBUTING.md
-
-Source Code
-===========
-
-The source code for the Clear Containers 2.0 runtime and corresponding
-qemu-lite are publicly hosted on github:
-
-- https://github.com/01org/cc-oci-runtime
-- https://github.com/01org/qemu-lite
-
-Architecture Overview
-=====================
-
-Please see the the `Architecture Overview`_ section.
-
-
-
-.. _Architecture Overview: https://clearlinux.org/documentation/clear-containers.html#architecture-overview
-
+.. _gs-clear-containers-getting-started:
+
+Clear Containers getting started guide
+######################################
+
+
+Introduction
+============
+
+Intel® Clear Containers v2.0 beta release is now available for evaluation.
+This enables executing existing Docker applications in the secure
+and fast Intel Clear Containers environment under Docker* 1.12 and beyond
+via an :abbr:`Open Container Initiative (OCI)` compatible `runtime`.
+
+Installation instructions
+=========================
+
+The primary host platform is Clear Linux* Project for Intel® 
+Architecture. For instructions on installing Docker and Clear Containers under
+Clear Linux, please refer to instructions from the runtime source tree:
+
+	•	https://github.com/01org/cc-oci-runtime/wiki/Installation
+
+If you have any feedback, questions, or would like to participate and
+contribute, then  please consult the contact details (mailing list, IRC etc.)
+in the document at:
+
+- https://github.com/01org/cc-oci-runtime/blob/master/CONTRIBUTING.md
+
+Source Code
+===========
+
+The source code for the Clear Containers 2.0 runtime and corresponding
+qemu-lite are publicly hosted on github:
+
+- https://github.com/01org/cc-oci-runtime
+- https://github.com/01org/qemu-lite
+
+Architecture Overview
+=====================
+
+Please see the the `Architecture Overview`_ section.
+
+
+
+.. _Architecture Overview: https://clearlinux.org/documentation/clear-containers.html#architecture-overview
+

source/gs/clear-host.rst

@@ -1,32 +1,32 @@
-.. _gs_installing_clr_as_host:
-
-Installing the OS as host
-#########################
-
-Running Clear Linux* OS for Intel® Architecture natively on a system is
-easy with the installer image. To get started you'll need the following:
-
-* A USB stick flashed with the `installer image`_.  For instructions on how to
-  do this, see :ref:`gs_creating_bootable_usb`.
-* A host machine running :ref:`gs_supported_hardware`.
-* Network access via DHCP.
-
-Installing Clear Linux OS for Intel Architecture to a target system
-===================================================================
-
-#. Configure the BIOS; this may involve changing the priority of the boot 
-   device to boot from USB port first. 
-#. Insert the USB device that is flashed with the 
-   `installer image`_ into the target system, then reboot. 
-#. The installer user interface will appear. Once all appropriate configuration
-   options have been chosen, the installer will install the OS.
-
-The entire installation should take no more than a few minutes. 
-
-For feedback on installation or other topics, please feel free to write in to our 
-`mailing list`_.
-
-Note: You can also try :ref:`vm-kvm`.
-
-.. _installer image: http://download.clearlinux.org/image
-.. _mailing list: https://lists.clearlinux.org/mailman/listinfo/dev
+.. _gs_installing_clr_as_host:
+
+Installing the OS as host
+#########################
+
+Running Clear Linux* OS for Intel® Architecture natively on a system is
+easy with the installer image. To get started you'll need the following:
+
+* A USB stick flashed with the `installer image`_.  For instructions on how to
+  do this, see :ref:`gs_creating_bootable_usb`.
+* A host machine running :ref:`gs_supported_hardware`.
+* Network access via DHCP.
+
+Installing Clear Linux OS for Intel Architecture to a target system
+===================================================================
+
+#. Configure the BIOS; this may involve changing the priority of the boot 
+   device to boot from USB port first. 
+#. Insert the USB device that is flashed with the 
+   `installer image`_ into the target system, then reboot. 
+#. The installer user interface will appear. Once all appropriate configuration
+   options have been chosen, the installer will install the OS.
+
+The entire installation should take no more than a few minutes. 
+
+For feedback on installation or other topics, please feel free to write in to our 
+`mailing list`_.
+
+Note: You can also try :ref:`vm-kvm`.
+
+.. _installer image: http://download.clearlinux.org/image
+.. _mailing list: https://lists.clearlinux.org/mailman/listinfo/dev

source/gs/index.rst

@@ -0,0 +1,11 @@
+Getting started
+###############
+
+.. toctree::
+   :maxdepth: 2
+
+   overview
+   supported-hardware
+   boot-usb
+   clear-host
+   clear-containers

source/gs/overview.rst

@@ -1,83 +1,83 @@
-.. _gs_getting_started:
-
-Getting started
-###############
-
-There are a number of options available for downloading and running Clear 
-Linux* OS for Intel® Architecture. You can check your system hardware
-capabilities against the list of `supported processors`_; alternatively,
-download and run the `clear-linux-check-config`_ script to check the hardware
-compatibility of your system from the command line.
-
-
-Virtualized images
-==================
-
-Images are also available to run under Virtual Machines or containers.
-
-To test whether your host contains the necessary components to run the OS in
-a container, download the `clear-linux-check-config`_ script and run::
-
-   $ ./clear-linux-check-config.sh container
-
-* **KVM Image** -- Download a recent KVM image, along with the UEFI firmware helper,
-  ``OVMF.fd`` and the KVM start helper script ``start_qemu.sh.`` Find the
-  ``clear-[version_number]-kvm.img.xz`` image in the `current`_ directory and see
-  :ref:`vm-kvm` for further detail.
-
-* **Docker Image** -- A Clear Linux* Docker* image can be downloaded
-  directly from the Docker hub and executed within the Docker environment.
-  Details were posted in the blog post `Clear Linux Highlights 3`_, and
-  on a Docker* enabled system you can execute::
-
-    docker pull clearlinux
-    docker run -it clearlinux
-
-  and then follow the normal Clear Linux* instuctions to add bundles etc.
-
-
-Bare metal installer images
-===========================
-
-To test whether your system contains the necessary components to run the OS natively,
-download the `clear-linux-check-config`_ script and run::
-
-   $ ./clear-linux-check-config.sh host
-
-
-* **Installer Image** -- The installer image allows you to manipulate and target
-  partitions, and to set other OS configuration features (hostname, administrative user)
-  commonly found in Linux installers. Find the ``clear-[version_number]-installer.img.xz``
-  in our `current`_ directory and see :ref:`gs_installing_clr_as_host`. This `blog post`_
-  contains more detail about the evolution of our installer.
-
-* **Provisioning Image** -- This image is intended to be used in a provioning environment.
-  Find the ``clear-[version_number]-provision.img.xz`` image in our `current`_ directory.
-  *Warning*: This installer repartitions ``/dev/sda`` and installs the OS to the new
-  partition. Don't use this image on a system where you care about existing data on
-  ``/dev/sda``.
-
-
-Other installation options
-==========================
-
-* **Live Image** -- The live image can be used to boot the OS in a VM, or you can lay
-  the image down on a USB drive with a tool like ``dd`` and boot from USB.
-
-  This option is a great way to kick the tires with a minimal amount of effort.  Be
-  aware, however, that if you do **not** manually configure the install and instead use
-  the auto-install, it will repartition ``/dev/sda``.  This image also enables telemetry
-  by default; see the `telemetry`_ feature page for more details.
-
-  To select this option, download the ``clear-[version_number]-live.img.xz`` image in
-  the `current`_ version's download directory.
-
-For older versions, see our `releases`_ page.
-
-.. _clear-linux-check-config: http://download.clearlinux.org/current/clear-linux-check-config.sh
-.. _current: http://download.clearlinux.org/current
-.. _blog post: https://clearlinux.org/blogs/clear-linux-installer-v20
-.. _Clear Linux Highlights 3: https://clearlinux.org/blogs/clear-linux-highlights-3
-.. _telemetry: https://clearlinux.org/features/telemetry
-.. _supported processors: http://clearlinux.org/documentation/gs_supported_hardware.html
-.. _releases: https://download.clearlinux.org/releases
+.. _gs_getting_started:
+
+Getting started
+###############
+
+There are a number of options available for downloading and running Clear 
+Linux* OS for Intel® Architecture. You can check your system hardware
+capabilities against the list of `supported processors`_; alternatively,
+download and run the `clear-linux-check-config`_ script to check the hardware
+compatibility of your system from the command line.
+
+
+Virtualized images
+==================
+
+Images are also available to run under Virtual Machines or containers.
+
+To test whether your host contains the necessary components to run the OS in
+a container, download the `clear-linux-check-config`_ script and run::
+
+   $ ./clear-linux-check-config.sh container
+
+* **KVM Image** -- Download a recent KVM image, along with the UEFI firmware helper,
+  ``OVMF.fd`` and the KVM start helper script ``start_qemu.sh.`` Find the
+  ``clear-[version_number]-kvm.img.xz`` image in the `current`_ directory and see
+  :ref:`vm-kvm` for further detail.
+
+* **Docker Image** -- A Clear Linux* Docker* image can be downloaded
+  directly from the Docker hub and executed within the Docker environment.
+  Details were posted in the blog post `Clear Linux Highlights 3`_, and
+  on a Docker* enabled system you can execute::
+
+    docker pull clearlinux
+    docker run -it clearlinux
+
+  and then follow the normal Clear Linux* instuctions to add bundles etc.
+
+
+Bare metal installer images
+===========================
+
+To test whether your system contains the necessary components to run the OS natively,
+download the `clear-linux-check-config`_ script and run::
+
+   $ ./clear-linux-check-config.sh host
+
+
+* **Installer Image** -- The installer image allows you to manipulate and target
+  partitions, and to set other OS configuration features (hostname, administrative user)
+  commonly found in Linux installers. Find the ``clear-[version_number]-installer.img.xz``
+  in our `current`_ directory and see :ref:`gs_installing_clr_as_host`. This `blog post`_
+  contains more detail about the evolution of our installer.
+
+* **Provisioning Image** -- This image is intended to be used in a provioning environment.
+  Find the ``clear-[version_number]-provision.img.xz`` image in our `current`_ directory.
+  *Warning*: This installer repartitions ``/dev/sda`` and installs the OS to the new
+  partition. Don't use this image on a system where you care about existing data on
+  ``/dev/sda``.
+
+
+Other installation options
+==========================
+
+* **Live Image** -- The live image can be used to boot the OS in a VM, or you can lay
+  the image down on a USB drive with a tool like ``dd`` and boot from USB.
+
+  This option is a great way to kick the tires with a minimal amount of effort.  Be
+  aware, however, that if you do **not** manually configure the install and instead use
+  the auto-install, it will repartition ``/dev/sda``.  This image also enables telemetry
+  by default; see the `telemetry`_ feature page for more details.
+
+  To select this option, download the ``clear-[version_number]-live.img.xz`` image in
+  the `current`_ version's download directory.
+
+For older versions, see our `releases`_ page.
+
+.. _clear-linux-check-config: http://download.clearlinux.org/current/clear-linux-check-config.sh
+.. _current: http://download.clearlinux.org/current
+.. _blog post: https://clearlinux.org/blogs/clear-linux-installer-v20
+.. _Clear Linux Highlights 3: https://clearlinux.org/blogs/clear-linux-highlights-3
+.. _telemetry: https://clearlinux.org/features/telemetry
+.. _supported processors: http://clearlinux.org/documentation/gs_supported_hardware.html
+.. _releases: https://download.clearlinux.org/releases

source/gs/supported-hardware.rst

@@ -1,25 +1,25 @@
-.. _gs_supported_hardware:
-
-Supported hardware
-##################
-
-Clear Linux* OS for Intel® Architecture can be successfully run in 4th
-Generation Intel® Core™ processor family and later generations.
-The following processors have been tested to work correctly:
-
--  4th Generation Intel® Core™ processor.
--  5th Generation Intel® Core™ processor.
--  6th Generation Intel® Core™ processor.
--  Intel® Xeon® Processor E5 v3 processor.
--  Intel® Xeon® Processor E3 v5 processor.
-
-
-If you're unsure whether your system will be capable of running Clear Linux*
-OS for Intel® Architecture, you can determine ahead of time by downloading
-and running the simple `clear-linux-check-config.sh`_ script locally. This script
-is available in the `current`_ download directory; it checks the hardware
-capabilities of your system to determine whether it will work with the
-latest release.
-
-.. _clear-linux-check-config.sh: http://download.clearlinux.org/current/clear-linux-check-config.sh
-.. _current: http://download.clearlinux.org/current
+.. _gs_supported_hardware:
+
+Supported hardware
+##################
+
+Clear Linux* OS for Intel® Architecture can be successfully run in 4th
+Generation Intel® Core™ processor family and later generations.
+The following processors have been tested to work correctly:
+
+-  4th Generation Intel® Core™ processor.
+-  5th Generation Intel® Core™ processor.
+-  6th Generation Intel® Core™ processor.
+-  Intel® Xeon® Processor E5 v3 processor.
+-  Intel® Xeon® Processor E3 v5 processor.
+
+
+If you're unsure whether your system will be capable of running Clear Linux*
+OS for Intel® Architecture, you can determine ahead of time by downloading
+and running the simple `clear-linux-check-config.sh`_ script locally. This script
+is available in the `current`_ download directory; it checks the hardware
+capabilities of your system to determine whether it will work with the
+latest release.
+
+.. _clear-linux-check-config.sh: http://download.clearlinux.org/current/clear-linux-check-config.sh
+.. _current: http://download.clearlinux.org/current

source/index-openstack.rst

@@ -1,13 +0,0 @@
-OpenStack* implementation
-#########################
-
-.. toctree::
-   :maxdepth: 1
-
-   openstack_use_cases
-   openstack_bundle_and_service_summary
-   installing_openstack
-   configure_openstack_environment
-   openstack_env_inventory_file
-   openstack_conf_vars_about
-   openstack_conf_vars_list

source/index-ts.rst

@@ -1,13 +0,0 @@
-Tutorials
-#########
-
-.. toctree::
-   :maxdepth: 2
-
-   gs-clear-containers-getting-started
-   ciao-deploy
-   ciao-cluster-setup-quick.rst
-   ciao-cluster-setup
-
-
-

source/index.rst

@@ -1,84 +1,93 @@
-.. ClearLinux Documentation documentation master file, created by
-   sphinx-quickstart on Fri Nov 13 12:23:35 2015. 
-   You can adapt this file completely to your liking, but it should at least
-   contain the root `toctree` directive.
-
-Clear Linux* Project for Intel® Architecture--Documentation
-############################################################
-
-
-Getting started
-================
-
-.. toctree::
-   :maxdepth: 2
-
-   index_gs.rst
-
-
-Running in a virtualized environment
-====================================
-
-.. toctree::
-   :maxdepth: 2
-
-   index_vm.rst
-
-
-Software update
-===============
-
-.. toctree::
-   :maxdepth: 2
-
-   index_sw_update.rst
-
-
-Bundles
-=======
-
-.. toctree::
-   :maxdepth: 2
-
-   index_bundles.rst
-
-
-Advanced configuration
-======================
-
-.. toctree::
-   :maxdepth: 2
-
-   index_advanced_configuration.rst
-
-
-Storage solutions
-=================
-
-.. toctree::
-   :maxdepth: 2
-
-   index-storage.rst
-
-
-Tutorials
-=========
-
-.. toctree::
-   :maxdepth: 2
-
-   index-ts.rst
-
-
-Indices and tables
-==================
-
-* :ref:`genindex`
-* :ref:`modindex`
-* :ref:`search`
-
-License and disclaimers
-=======================
-.. toctree::
-
-.. include:: documentation_license.rst
+.. ClearLinux Documentation documentation master file, created by
+   sphinx-quickstart on Fri Nov 13 12:23:35 2015.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+Clear Linux* Project for Intel® Architecture--Documentation
+############################################################
+
+
+Getting started
+================
+
+.. toctree::
+   :maxdepth: 2
+
+   gs/index.rst
+
+
+Running in a virtualized environment
+====================================
+
+.. toctree::
+   :maxdepth: 2
+
+   vm/index.rst
+
+
+Software update
+===============
+
+.. toctree::
+   :maxdepth: 2
+
+   update/index.rst
+
+
+Bundles
+=======
+
+.. toctree::
+   :maxdepth: 2
+
+   bundles/index.rst
+
+
+Advanced configuration
+======================
+
+.. toctree::
+   :maxdepth: 2
+
+   advanced/index.rst
+
+
+Storage solutions
+=================
+
+.. toctree::
+   :maxdepth: 2
+
+   storage/index.rst
+
+
+CIAO
+====
+
+.. toctree::
+   :maxdepth: 2
+
+   ciao/index.rst
+
+OpenStack
+=========
+
+.. toctree::
+   :maxdepth: 2
+
+   openstack/index.rst
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
+
+License and disclaimers
+=======================
+
+.. toctree::
+
+   documentation_license.rst
+   disclaimers.rst

source/index_bundles.rst

@@ -1,10 +0,0 @@
-Bundles
-#######
-
-.. toctree::
-   :maxdepth: 2
-
-   bundles_overview
-   bdl-containers-basic
-   bdl-openssh-server
-   bdl-os-core

source/index_gs.rst

@@ -1,12 +0,0 @@
-Getting started
-###############
-
-.. toctree::
-   :maxdepth: 2
-
-   gs_getting_started
-   gs_supported_hardware
-   gs_creating_bootable_usb
-   gs_installing_clr_as_host
-
-

source/openstack/about-conf-variables.rst

@@ -1,14 +1,14 @@
-.. _openstack_conf_vars_about:
-
-About "group_vars/all"
-######################
-
-The ``group_vars/all`` section is where you will specify the
-values for your passwords and other required or optional parameters.
-
-Variables in this section are built with yaml format.
-
-For a more detailed reference of the numerous variables and parameters
-that can be set, see the :ref:`openstack_conf_vars_list`.
-
-**Back to Configuration Section** :ref:`configure_openstack_environment`
+.. _openstack_conf_vars_about:
+
+About "group_vars/all"
+######################
+
+The ``group_vars/all`` section is where you will specify the
+values for your passwords and other required or optional parameters.
+
+Variables in this section are built with yaml format.
+
+For a more detailed reference of the numerous variables and parameters
+that can be set, see the :ref:`openstack_conf_vars_list`.
+
+**Back to Configuration Section** :ref:`configure_openstack_environment`

source/openstack/conf-variables.rst

@@ -1,62 +1,62 @@
-.. _openstack_conf_vars_list:
-
-Variables for OpenStack* Deployment
-###################################
-
-This installer provides a variety of configurations you can set through
-variables; below you will find a reference of the components supported
-with Clear Linux* OS for Intel® Architecture.
-
-Required Variables
-==================
-
-.. csv-table::
-   :header: "*(Component)* `Variable`", "Description"
-   :widths: 90, 150
-
-   "*(Heat, Neutron, Nova, RabbitMQ)* **rabbitmq_password**", "Password of RabbitMQ user "
-   "*(ALL)* **database_root_password**","Password for root database user"
-   "*(Keystone)* **keystone_database_password**", "Password for 'keystone' database"
-   "*(ALL)* **keystone_admin_password**", "Password for 'admin' user"
-   "*(Glance)* **glance_user_password**", "Password for 'glance' user"
-   "*(Glance)* **glance_database_password**", "Password for 'glance' database"
-   "*(Neutron, Nova)* **nova_user_password**", "Password for 'nova' user"
-   "*(Nova)* **nova_database_password**", "Password for 'nova' database"
-   "*(Neutron)* **neutron_database_password**", "Password for 'neutron' database"
-   "*(Neutron, Nova)* **neutron_user_password**", "Password for 'neutron' user"
-   "*(Neutron, Nova)* **metadata_proxy_shared_secret**", "Secret for the metadata proxy"
-   "*(Heat)* **heat_domain_admin_password**", "Password for heat domain admin user"
-   "*(Heat)* **heat_user_password**", "Password for heat user"
-   "*(Heat)* **heat_database_password**", "Password for heat database"
-   "*(Heat)* **heat_domain**", "The heat domain that contains projects and users for stacks"
-   "*(Swift)* **swift_user_password**", "Password for 'swift' user"
-   "*(Swift)* **swift_database_password**", "Password for 'swift' database"
-   "*(Swift)* **swift_replica_count**", "Replica number for each object. IMPORTANT: This number must be lower than the sum of all the storage devices among all storage nodes. It can be changed later."
-   "*(Swift)* **swift_hash_path_suffix**", "Suffix for the object path name"
-   "*(Swift)* **swift_hash_path_prefix**", "Prefix for the object path name"
-   "*(Swift)* **swift_storage_device_path**", "The path of the storage devices"
-   "*(Swift)* **swift_storage_devices**", "A list of the storage devices dedicated to swift deployment. For more information, see :ref:`openstack_swift_deployment_scenarios`"
-
-Optional Variables
-==================
-
-.. csv-table::
-   :header: "*(Component)* **Variable** : Default value", "Description"
-   :widths: 90, 150
-
-   "*(ALL)* **swupd_args**: unset", "Optional arguments for swupd"
-   "*(ALL)* **log_debug**: False", "Set to True to enable debug log level on all services"
-   "*(Heat, Neutron, Nova, RabbitMQ)* **rabbitmq_username**: openstack", "User ID for RabbitMQ"
-   "*(Neutron, Nova)* **neutron_public_interface_name**: unset", "Public interface of Neutron machines, if is not set, it will take the default interface reported by **ip route**"
-   "*(Nova)* **nova_public_interface_name**: unset", "Public interface of Neutron machines, if is not set, it will take the default interface reported by **ip route**"
-   "*(Nova)* **nova_virt_type**: qemu", "Virtualization type (qemu | kvm), if this is not set, then the playbook will try to guess it"
-   "*(Neutron)* **os_tuning_params**: net.ipv4.ip_forward: 1, net.ipv4.conf.default.rp_filter: 0, net.ipv4.conf.all.rp_filter: 0, net.bridge.bridge-nf-call-iptables: 1, net.bridge.bridge-nf-call-ip6tables: 1", "syctl values needed by neutron when using openvswitch deployment scenario"
-   "*(Swift)* **swift_public_interface_name**, "Public interface of storage nodes, also known as the storage network interface name; If is not set, it will take the default interface reported by **ip route**"
-
-
-Note:
------
-If you would like to override a default, you can define it in the
-:ref:`openstack_conf_vars_about`.
-
-**Back to Configuration Section** :ref:`configure_openstack_environment`
+.. _openstack_conf_vars_list:
+
+Variables for OpenStack* Deployment
+###################################
+
+This installer provides a variety of configurations you can set through
+variables; below you will find a reference of the components supported
+with Clear Linux* OS for Intel® Architecture.
+
+Required Variables
+==================
+
+.. csv-table::
+   :header: "*(Component)* `Variable`", "Description"
+   :widths: 90, 150
+
+   "*(Heat, Neutron, Nova, RabbitMQ)* **rabbitmq_password**", "Password of RabbitMQ user "
+   "*(ALL)* **database_root_password**","Password for root database user"
+   "*(Keystone)* **keystone_database_password**", "Password for 'keystone' database"
+   "*(ALL)* **keystone_admin_password**", "Password for 'admin' user"
+   "*(Glance)* **glance_user_password**", "Password for 'glance' user"
+   "*(Glance)* **glance_database_password**", "Password for 'glance' database"
+   "*(Neutron, Nova)* **nova_user_password**", "Password for 'nova' user"
+   "*(Nova)* **nova_database_password**", "Password for 'nova' database"
+   "*(Neutron)* **neutron_database_password**", "Password for 'neutron' database"
+   "*(Neutron, Nova)* **neutron_user_password**", "Password for 'neutron' user"
+   "*(Neutron, Nova)* **metadata_proxy_shared_secret**", "Secret for the metadata proxy"
+   "*(Heat)* **heat_domain_admin_password**", "Password for heat domain admin user"
+   "*(Heat)* **heat_user_password**", "Password for heat user"
+   "*(Heat)* **heat_database_password**", "Password for heat database"
+   "*(Heat)* **heat_domain**", "The heat domain that contains projects and users for stacks"
+   "*(Swift)* **swift_user_password**", "Password for 'swift' user"
+   "*(Swift)* **swift_database_password**", "Password for 'swift' database"
+   "*(Swift)* **swift_replica_count**", "Replica number for each object. IMPORTANT: This number must be lower than the sum of all the storage devices among all storage nodes. It can be changed later."
+   "*(Swift)* **swift_hash_path_suffix**", "Suffix for the object path name"
+   "*(Swift)* **swift_hash_path_prefix**", "Prefix for the object path name"
+   "*(Swift)* **swift_storage_device_path**", "The path of the storage devices"
+   "*(Swift)* **swift_storage_devices**", "A list of the storage devices dedicated to swift deployment. For more information, see :ref:`openstack_swift_deployment_scenarios`"
+
+Optional Variables
+==================
+
+.. csv-table::
+   :header: "*(Component)* **Variable** : Default value", "Description"
+   :widths: 90, 150
+
+   "*(ALL)* **swupd_args**: unset", "Optional arguments for swupd"
+   "*(ALL)* **log_debug**: False", "Set to True to enable debug log level on all services"
+   "*(Heat, Neutron, Nova, RabbitMQ)* **rabbitmq_username**: openstack", "User ID for RabbitMQ"
+   "*(Neutron, Nova)* **neutron_public_interface_name**: unset", "Public interface of Neutron machines, if is not set, it will take the default interface reported by **ip route**"
+   "*(Nova)* **nova_public_interface_name**: unset", "Public interface of Neutron machines, if is not set, it will take the default interface reported by **ip route**"
+   "*(Nova)* **nova_virt_type**: qemu", "Virtualization type (qemu | kvm), if this is not set, then the playbook will try to guess it"
+   "*(Neutron)* **os_tuning_params**: net.ipv4.ip_forward: 1, net.ipv4.conf.default.rp_filter: 0, net.ipv4.conf.all.rp_filter: 0, net.bridge.bridge-nf-call-iptables: 1, net.bridge.bridge-nf-call-ip6tables: 1", "syctl values needed by neutron when using openvswitch deployment scenario"
+   "*(Swift)* **swift_public_interface_name**, "Public interface of storage nodes, also known as the storage network interface name; If is not set, it will take the default interface reported by **ip route**"
+
+
+Note:
+-----
+If you would like to override a default, you can define it in the
+:ref:`openstack_conf_vars_about`.
+
+**Back to Configuration Section** :ref:`configure_openstack_environment`

source/openstack/configuration.rst

@@ -1,43 +1,43 @@
-.. _configure_openstack_environment:
-
-Configure environment
-#####################
-
-Before continuing with the installation process, it's important to understand:
-
-* The :file:`hosts` file; this file defines the roles your machines play in the
-  overall scheme of your network mapping.
-   **Note**: For more in-depth information, see :ref:`openstack_env_inventory_file`
-
-* The ``group_vars/all`` structuring can be used to override variable
-  values. **Note**: For more in-depth information, see :ref:`openstack_conf_vars_about`
-
-Once you understand these components and are comfortable modifying them to affect
-the network configuration, you can proceed as follows:
-
-#. Copy ``/usr/share/ansible/examples/openstack`` to your working directory.
-
-#. Move into the copied directory.
-
-#. Edit the :file:`hosts` file to specify node roles.
-
-#. Edit the contents under ``group_vars/all`` to set passwords and other needed
-   variables. **Note**: Default variables exist for every role in the
-   :file:`roles/<role>/defaults/main.yml` file. To override a default, define
-   it with specifications under ``group_vars/all``.
-
-
-Run the installer
-=================
-
-Finally, you can run the installer.
-
-#. Run the installer as follows, replacing ``<ssh_key>`` with the key you've
-   previously set up::
-
-    $ ansible-playbook -i hosts openstack_deployment.yml --private-key=<ssh_key>
-
-After running the previous command you should see the output of the tasks 
-that are running.
-
-At the end of the execution Ansible* will display a summary of the results.
+.. _configure_openstack_environment:
+
+Configure environment
+#####################
+
+Before continuing with the installation process, it's important to understand:
+
+* The :file:`hosts` file; this file defines the roles your machines play in the
+  overall scheme of your network mapping.
+   **Note**: For more in-depth information, see :ref:`openstack_env_inventory_file`
+
+* The ``group_vars/all`` structuring can be used to override variable
+  values. **Note**: For more in-depth information, see :ref:`openstack_conf_vars_about`
+
+Once you understand these components and are comfortable modifying them to affect
+the network configuration, you can proceed as follows:
+
+#. Copy ``/usr/share/ansible/examples/openstack`` to your working directory.
+
+#. Move into the copied directory.
+
+#. Edit the :file:`hosts` file to specify node roles.
+
+#. Edit the contents under ``group_vars/all`` to set passwords and other needed
+   variables. **Note**: Default variables exist for every role in the
+   :file:`roles/<role>/defaults/main.yml` file. To override a default, define
+   it with specifications under ``group_vars/all``.
+
+
+Run the installer
+=================
+
+Finally, you can run the installer.
+
+#. Run the installer as follows, replacing ``<ssh_key>`` with the key you've
+   previously set up::
+
+    $ ansible-playbook -i hosts openstack_deployment.yml --private-key=<ssh_key>
+
+After running the previous command you should see the output of the tasks 
+that are running.
+
+At the end of the execution Ansible* will display a summary of the results.

source/openstack/env-inventory.rst

@@ -1,61 +1,61 @@
-.. _openstack_env_inventory_file:
-
-The "hosts" file
-################
-
-The :file:`hosts` file is an inventory file where you specify, via
-``ini`` format, the roles your machine plays.
-
-The :file:`hosts` file can be structured with different groups, where each
-group plays a specific role in your environment and network mapping.
-
-Consider the following example::
-
-    [openstack_identity]
-    192.168.50.13
-
-Here, the role ``[openstack_identity]`` syntax defines the group, and
-``192.168.50.13`` specifies the machine(s) that possess that role. You
-may define multiple machines in the same group; this is a standard
-configuration for role ``[openstack_compute]`` nodes::
-
-    [openstack_compute]
-    192.168.50.16
-    192.168.50.17
-
-
-Inventory file groups
----------------------
-
-Below you will find the description of each group in the `hosts` file.
-
-.. csv-table:: "Inventory File Groups"
-   :header: "Group", "Components", "Comments"
-   :widths: 40, 40, 300
-
-   "[dbservers]", "MariaDB", ""
-   "[messaging_servers]", "RabbitMQ", ""
-   "[openstack_identity]", "Keystone, Horizon", ""
-   "[openstack_image]", "Glance", ""
-   "[openstack_compute_controller]", "Nova", ""
-   "[openstack_compute]", "Nova", "Accepts multiple entries to have multiple compute nodes. You can add more entries and re-run the installer to add them to your environment."
-   "[openstack_networking]", "Neutron", ""
-   "[openstack_orchestration]", "Heat", ""
-   "[openstack_object_storage_controller]", "Swift", "The Swift storage controller. It runs the swift proxy server and the memcache server"
-   "[openstack_object_storage]", "Swift", "The Swift Storage nodes. Accepts multiple entries to have multiple storage nodes"
-
-
-Important notes
----------------
-
-* To omit any role, do not add an entry under its group section.
-
-* To create an ``All In One`` scenario, specify the same machine name or IPv4
-  Address under all of the groups.
-
-For further reference, check out the `Ansible`_ documentation.
-
-
-**Back to Configuration Section** :ref:`configure_openstack_environment`
-
-.. _Ansible: http://docs.ansible.com/ansible/intro_inventory.html
+.. _openstack_env_inventory_file:
+
+The "hosts" file
+################
+
+The :file:`hosts` file is an inventory file where you specify, via
+``ini`` format, the roles your machine plays.
+
+The :file:`hosts` file can be structured with different groups, where each
+group plays a specific role in your environment and network mapping.
+
+Consider the following example::
+
+    [openstack_identity]
+    192.168.50.13
+
+Here, the role ``[openstack_identity]`` syntax defines the group, and
+``192.168.50.13`` specifies the machine(s) that possess that role. You
+may define multiple machines in the same group; this is a standard
+configuration for role ``[openstack_compute]`` nodes::
+
+    [openstack_compute]
+    192.168.50.16
+    192.168.50.17
+
+
+Inventory file groups
+---------------------
+
+Below you will find the description of each group in the `hosts` file.
+
+.. csv-table:: "Inventory File Groups"
+   :header: "Group", "Components", "Comments"
+   :widths: 40, 40, 300
+
+   "[dbservers]", "MariaDB", ""
+   "[messaging_servers]", "RabbitMQ", ""
+   "[openstack_identity]", "Keystone, Horizon", ""
+   "[openstack_image]", "Glance", ""
+   "[openstack_compute_controller]", "Nova", ""
+   "[openstack_compute]", "Nova", "Accepts multiple entries to have multiple compute nodes. You can add more entries and re-run the installer to add them to your environment."
+   "[openstack_networking]", "Neutron", ""
+   "[openstack_orchestration]", "Heat", ""
+   "[openstack_object_storage_controller]", "Swift", "The Swift storage controller. It runs the swift proxy server and the memcache server"
+   "[openstack_object_storage]", "Swift", "The Swift Storage nodes. Accepts multiple entries to have multiple storage nodes"
+
+
+Important notes
+---------------
+
+* To omit any role, do not add an entry under its group section.
+
+* To create an ``All In One`` scenario, specify the same machine name or IPv4
+  Address under all of the groups.
+
+For further reference, check out the `Ansible`_ documentation.
+
+
+**Back to Configuration Section** :ref:`configure_openstack_environment`
+
+.. _Ansible: http://docs.ansible.com/ansible/intro_inventory.html

source/openstack/index.rst

@@ -0,0 +1,17 @@
+OpenStack* implementation
+#########################
+
+.. toctree::
+   :maxdepth: 1
+
+   use-cases
+   summary
+   installation
+   configuration
+   env-inventory
+   about-conf-variables
+   conf-variables
+   swift-deployment
+   telemetry/image
+   telemetry/compute
+   telemetry/verify

source/openstack/installation.rst

@@ -1,78 +1,78 @@
-.. _installing_openstack:
-
-Installing OpenStack*
-#####################
-
-This section details an OpenStack installation that uses
-bundles available for Clear Linux* OS for Intel® Architecture.
-
-The sample configuration files that are included will likely
-require modification for your specific environment.
-
-This Clear Config Management uses Ansible* as configuration management tool.
-
-
-Components supported by Clear Config Management
-===============================================
-
-At the moment, this installer can deploy any or all of the following
-components:
-
- - MariaDB
- - RabbitMQ
- - Keystone
- - Glance
- - Nova
- - Neutron
- - Dashboard (In identity node)
- - Heat
- - Swift
-
-Note:
------
-
-Below you will find the reference to componets supported on Clear Linux OS for Intel Architecture, but
-its support in Clear Config Management is still pending development:
-
-.. csv-table:: "Supported Components on ClearLinux*, but unsupported by Clear Config Management"
-   :header: "Component", "Bundles", "OpenStack* official documentation"
-   :widths: 20, 70, 100
-
-   "Cinder", "openstack-block-storage and openstack-block-storage-controller", "http://docs.openstack.org/developer/cinder/"
-   "Ceilometer", "openstack-telemetry", "http://docs.openstack.org/developer/ceilometer/"
-
-
-Prerequisites
-=============
-
-Before the installer can set up your cloud environment, these prerequisites
-should be completed (if they aren't already):
-
-#. Create a pair of SSH keys.
-
-#. Copy your public key to each node.
-
-#. Create the :file:`sshd_config` in ``/etc/ssh`` if it doesn't exist::
-
-    # mkdir -p /etc/ssh && touch /etc/ssh/sshd_config
-
-#. Allow ssh root access by adding "PermitRootLogin yes" to the ssh
-   configuration.::
-
-    # echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
-
-
-Using the Installer
-===================
-
-This step presumes a machine running Clear Linux OS for Intel Architecture as the ansible host.
-
-
-Install the bundle
-------------------
-
-#. Install the `sysadmin-hostmgmt` bundle::
-
-     # swupd bundle-add sysadmin-hostmgmt
-
-**Next**:  :ref:`configure_openstack_environment`
+.. _installing_openstack:
+
+Installing OpenStack*
+#####################
+
+This section details an OpenStack installation that uses
+bundles available for Clear Linux* OS for Intel® Architecture.
+
+The sample configuration files that are included will likely
+require modification for your specific environment.
+
+This Clear Config Management uses Ansible* as configuration management tool.
+
+
+Components supported by Clear Config Management
+===============================================
+
+At the moment, this installer can deploy any or all of the following
+components:
+
+ - MariaDB
+ - RabbitMQ
+ - Keystone
+ - Glance
+ - Nova
+ - Neutron
+ - Dashboard (In identity node)
+ - Heat
+ - Swift
+
+Note:
+-----
+
+Below you will find the reference to componets supported on Clear Linux OS for Intel Architecture, but
+its support in Clear Config Management is still pending development:
+
+.. csv-table:: "Supported Components on ClearLinux*, but unsupported by Clear Config Management"
+   :header: "Component", "Bundles", "OpenStack* official documentation"
+   :widths: 20, 70, 100
+
+   "Cinder", "openstack-block-storage and openstack-block-storage-controller", "http://docs.openstack.org/developer/cinder/"
+   "Ceilometer", "openstack-telemetry", "http://docs.openstack.org/developer/ceilometer/"
+
+
+Prerequisites
+=============
+
+Before the installer can set up your cloud environment, these prerequisites
+should be completed (if they aren't already):
+
+#. Create a pair of SSH keys.
+
+#. Copy your public key to each node.
+
+#. Create the :file:`sshd_config` in ``/etc/ssh`` if it doesn't exist::
+
+    # mkdir -p /etc/ssh && touch /etc/ssh/sshd_config
+
+#. Allow ssh root access by adding "PermitRootLogin yes" to the ssh
+   configuration.::
+
+    # echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
+
+
+Using the Installer
+===================
+
+This step presumes a machine running Clear Linux OS for Intel Architecture as the ansible host.
+
+
+Install the bundle
+------------------
+
+#. Install the `sysadmin-hostmgmt` bundle::
+
+     # swupd bundle-add sysadmin-hostmgmt
+
+**Next**:  :ref:`configure_openstack_environment`

source/openstack/summary.rst

@@ -1,65 +1,65 @@
-.. _openstack_bundle_and_service_summary:
-
-OpenStack* bundle and service summary
-#####################################
-
-OpenStack provides an Infrastructure-as-a-Service (IaaS) solution
-through a variety of complementary services. Each service offers an
-application programming interface (API) that facilitates this
-integration. The following table provides a list of OpenStack services:
-
-.. csv-table:: OpenStack services
-   :header: "Bundle Name (service)", "Project Name", "Description"
-   :widths: 90, 90, 300
-
-   "openstack-compute-controller", "Nova", "Manages the lifecycle of
-   compute instances in an OpenStack environment. Responsibilities include
-   spawning, scheduling and decommissioning of virtual machines on demand."
-   "openstack-identity", "Keystone", "Provides an authentication and
-   authorization service for other OpenStack services. Provides a catalog
-   of endpoints for all OpenStack services."
-   "openstack-image", "Glance", "Stores and retrieves virtual machine disk
-   images. OpenStack Compute makes use of this during instance provisioning."
-   "openstack-dashboard", "Horizon", "Provides a web-based self-service portal
-   to interact with underlying OpenStack services."
-   "openstack-network", "Neutron", "Enables Network-Connectivity-as-a-Service
-   for some OpenStack services. Besides, it provides an API for users to define
-   networks and the attachments into them."
-   "openstack-object-storage", "Swift", "Stores and retrieves arbitrary
-   unstructured data objects. It is highly fault tolerant with its data
-   replication and scale-out architecture."
-   "openstack-block-storage/openstack-block-storage-controller", "Cinder", "Provides
-   persistent block storage to running instances."
-   "openstack-telemetry", "Ceilometer", "Monitors and meters the
-   OpenStack cloud for billing, benchmarking, scalability, and statistical
-   purposes."
-   "openstack-orchestration", "Heat", "Orchestrates multiple composite cloud
-   applications by using either the native Heat Orchestration Template (HOT)
-   template format or the AWS CloudFormation template format."
-
-OpenStack is highly configurable to meet different needs. This guide
-uses a two-node architecture.
-
--  The controller node runs the Identity Service, Image Service, the
-   management portion of Compute, and the Dashboard. It also includes
-   supporting services, such as an SQL database and message queue.
-   Optionally, the controller node runs management portions of Block
-   Storage services.
--  The compute node runs the hypervisor portion of Compute that operates
-   project virtual machines or instances. By default, Compute uses KVM
-   as the hypervisor. Compute also provisions project networks and
-   provides firewalling (security groups) services. You can run more
-   than one compute node.
--  (Optional) Block Storage node contains the disks that the Block
-   Storage service provisions for instances. You can deploy more than
-   one block storage node.
--  (Optional) Object Storage node contain the disks that the Object
-   Storage service uses for storing accounts, containers, and objects.
-   This service requires two nodes. Each node requires a minimum of one
-   network interface. You can deploy more than two object storage nodes.
--  The self-service networks option augments the provider networks option
-   with layer-3 (routing) services that enable self-service networks
-   using overlay segmentation methods. Additionally, this option provides
-   the foundation for advanced services such as LBaaS and FWaaS.
-
-Next topic: :ref:`installing_openstack`.
+.. _openstack_bundle_and_service_summary:
+
+OpenStack* bundle and service summary
+#####################################
+
+OpenStack provides an Infrastructure-as-a-Service (IaaS) solution
+through a variety of complementary services. Each service offers an
+application programming interface (API) that facilitates this
+integration. The following table provides a list of OpenStack services:
+
+.. csv-table:: OpenStack services
+   :header: "Bundle Name (service)", "Project Name", "Description"
+   :widths: 90, 90, 300
+
+   "openstack-compute-controller", "Nova", "Manages the lifecycle of
+   compute instances in an OpenStack environment. Responsibilities include
+   spawning, scheduling and decommissioning of virtual machines on demand."
+   "openstack-identity", "Keystone", "Provides an authentication and
+   authorization service for other OpenStack services. Provides a catalog
+   of endpoints for all OpenStack services."
+   "openstack-image", "Glance", "Stores and retrieves virtual machine disk
+   images. OpenStack Compute makes use of this during instance provisioning."
+   "openstack-dashboard", "Horizon", "Provides a web-based self-service portal
+   to interact with underlying OpenStack services."
+   "openstack-network", "Neutron", "Enables Network-Connectivity-as-a-Service
+   for some OpenStack services. Besides, it provides an API for users to define
+   networks and the attachments into them."
+   "openstack-object-storage", "Swift", "Stores and retrieves arbitrary
+   unstructured data objects. It is highly fault tolerant with its data
+   replication and scale-out architecture."
+   "openstack-block-storage/openstack-block-storage-controller", "Cinder", "Provides
+   persistent block storage to running instances."
+   "openstack-telemetry", "Ceilometer", "Monitors and meters the
+   OpenStack cloud for billing, benchmarking, scalability, and statistical
+   purposes."
+   "openstack-orchestration", "Heat", "Orchestrates multiple composite cloud
+   applications by using either the native Heat Orchestration Template (HOT)
+   template format or the AWS CloudFormation template format."
+
+OpenStack is highly configurable to meet different needs. This guide
+uses a two-node architecture.
+
+-  The controller node runs the Identity Service, Image Service, the
+   management portion of Compute, and the Dashboard. It also includes
+   supporting services, such as an SQL database and message queue.
+   Optionally, the controller node runs management portions of Block
+   Storage services.
+-  The compute node runs the hypervisor portion of Compute that operates
+   project virtual machines or instances. By default, Compute uses KVM
+   as the hypervisor. Compute also provisions project networks and
+   provides firewalling (security groups) services. You can run more
+   than one compute node.
+-  (Optional) Block Storage node contains the disks that the Block
+   Storage service provisions for instances. You can deploy more than
+   one block storage node.
+-  (Optional) Object Storage node contain the disks that the Object
+   Storage service uses for storing accounts, containers, and objects.
+   This service requires two nodes. Each node requires a minimum of one
+   network interface. You can deploy more than two object storage nodes.
+-  The self-service networks option augments the provider networks option
+   with layer-3 (routing) services that enable self-service networks
+   using overlay segmentation methods. Additionally, this option provides
+   the foundation for advanced services such as LBaaS and FWaaS.
+
+Next topic: :ref:`installing_openstack`.

source/openstack/swift-deployment.rst

@@ -1,69 +1,69 @@
-.. _openstack_swift_deployment_scenarios:
-
-OpenStack* Swift* Deployment Scenarios
-######################################
-
-You can install OpenStack Swift using clear-config-management through two
-possible scenarios.
-
-- **Scenario #1:** All the storage nodes are identical, with the same number of storage devices with the same names.
-
-- **Scenario #2:** The storage setup is heterogeneous. The list of storage devices must be provided for each storage node individually.
-
-
-Scenario #1: Identical storage nodes scenario
-=============================================
-
-To set up this scenario, the ``swift_storage_devices`` variable needs to be
-defined in ``../group_vars/all`` as follows:
-
-.. code-block:: yaml
-
-   ...
-   swift_storage_device_path: /dev/
-   swift_storage_devices:
-     - sda
-     - sdb
-     ...
-
-Scenario #2: Different storage nodes scenario
-=============================================
-
-With this setup, specific information about each storage node has to be provided.
-
-First, in the root of your Ansible* directory setup, create a new directory called ``host_vars``.
-Inside ``host_vars``, for each storage node, create a new file with the name of the
-storage node's hostname or IP. In each file, provide the list of the storage
-devices.
-
-The Ansible directory setup should look similar to the following directory tree:
-
-.. code-block:: console
-
-   openstack/
-   ├── group_vars
-   │   └── all
-   ├── hosts
-   ├── host_vars
-   │   ├── storage-one
-   │   └── storage-two
-   ├── openstack_deployment.yml
-   └── README.md
-
-And the ``storage-one`` and ``storage-two`` storage node files should look similar to this:
-
-.. code-block:: yaml
-
-   ---
-   devices:
-     - sdb
-     - sdc
-     - sdd
-
-
-.. code-block:: yaml
-
-   ---
-   devices:
-     - vdb
-     - vdc
+.. _openstack_swift_deployment_scenarios:
+
+OpenStack* Swift* Deployment Scenarios
+######################################
+
+You can install OpenStack Swift using clear-config-management through two
+possible scenarios.
+
+- **Scenario #1:** All the storage nodes are identical, with the same number of storage devices with the same names.
+
+- **Scenario #2:** The storage setup is heterogeneous. The list of storage devices must be provided for each storage node individually.
+
+
+Scenario #1: Identical storage nodes scenario
+=============================================
+
+To set up this scenario, the ``swift_storage_devices`` variable needs to be
+defined in ``../group_vars/all`` as follows:
+
+.. code-block:: yaml
+
+   ...
+   swift_storage_device_path: /dev/
+   swift_storage_devices:
+     - sda
+     - sdb
+     ...
+
+Scenario #2: Different storage nodes scenario
+=============================================
+
+With this setup, specific information about each storage node has to be provided.
+
+First, in the root of your Ansible* directory setup, create a new directory called ``host_vars``.
+Inside ``host_vars``, for each storage node, create a new file with the name of the
+storage node's hostname or IP. In each file, provide the list of the storage
+devices.
+
+The Ansible directory setup should look similar to the following directory tree:
+
+.. code-block:: console
+
+   openstack/
+   ├── group_vars
+   │   └── all
+   ├── hosts
+   ├── host_vars
+   │   ├── storage-one
+   │   └── storage-two
+   ├── openstack_deployment.yml
+   └── README.md
+
+And the ``storage-one`` and ``storage-two`` storage node files should look similar to this:
+
+.. code-block:: yaml
+
+   ---
+   devices:
+     - sdb
+     - sdc
+     - sdd
+
+
+.. code-block:: yaml
+
+   ---
+   devices:
+     - vdb
+     - vdc

source/openstack/telemetry/compute.rst

@@ -1,82 +1,82 @@
-OpenStack* Telemetry - Enable compute service meters
-############################################################
-
-Telemetry uses a combination of notifications and an agent to
-collect Compute meters. Perform these steps on each compute node.
-
-Configure components
------------------------------------------------
-
-Edit the ``/etc/ceilometer/ceilometer.conf`` file and complete the following actions:
-
-#. In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections, configure RabbitMQ message queue access::
-
-    [DEFAULT]
-    ...
-    rpc_backend = rabbit
-
-    [oslo_messaging_rabbit]
-    ...
-    rabbit_host = controller
-    rabbit_userid = openstack
-    rabbit_password = RABBIT_PASS
-
-   Replace the ``RABBIT_PASS`` with the password you chose for the openstack account in RabbitMQ.
-
-#. In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections, configure Identity service access::
-
-    [DEFAULT]
-    ...
-    auth_strategy = keystone
-
-    [keystone_authtoken]
-    ...
-    auth_uri = http://controller:5000
-    auth_url = http://controller:35357
-    auth_plugin = password
-    project_domain_id = default
-    user_domain_id = default
-    project_name = service
-    username = ceilometer
-    password = CEILOMETER_PASS
-
-   Replace ``CEILOMETER_PASS`` with the password you chose for the Telemetry service database.
-
-#. In the ``[service_credentials]`` section, configure service credentials::
-
-    [service_credentials]
-    ...
-    os_auth_url = http://controller:5000/v2.0
-    os_username = ceilometer
-    os_tenant_name = service
-    os_password = CEILOMETER_PASS
-    os_endpoint_type = internalURL
-    os_region_name = RegionOne
-
-   Replace ``CEILOMETER_PASS`` with the password you chose for the ceilometer user in the Identity service.
-
-
-Configure Compute to use Telemetry
------------------------------------------------
-
-#. Edit the ``/etc/nova/nova.conf`` file and configure notifications in the ``[DEFAULT]`` section::
-
-    [DEFAULT]
-    ...
-    instance_usage_audit = True
-    instance_usage_audit_period = hour
-    notify_on_state_change = vm_and_task_state
-    notification_driver = messagingv2
-
-
-Finalize the installation
------------------------------------------------
-
-#. Restart the agent::
-
-    # systemctl enable ceilometer-agent-compute.service
-    # systemctl restart ceilometer-agent-compute.service
-
-#. Restart the compute service::
-
-   	# systemctl restart nova-compute.service
+OpenStack* Telemetry - Enable compute service meters
+############################################################
+
+Telemetry uses a combination of notifications and an agent to
+collect Compute meters. Perform these steps on each compute node.
+
+Configure components
+-----------------------------------------------
+
+Edit the ``/etc/ceilometer/ceilometer.conf`` file and complete the following actions:
+
+#. In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections, configure RabbitMQ message queue access::
+
+    [DEFAULT]
+    ...
+    rpc_backend = rabbit
+
+    [oslo_messaging_rabbit]
+    ...
+    rabbit_host = controller
+    rabbit_userid = openstack
+    rabbit_password = RABBIT_PASS
+
+   Replace the ``RABBIT_PASS`` with the password you chose for the openstack account in RabbitMQ.
+
+#. In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections, configure Identity service access::
+
+    [DEFAULT]
+    ...
+    auth_strategy = keystone
+
+    [keystone_authtoken]
+    ...
+    auth_uri = http://controller:5000
+    auth_url = http://controller:35357
+    auth_plugin = password
+    project_domain_id = default
+    user_domain_id = default
+    project_name = service
+    username = ceilometer
+    password = CEILOMETER_PASS
+
+   Replace ``CEILOMETER_PASS`` with the password you chose for the Telemetry service database.
+
+#. In the ``[service_credentials]`` section, configure service credentials::
+
+    [service_credentials]
+    ...
+    os_auth_url = http://controller:5000/v2.0
+    os_username = ceilometer
+    os_tenant_name = service
+    os_password = CEILOMETER_PASS
+    os_endpoint_type = internalURL
+    os_region_name = RegionOne
+
+   Replace ``CEILOMETER_PASS`` with the password you chose for the ceilometer user in the Identity service.
+
+
+Configure Compute to use Telemetry
+-----------------------------------------------
+
+#. Edit the ``/etc/nova/nova.conf`` file and configure notifications in the ``[DEFAULT]`` section::
+
+    [DEFAULT]
+    ...
+    instance_usage_audit = True
+    instance_usage_audit_period = hour
+    notify_on_state_change = vm_and_task_state
+    notification_driver = messagingv2
+
+
+Finalize the installation
+-----------------------------------------------
+
+#. Restart the agent::
+
+    # systemctl enable ceilometer-agent-compute.service
+    # systemctl restart ceilometer-agent-compute.service
+
+#. Restart the compute service::
+
+   	# systemctl restart nova-compute.service

source/openstack/telemetry/image.rst

@@ -1,35 +1,35 @@
-OpenStack* Telemetry - Enable image service meters
-############################################################
-
-Telemetry uses notifications to collect Image service meters.
-Perform these steps on the controller node.
-
-
-Configure the Image service to use Telemetry
------------------------------------------------
-
-Edit the ``/etc/glance/glance-api.conf`` and ``/etc/glance/glance-registry.conf``
-files and complete the following actions:
-
-#. In the ``[DEFAULT]`` section, configure notifications and RabbitMQ message broker access::
-
-    [DEFAULT]
-    ...
-    notification_driver = messagingv2
-    rpc_backend = rabbit
-
-    [oslo_messaging_rabbit]
-    ...
-    rabbit_host = controller
-    rabbit_userid = openstack
-    rabbit_password = RABBIT_PASS
-
-   Replace the ``RABBIT_PASS`` with the password you chose for the openstack account in RabbitMQ.
-
-Finalize the installation
-----------------------------
-
-#. Restart the image service::
-
-   	# systemctl restart glance-registry.service
-   	# systemctl restart glance-api.service
+OpenStack* Telemetry - Enable image service meters
+############################################################
+
+Telemetry uses notifications to collect Image service meters.
+Perform these steps on the controller node.
+
+
+Configure the Image service to use Telemetry
+-----------------------------------------------
+
+Edit the ``/etc/glance/glance-api.conf`` and ``/etc/glance/glance-registry.conf``
+files and complete the following actions:
+
+#. In the ``[DEFAULT]`` section, configure notifications and RabbitMQ message broker access::
+
+    [DEFAULT]
+    ...
+    notification_driver = messagingv2
+    rpc_backend = rabbit
+
+    [oslo_messaging_rabbit]
+    ...
+    rabbit_host = controller
+    rabbit_userid = openstack
+    rabbit_password = RABBIT_PASS
+
+   Replace the ``RABBIT_PASS`` with the password you chose for the openstack account in RabbitMQ.
+
+Finalize the installation
+----------------------------
+
+#. Restart the image service::
+
+   	# systemctl restart glance-registry.service
+   	# systemctl restart glance-api.service

source/openstack/telemetry/verify.rst

@@ -1,59 +1,59 @@
-OpenStack* Telemetry - Verify Operation
-############################################################
-
-Verify Operation
-------------------
-
-Verify operation of the Telemetry service. These steps only include the Image service meters to reduce clutter. Environments with ceilometer integration for additional services contain more meters.
-
-
-#. Source the ``admin`` credentials to gain access to admin-only CLI
-   commands::
-
-   	$ source admin-openrc.sh
-
-#. List available meters::
-
-    $ ceilometer meter-list
-    +--------------+-------+-------+--------------------------------------+---------+------------+
-    | Name         | Type  | Unit  | Resource ID                          | User ID | Project ID |
-    +--------------+-------+-------+--------------------------------------+---------+------------+
-    | image        | gauge | image | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
-    | image.size   | gauge | B     | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
-    +--------------+-------+-------+--------------------------------------+---------+------------+
-
-#. Download the CirrOS image from the Image service::
-
-    $ IMAGE_ID=$(glance image-list | grep 'cirros' | awk '{ print $2 }')
-    $ glance image-download $IMAGE_ID > /tmp/cirros.img
-
-#. List available meters again to validate detection of the image download::
-
-    $ ceilometer meter-list
-    +----------------+-------+-------+--------------------------------------+---------+------------+
-    | Name           | Type  | Unit  | Resource ID                          | User ID | Project ID |
-    +----------------+-------+-------+--------------------------------------+---------+------------+
-    | image          | gauge | image | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
-    | image.download | delta | B     | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
-    | image.serve    | delta | B     | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
-    | image.size     | gauge | B     | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
-    +----------------+-------+-------+--------------------------------------+---------+------------+
-
-#. Retrieve usage statistics from the image.download meter::
-
-    $ ceilometer statistics -m image.download -p 60
-
-    +--------+---------------------+---------------------+------------+------------+------------+------------+-------+----------+----------------------------+----------------------------+
-    | Period | Period Start        | Period End          | Max        | Min        | Avg        | Sum        | Count | Duration | Duration Start             | Duration End               |
-    +--------+---------------------+---------------------+------------+------------+------------+------------+-------+----------+----------------------------+----------------------------+
-    | 60     | 2015-04-21T12:21:45 | 2015-04-21T12:22:45 | 13200896.0 | 13200896.0 | 13200896.0 | 13200896.0 | 1     | 0.0      | 2015-04-21T12:22:12.983000 | 2015-04-21T12:22:12.983000 |
-    +--------+---------------------+---------------------+------------+------------+------------+------------+-------+----------+----------------------------+----------------------------+
-
-#. Remove the previously downloaded image file /tmp/cirros.img::
-
-    $ rm /tmp/cirros.img
-
-
-
-
-
+OpenStack* Telemetry - Verify Operation
+############################################################
+
+Verify Operation
+------------------
+
+Verify operation of the Telemetry service. These steps only include the Image service meters to reduce clutter. Environments with ceilometer integration for additional services contain more meters.
+
+
+#. Source the ``admin`` credentials to gain access to admin-only CLI
+   commands::
+
+   	$ source admin-openrc.sh
+
+#. List available meters::
+
+    $ ceilometer meter-list
+    +--------------+-------+-------+--------------------------------------+---------+------------+
+    | Name         | Type  | Unit  | Resource ID                          | User ID | Project ID |
+    +--------------+-------+-------+--------------------------------------+---------+------------+
+    | image        | gauge | image | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
+    | image.size   | gauge | B     | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
+    +--------------+-------+-------+--------------------------------------+---------+------------+
+
+#. Download the CirrOS image from the Image service::
+
+    $ IMAGE_ID=$(glance image-list | grep 'cirros' | awk '{ print $2 }')
+    $ glance image-download $IMAGE_ID > /tmp/cirros.img
+
+#. List available meters again to validate detection of the image download::
+
+    $ ceilometer meter-list
+    +----------------+-------+-------+--------------------------------------+---------+------------+
+    | Name           | Type  | Unit  | Resource ID                          | User ID | Project ID |
+    +----------------+-------+-------+--------------------------------------+---------+------------+
+    | image          | gauge | image | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
+    | image.download | delta | B     | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
+    | image.serve    | delta | B     | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
+    | image.size     | gauge | B     | acafc7c0-40aa-4026-9673-b879898e1fc2 | None    | cf12a15... |
+    +----------------+-------+-------+--------------------------------------+---------+------------+
+
+#. Retrieve usage statistics from the image.download meter::
+
+    $ ceilometer statistics -m image.download -p 60
+
+    +--------+---------------------+---------------------+------------+------------+------------+------------+-------+----------+----------------------------+----------------------------+
+    | Period | Period Start        | Period End          | Max        | Min        | Avg        | Sum        | Count | Duration | Duration Start             | Duration End               |
+    +--------+---------------------+---------------------+------------+------------+------------+------------+-------+----------+----------------------------+----------------------------+
+    | 60     | 2015-04-21T12:21:45 | 2015-04-21T12:22:45 | 13200896.0 | 13200896.0 | 13200896.0 | 13200896.0 | 1     | 0.0      | 2015-04-21T12:22:12.983000 | 2015-04-21T12:22:12.983000 |
+    +--------+---------------------+---------------------+------------+------------+------------+------------+-------+----------+----------------------------+----------------------------+
+
+#. Remove the previously downloaded image file /tmp/cirros.img::
+
+    $ rm /tmp/cirros.img
+
+
+
+
+

source/storage/ceph-deploy.rst

@@ -1,210 +1,210 @@
-.. _ceph-deploy:
-
-Ceph*
-#####
-
-Ceph is a distributed storage system designed to scale well. It can be
-integrated with OpenStack* as the storage backend for the OS images and
-volumes.
-
-Deploying a Ceph storage cluster is simple using Clear Linux* OS for
-Intel® Architecture and Ansible*.
-
-
-Environment
-===========
-
-For this example, we'll use a total of six nodes: a **deployment node**,
-to run the playbooks, a **monitor node**, a **metadata node** and three 
-**storage nodes**.
-
-Install each component on its own server for best results; however,
-for testing purposes you can install the monitor, metadata, and storage 
-nodes all on the same host.
-
-
-Prerequisites
-=============
-
-Ansible uses ``ssh`` to run commands on the remote servers. In order to
-do that, the servers must be configured to allow passwordless ssh
-connections from the root user. Follow these steps to configure
-your nodes.
-
-On your cluster nodes
----------------------
-
-#. Enable root login::
-
-    # echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
-
-#. Enable sshd service::
-
-    # systemctl enable sshd
-    # systemctl start sshd
-
-On your deployment node
------------------------
-
-#. Generate an ssh key if you have not already::
-
-    # ssh-keygen
-
-#. Copy your public key (:file:`~/.ssh/id_rsa.pub`) to :file:`/root/.ssh/authorized_keys` on each node::
-
-    # ssh-copy-id root@node
-
-
-Install the software
-====================
-
-Install the `sysadmin-hostmgmt`_ bundle on the deployment node. This
-bundle contains the Ansible software required to run the playbooks, as
-well as some Ansible roles and sample playbooks that you can use to
-build your own::
-
-    # swupd bundle-add sysadmin-hostmgmt
-
-
-Create the playbook
-===================
-
-The ``sysadmin-hostmgmt`` bundle includes some sample playbooks that
-can be customized for your own needs. Start by making a copy of the
-sample playbook into your home folder.::
-
-    # cp -r /usr/share/ansible/examples/ceph ~/
-
-The playbook consist of four files that you should modify to fit
-your needs::
-
-    ceph
-    |-- group_vars/
-    |    |-- all
-    |    +-- mons
-    |-- hosts
-    +-- ceph_deploy.yml
-
-The ``hosts`` file contains the IP addresses of your servers grouped
-under the roles they will serve::
-
-    [mons]
-    172.28.128.7
-
-    [osds]
-    172.28.128.8
-    172.28.128.9
-    172.28.128.10
-
-    [mdss]
-    172.28.128.11
-
-This :file:`groups_var/all` file contains variables that will be applied
-to all your nodes. The mandatory variables are already there; be sure
-to change the values accordingly to fit your environment. It should
-look something like this::
-
-    ---
-    journal_size: 1024
-    monitor_interface: enp0s8
-    public_network: 172.28.128.0/24
-    cluster_network: "{{ public_network }}"
-
-A full list of available variables can be found under each role 
-in ``defaults/main.yml``::
-
-   * `ceph-common/defaults/main.yml`_
-   * `ceph-mon/defaults/main.yml`_
-   * `ceph-mds/defaults/main.yml`_
-   * `ceph-osd/defaults/main.yml`_
-
-This :file:`groups_var/osd` file contains variables that apply only
-to the hosts under the ``[mons]`` section in your hosts file. You can
-choose one of the three available scenarios for this playbook.
-
-#. **Journal and osd_data on the same device**: This will co-locate both
-   journal and data on the same disk, creating a partition at the
-   beginning of the device::
-
-      journal_collocation: true
-      devices:
-        - /dev/sdb
-        - /dev/sdc
-        - /dev/sdd
-
-#. **N journal devices for N OSDs**: In this example, the ``sdb``
-   partition will be used for journaling of ``sdc``. The ``sdd sdf``
-   will be used for journaling of ``sde``::
-
-      raw_multi_journal: true
-      devices:
-        - /dev/sdc
-        - /dev/sdd
-        - /dev/sde
-      raw_journal_devices:
-        - /dev/sdb
-        - /dev/sdb
-        - /dev/sdf
-
-#. **Specify a directory instead of disk for OSDs**::
-
-      osd_directory: true
-      osd_directories:
-        - /var/lib/ceph/osd/mydir1
-        - /var/lib/ceph/osd/mydir2
-        - /var/lib/ceph/osd/mydir3
-
-  Note: The directories should reside on an XFS filesystem. EXT4 is not supported.
-
-
-Run the playbook
-================
-
-Once the variables and hosts file is configured,
-deployment is as simple as issuing the command::
-
-    # ansible-playbook -i hosts ceph_deploy.yml
-
-
-Verify
-======
-
-After Ansible has finished deployment, you may
-like to verify and watch the health of the cluster
-with Ceph utilites such as ``ceph status`` and
-``ceph osd tree``::
-
-    # ceph status
-        cluster ee1fae3b-b95b-494c-abd7-f0629d113446
-         health HEALTH_OK
-         monmap e1: 1 mons at {node2=172.28.128.5:6789/0}
-                election epoch 2, quorum 0 node2
-         osdmap e8: 3 osds: 3 up, 3 in
-                flags sortbitwise
-          pgmap v14: 64 pgs, 1 pools, 0 bytes data, 0 objects
-                7566 MB used, 49647 MB / 59896 MB avail
-                      64 active+clean
-
-::
-
-    # ceph osd tree
-    ID WEIGHT  TYPE NAME      UP/DOWN REWEIGHT PRIMARY-AFFINITY
-    -1 0.05699 root default
-    -2 0.01900     host node3
-     0 0.01900         osd.0       up  1.00000          1.00000
-    -3 0.01900     host node4
-     1 0.01900         osd.1       up  1.00000          1.00000
-    -4 0.01900     host node5
-     2 0.01900         osd.2       up  1.00000          1.00000
-
-::
-
-    # ceph fs ls
-    name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
-
-.. _ceph-common/defaults/main.yml: https://github.com/clearlinux/clear-config-management/blob/master/roles/ceph-common/defaults/main.yml
-.. _ceph-mon/defaults/main.yml: https://github.com/clearlinux/clear-config-management/blob/master/roles/ceph-mon/defaults/main.yml
-.. _ceph-mds/defaults/main.yml: https://github.com/clearlinux/clear-config-management/blob/master/roles/ceph-mds/defaults/main.yml
-.. _ceph-osd/defaults/main.yml: https://github.com/clearlinux/clear-config-management/blob/master/roles/ceph-osd/defaults/main.yml
-.. _sysadmin-hostmgmt: https://github.com/clearlinux/clr-bundles/blob/master/bundles/sysadmin-hostmgmt
-
+.. _ceph-deploy:
+
+Ceph*
+#####
+
+Ceph is a distributed storage system designed to scale well. It can be
+integrated with OpenStack* as the storage backend for the OS images and
+volumes.
+
+Deploying a Ceph storage cluster is simple using Clear Linux* OS for
+Intel® Architecture and Ansible*.
+
+
+Environment
+===========
+
+For this example, we'll use a total of six nodes: a **deployment node**,
+to run the playbooks, a **monitor node**, a **metadata node** and three 
+**storage nodes**.
+
+Install each component on its own server for best results; however,
+for testing purposes you can install the monitor, metadata, and storage 
+nodes all on the same host.
+
+
+Prerequisites
+=============
+
+Ansible uses ``ssh`` to run commands on the remote servers. In order to
+do that, the servers must be configured to allow passwordless ssh
+connections from the root user. Follow these steps to configure
+your nodes.
+
+On your cluster nodes
+---------------------
+
+#. Enable root login::
+
+    # echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
+
+#. Enable sshd service::
+
+    # systemctl enable sshd
+    # systemctl start sshd
+
+On your deployment node
+-----------------------
+
+#. Generate an ssh key if you have not already::
+
+    # ssh-keygen
+
+#. Copy your public key (:file:`~/.ssh/id_rsa.pub`) to :file:`/root/.ssh/authorized_keys` on each node::
+
+    # ssh-copy-id root@node
+
+
+Install the software
+====================
+
+Install the `sysadmin-hostmgmt`_ bundle on the deployment node. This
+bundle contains the Ansible software required to run the playbooks, as
+well as some Ansible roles and sample playbooks that you can use to
+build your own::
+
+    # swupd bundle-add sysadmin-hostmgmt
+
+
+Create the playbook
+===================
+
+The ``sysadmin-hostmgmt`` bundle includes some sample playbooks that
+can be customized for your own needs. Start by making a copy of the
+sample playbook into your home folder.::
+
+    # cp -r /usr/share/ansible/examples/ceph ~/
+
+The playbook consist of four files that you should modify to fit
+your needs::
+
+    ceph
+    |-- group_vars/
+    |    |-- all
+    |    +-- mons
+    |-- hosts
+    +-- ceph_deploy.yml
+
+The ``hosts`` file contains the IP addresses of your servers grouped
+under the roles they will serve::
+
+    [mons]
+    172.28.128.7
+
+    [osds]
+    172.28.128.8
+    172.28.128.9
+    172.28.128.10
+
+    [mdss]
+    172.28.128.11
+
+This :file:`groups_var/all` file contains variables that will be applied
+to all your nodes. The mandatory variables are already there; be sure
+to change the values accordingly to fit your environment. It should
+look something like this::
+
+    ---
+    journal_size: 1024
+    monitor_interface: enp0s8
+    public_network: 172.28.128.0/24
+    cluster_network: "{{ public_network }}"
+
+A full list of available variables can be found under each role 
+in ``defaults/main.yml``::
+
+   * `ceph-common/defaults/main.yml`_
+   * `ceph-mon/defaults/main.yml`_
+   * `ceph-mds/defaults/main.yml`_
+   * `ceph-osd/defaults/main.yml`_
+
+This :file:`groups_var/osd` file contains variables that apply only
+to the hosts under the ``[mons]`` section in your hosts file. You can
+choose one of the three available scenarios for this playbook.
+
+#. **Journal and osd_data on the same device**: This will co-locate both
+   journal and data on the same disk, creating a partition at the
+   beginning of the device::
+
+      journal_collocation: true
+      devices:
+        - /dev/sdb
+        - /dev/sdc
+        - /dev/sdd
+
+#. **N journal devices for N OSDs**: In this example, the ``sdb``
+   partition will be used for journaling of ``sdc``. The ``sdd sdf``
+   will be used for journaling of ``sde``::
+
+      raw_multi_journal: true
+      devices:
+        - /dev/sdc
+        - /dev/sdd
+        - /dev/sde
+      raw_journal_devices:
+        - /dev/sdb
+        - /dev/sdb
+        - /dev/sdf
+
+#. **Specify a directory instead of disk for OSDs**::
+
+      osd_directory: true
+      osd_directories:
+        - /var/lib/ceph/osd/mydir1
+        - /var/lib/ceph/osd/mydir2
+        - /var/lib/ceph/osd/mydir3
+
+  Note: The directories should reside on an XFS filesystem. EXT4 is not supported.
+
+
+Run the playbook
+================
+
+Once the variables and hosts file is configured,
+deployment is as simple as issuing the command::
+
+    # ansible-playbook -i hosts ceph_deploy.yml
+
+
+Verify
+======
+
+After Ansible has finished deployment, you may
+like to verify and watch the health of the cluster
+with Ceph utilites such as ``ceph status`` and
+``ceph osd tree``::
+
+    # ceph status
+        cluster ee1fae3b-b95b-494c-abd7-f0629d113446
+         health HEALTH_OK
+         monmap e1: 1 mons at {node2=172.28.128.5:6789/0}
+                election epoch 2, quorum 0 node2
+         osdmap e8: 3 osds: 3 up, 3 in
+                flags sortbitwise
+          pgmap v14: 64 pgs, 1 pools, 0 bytes data, 0 objects
+                7566 MB used, 49647 MB / 59896 MB avail
+                      64 active+clean
+
+::
+
+    # ceph osd tree
+    ID WEIGHT  TYPE NAME      UP/DOWN REWEIGHT PRIMARY-AFFINITY
+    -1 0.05699 root default
+    -2 0.01900     host node3
+     0 0.01900         osd.0       up  1.00000          1.00000
+    -3 0.01900     host node4
+     1 0.01900         osd.1       up  1.00000          1.00000
+    -4 0.01900     host node5
+     2 0.01900         osd.2       up  1.00000          1.00000
+
+::
+
+    # ceph fs ls
+    name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
+
+.. _ceph-common/defaults/main.yml: https://github.com/clearlinux/clear-config-management/blob/master/roles/ceph-common/defaults/main.yml
+.. _ceph-mon/defaults/main.yml: https://github.com/clearlinux/clear-config-management/blob/master/roles/ceph-mon/defaults/main.yml
+.. _ceph-mds/defaults/main.yml: https://github.com/clearlinux/clear-config-management/blob/master/roles/ceph-mds/defaults/main.yml
+.. _ceph-osd/defaults/main.yml: https://github.com/clearlinux/clear-config-management/blob/master/roles/ceph-osd/defaults/main.yml
+.. _sysadmin-hostmgmt: https://github.com/clearlinux/clr-bundles/blob/master/bundles/sysadmin-hostmgmt
+

source/storage/index.rst

@@ -1,7 +1,7 @@
-Storage solutions
-#################
-
-.. toctree::
-   :maxdepth: 2
-
-   ceph-deploy
+Storage solutions
+#################
+
+.. toctree::
+   :maxdepth: 2
+
+   ceph-deploy

source/substitutions.rst

@@ -1,5 +1,5 @@
-.. |codename| replace:: Zephyr Kernel
-
-.. |PM| replace:: Hirally Rodriguez Santiago
-
-.. |project| replace:: Zephyr Project
+.. |codename| replace:: Zephyr Kernel
+
+.. |PM| replace:: Hirally Rodriguez Santiago
+
+.. |project| replace:: Zephyr Project

source/update/about.rst

@@ -1,132 +1,132 @@
-About software update
-#####################
-
-The traditional way
-===================
-
-Traditional Linux-based operating systems are often a mix of several
-hundred, if not thousands, of open source projects. To make them
-manageable, most distributions use the concept of "packages" to configure
-and compile source code into binaries for installation.
-
-Many distributions then combine these compiled binaries into so-called
-packages, resolving dependencies and providing everything needed to
-install. This is the granularity at which typical distributions deploy
-their software, enabling system administrators to install and update
-each package individually or as a set, using tools such as ``yum`` and
-``apt-get``.
-
-The Clear way
-=============
-
-Clear Linux OS for Intel® Architecture does things a little differently. 
-Following here are a few notable features that distinguish it from
-standard OSes: bundles, versioning, updating, and update speed.
-
-Bundles
--------
-
-While we use the concept of packages to manage compiling source code into
-installable binaries, we do not deploy software through packages. Instead,
-we provide "bundles" which operate as a self-contained set of functionality
-for the system administrator -- functionality that gets enabled by composing
-all the required upstream open-source projects into one logical unit: a
-bundle.
-
-
-Versioning
-----------
-
-On a traditional distribution, the process of describing current software
-versioning usually involves:
-
--  Listing and keeping track of the current OS release (generally
-   uninformative about any singular packages or functionality),
-
--  Keeping track of packages and repositories being used, updating them
-   individually,
-
--  Listing and tracking every package available and installed on the
-   system, none of which are directly tied to the current OS release
-
-This can be done effectively, but given the nearly endless combinations of
-packages and versions of packages a server may have, it quickly becomes
-non-trivial to define what "version" the system is and what software it
-is running without explicitly going through each system and inspecting
-every package.
-
-With the Clear Linux OS for Intel Architecture, we need only track:
-
--  One single number
-
-A number representing the **current** release of the OS is sufficient to
-describe the versions of all the software on the OS. Each build is
-composed of a specific set of bundles made from a particular version of
-packages. This matters on a daily basis to system administrators, who
-need to determine which of their systems do not have the latest security
-fixes, or which combinations of software have been tested, and on what
-other pieces. Every release of the same number is guaranteed to contain
-the same versions of software, so there's no ambiguity between two
-systems running the same Clear Linux OS for Intel Architecture.
-
-
-Updating
---------
-
-Another notable difference between package-based distributions and Clear Linux
-is how updates are managed. On a package-based OS, system administrators update
-each individual package or piece of software to a newer (or older!) version. With
-Clear Linux OS for Intel Architecture, an update translates to an entirely new
-OS version, containing one or many updates.  It is not possible to update a
-piece of the system while remaining on the same version of Clear Linux.
-
-How is this useful? Although it seems, at first, like a huge restriction
-or limitation, this method has many non-obvious benefits. Imagine a
-cloud environment composed of numerous machines.  Here, a homogeneous set of
-software makes sense -- from the system administrator's level down to the
-user level. Homogeneous systems allow users the ability to focus on their
-contributions and/or code, rather than configuring environments or worrying
-about synchronizing versions and updates.  At the system admin level, it
-ensures security is tighter and makes it far easier to monitor and update
-patches.
-
-Clear Linux OS will automatically check for updates and apply them. This default
-can be disabled by running::
-
-    # systemctl mask swupd-update.timer
-
-And reenabled by running::
-
-    # systemctl unmask swupd-update.timer
-
-
-Update speed
-------------
-
-Software updates with Clear Linux OS for Intel Architecture are also
-efficient. Bundles simply describe a set of files, and the update
-technology updates *only* files that actually changed by using so-called
-binary-delta technology for efficiency [1]_. Operating systems that use
-packages as the unit of deployment require full package updates (thus
-hogging resources), even when one small file in that package has changed.
-
-It is quite common for a full OS update fixing a security hole to be
-only 15 kilobytes in total update size. If only several kilobytes need
-to be changed, it does not make sense to re-download and reinstall an
-entire package or suite of programs just to incorporate a minuscule (yet
-important) update. Through binary deltas, the OS is able to update only
-those bits that changed, yielding very small update content (deltas)
-that can be applied exceedingly fast.  As a result, major security patches
-and core update take merely seconds.
-
-We realize that while our definition of bundles makes sense to us, each
-data center operator may have special needs and ideas. For that reason
-we're hard at work on a "mixer" tool, which allows users of Clear Linux OS
-for Intel Architecture the ability to customize and add bundles and
-their own software while keeping the content of the operating
-system, and its updates, as the base. With this tool, system administrators
-can focus on the pieces of their OS deployment that are custom to their
-environment, while continuing to stay on a controlled update stream.
-
-.. [1] The software update technology for Clear Linux* OS for Intel Architecture
-  was first presented at the Linux Plumbers conference in 2012.
+About software update
+#####################
+
+The traditional way
+===================
+
+Traditional Linux-based operating systems are often a mix of several
+hundred, if not thousands, of open source projects. To make them
+manageable, most distributions use the concept of "packages" to configure
+and compile source code into binaries for installation.
+
+Many distributions then combine these compiled binaries into so-called
+packages, resolving dependencies and providing everything needed to
+install. This is the granularity at which typical distributions deploy
+their software, enabling system administrators to install and update
+each package individually or as a set, using tools such as ``yum`` and
+``apt-get``.
+
+The Clear way
+=============
+
+Clear Linux OS for Intel® Architecture does things a little differently. 
+Following here are a few notable features that distinguish it from
+standard OSes: bundles, versioning, updating, and update speed.
+
+Bundles
+-------
+
+While we use the concept of packages to manage compiling source code into
+installable binaries, we do not deploy software through packages. Instead,
+we provide "bundles" which operate as a self-contained set of functionality
+for the system administrator -- functionality that gets enabled by composing
+all the required upstream open-source projects into one logical unit: a
+bundle.
+
+
+Versioning
+----------
+
+On a traditional distribution, the process of describing current software
+versioning usually involves:
+
+-  Listing and keeping track of the current OS release (generally
+   uninformative about any singular packages or functionality),
+
+-  Keeping track of packages and repositories being used, updating them
+   individually,
+
+-  Listing and tracking every package available and installed on the
+   system, none of which are directly tied to the current OS release
+
+This can be done effectively, but given the nearly endless combinations of
+packages and versions of packages a server may have, it quickly becomes
+non-trivial to define what "version" the system is and what software it
+is running without explicitly going through each system and inspecting
+every package.
+
+With the Clear Linux OS for Intel Architecture, we need only track:
+
+-  One single number
+
+A number representing the **current** release of the OS is sufficient to
+describe the versions of all the software on the OS. Each build is
+composed of a specific set of bundles made from a particular version of
+packages. This matters on a daily basis to system administrators, who
+need to determine which of their systems do not have the latest security
+fixes, or which combinations of software have been tested, and on what
+other pieces. Every release of the same number is guaranteed to contain
+the same versions of software, so there's no ambiguity between two
+systems running the same Clear Linux OS for Intel Architecture.
+
+
+Updating
+--------
+
+Another notable difference between package-based distributions and Clear Linux
+is how updates are managed. On a package-based OS, system administrators update
+each individual package or piece of software to a newer (or older!) version. With
+Clear Linux OS for Intel Architecture, an update translates to an entirely new
+OS version, containing one or many updates.  It is not possible to update a
+piece of the system while remaining on the same version of Clear Linux.
+
+How is this useful? Although it seems, at first, like a huge restriction
+or limitation, this method has many non-obvious benefits. Imagine a
+cloud environment composed of numerous machines.  Here, a homogeneous set of
+software makes sense -- from the system administrator's level down to the
+user level. Homogeneous systems allow users the ability to focus on their
+contributions and/or code, rather than configuring environments or worrying
+about synchronizing versions and updates.  At the system admin level, it
+ensures security is tighter and makes it far easier to monitor and update
+patches.
+
+Clear Linux OS will automatically check for updates and apply them. This default
+can be disabled by running::
+
+    # systemctl mask swupd-update.timer
+
+And reenabled by running::
+
+    # systemctl unmask swupd-update.timer
+
+
+Update speed
+------------
+
+Software updates with Clear Linux OS for Intel Architecture are also
+efficient. Bundles simply describe a set of files, and the update
+technology updates *only* files that actually changed by using so-called
+binary-delta technology for efficiency [1]_. Operating systems that use
+packages as the unit of deployment require full package updates (thus
+hogging resources), even when one small file in that package has changed.
+
+It is quite common for a full OS update fixing a security hole to be
+only 15 kilobytes in total update size. If only several kilobytes need
+to be changed, it does not make sense to re-download and reinstall an
+entire package or suite of programs just to incorporate a minuscule (yet
+important) update. Through binary deltas, the OS is able to update only
+those bits that changed, yielding very small update content (deltas)
+that can be applied exceedingly fast.  As a result, major security patches
+and core update take merely seconds.
+
+We realize that while our definition of bundles makes sense to us, each
+data center operator may have special needs and ideas. For that reason
+we're hard at work on a "mixer" tool, which allows users of Clear Linux OS
+for Intel Architecture the ability to customize and add bundles and
+their own software while keeping the content of the operating
+system, and its updates, as the base. With this tool, system administrators
+can focus on the pieces of their OS deployment that are custom to their
+environment, while continuing to stay on a controlled update stream.
+
+.. [1] The software update technology for Clear Linux* OS for Intel Architecture
+  was first presented at the Linux Plumbers conference in 2012.

source/update/index.rst

@@ -1,8 +1,8 @@
-Software update
-###############
-
-.. toctree::
-   :maxdepth: 2
-
-   swupdate_about_sw_update
-   swupdate_how_to_run_the_updater
+Software update
+###############
+
+.. toctree::
+   :maxdepth: 2
+
+   about
+   updater

source/update/updater.rst

@@ -1,41 +1,41 @@
-How to run the updater
-######################
-
-This section describes how to manually trigger the software update code in Clear Linux* OS for Intel® Architecture.
-
-Prerequisites
-~~~~~~~~~~~~~
-
--  System is up and running a Clear Linux OS for Intel
-   Architecture official build, 300 or later.
-
--  Device is on a well-connected network.
-
--  Device is able to connect to release infrastructure. For example:
-   http://update.clearlinux.org/update/300/
-
-Running the updater
-~~~~~~~~~~~~~~~~~~~
-
-#. Open a Terminal Emulator.
-
-#. Become root and trigger an update with this command::
-
-    # swupd update
-
-#. If the updater console output indicates a kernel update occurred,
-   then at your convenience reboot to begin using the new OS version.
-
-Updater options
-~~~~~~~~~~~~~~~
-
-Help options:
-
--  ``-h, --help`` Display help options.
-
-Application options:
-
--  ``-d, --download`` Download all content, but do not actually install
-   the update.
-
--  ``-v, --verbose`` Increase verbosity of log and console messages.
+How to run the updater
+######################
+
+This section describes how to manually trigger the software update code in Clear Linux* OS for Intel® Architecture.
+
+Prerequisites
+~~~~~~~~~~~~~
+
+-  System is up and running a Clear Linux OS for Intel
+   Architecture official build, 300 or later.
+
+-  Device is on a well-connected network.
+
+-  Device is able to connect to release infrastructure. For example:
+   http://update.clearlinux.org/update/300/
+
+Running the updater
+~~~~~~~~~~~~~~~~~~~
+
+#. Open a Terminal Emulator.
+
+#. Become root and trigger an update with this command::
+
+    # swupd update
+
+#. If the updater console output indicates a kernel update occurred,
+   then at your convenience reboot to begin using the new OS version.
+
+Updater options
+~~~~~~~~~~~~~~~
+
+Help options:
+
+-  ``-h, --help`` Display help options.
+
+Application options:
+
+-  ``-d, --download`` Download all content, but do not actually install
+   the update.
+
+-  ``-v, --verbose`` Increase verbosity of log and console messages.

source/vm/hyper-v.rst

@@ -1,75 +1,75 @@
-.. _vm-hyper-v:
-
-Using Hyper-V
-#############
-
-This section explains how to run Clear Linux OS for Intel® Architecture
-inside a `Windows Server Virtualization`_  *A.K.A.* **Hyper-V** environment.
-
-
-Install Hyper-V*
-================
-
-Please refer to `Microsoft documentation`_ to install and configure
-*Hyper-V* on your machine.
-
-
-Create a virtual machine
-========================
-
-#. Download the `latest`_ live version (clear-XXXX-live.img.xz) of Clear Linux OS
-   for Intel Architecture.
-
-#. Decompress the downloaded image. Uncompressed image size is ~ **5GB**.
-
-#. To convert a raw image to :abbr:`VHD (Virtual Hard Disk)`
-   format, you can use VirtualBox_ or QEMU_.
-
-   *  With *VirtualBox*, you can use one of the following commands::
-
-         > VBoxManage convertfromraw clear-XXXX-live.img clear-XXXX-live.vhd --format VHD
-
-      or::
-
-         > vbox-img convert --srcfilename clear-XXXX-live.img --dstfilename clear-XXXX-live.vhd --srcformat raw --dstformat vhd
-
-   *  With *QEMU*, you can use the following command::
-
-         > qemu-img convert -f raw -O vpc clear-XXXX-live.img clear-XXXX-live.vhd
-
-   You can test your new *VHD image* using the **PowerShell** command line::
-
-         PS C:\> Test-VHD -Path c:\path\to\clear-XXXX-live.vhd
-
-   Clear Linux OS for Intel Architecture uses *EFI* to boot.  Since this feature
-   is availible only in `Generation 2`_ or later virtual machines, you'll need
-   to convert from **VHD** to **VHDX**. To do this, you can use the following
-   *PowerShell* command::
-
-         PS C:\> Convert-VHD -Path c:\path\to\clear-XXXX-live.vhd -DestinationPath c:\path\to\clear-XXXX-live.vhdx
-
-   You can save the new *VHDX* virtual hard disk in :file:`C:\\Users\\Public\\Documents\\Hyper-V\\Virtual Hard Disks`.
-
-#. Create a virtual machine using the **Hyper-V Manager**:
-
-   * Choose **Generation 2** when you need to *specify VM generation*.
-   * Choose **Use an existing virtual hard disk** and browse to find the :file:`clear-XXXX-live.vhdx` file.
-   * When finised, open VM settings, select Firmware Section and in Secure Boot
-     config, **uncheck** Enable Secure Boot.
-
-     +  Currently Clear Linux does not boot with secure boot enabled.
-
-#. Finally, connect to your new VM and start it. You should see a prompt asking for
-   a user; use::
-
-      > User: root
-
-   and set a root user password.
-
-.. _Windows Server Virtualization: https://www.microsoft.com/en-us/server-cloud/solutions/virtualization.aspx
-.. _Microsoft documentation: https://www.microsoft.com/en-us/server-cloud/solutions/virtualization.aspx
-.. _latest: https://download.clearlinux.org/image/
-.. _7zip: http://www.7-zip.org/
-.. _VirtualBox: https://www.virtualbox.org/
-.. _QEMU: http://wiki.qemu.org/Links
-.. _Generation 2: https://technet.microsoft.com/en-us/library/dn282285.aspx
+.. _vm-hyper-v:
+
+Using Hyper-V
+#############
+
+This section explains how to run Clear Linux OS for Intel® Architecture
+inside a `Windows Server Virtualization`_  *A.K.A.* **Hyper-V** environment.
+
+
+Install Hyper-V*
+================
+
+Please refer to `Microsoft documentation`_ to install and configure
+*Hyper-V* on your machine.
+
+
+Create a virtual machine
+========================
+
+#. Download the `latest`_ live version (clear-XXXX-live.img.xz) of Clear Linux OS
+   for Intel Architecture.
+
+#. Decompress the downloaded image. Uncompressed image size is ~ **5GB**.
+
+#. To convert a raw image to :abbr:`VHD (Virtual Hard Disk)`
+   format, you can use VirtualBox_ or QEMU_.
+
+   *  With *VirtualBox*, you can use one of the following commands::
+
+         > VBoxManage convertfromraw clear-XXXX-live.img clear-XXXX-live.vhd --format VHD
+
+      or::
+
+         > vbox-img convert --srcfilename clear-XXXX-live.img --dstfilename clear-XXXX-live.vhd --srcformat raw --dstformat vhd
+
+   *  With *QEMU*, you can use the following command::
+
+         > qemu-img convert -f raw -O vpc clear-XXXX-live.img clear-XXXX-live.vhd
+
+   You can test your new *VHD image* using the **PowerShell** command line::
+
+         PS C:\> Test-VHD -Path c:\path\to\clear-XXXX-live.vhd
+
+   Clear Linux OS for Intel Architecture uses *EFI* to boot.  Since this feature
+   is availible only in `Generation 2`_ or later virtual machines, you'll need
+   to convert from **VHD** to **VHDX**. To do this, you can use the following
+   *PowerShell* command::
+
+         PS C:\> Convert-VHD -Path c:\path\to\clear-XXXX-live.vhd -DestinationPath c:\path\to\clear-XXXX-live.vhdx
+
+   You can save the new *VHDX* virtual hard disk in :file:`C:\\Users\\Public\\Documents\\Hyper-V\\Virtual Hard Disks`.
+
+#. Create a virtual machine using the **Hyper-V Manager**:
+
+   * Choose **Generation 2** when you need to *specify VM generation*.
+   * Choose **Use an existing virtual hard disk** and browse to find the :file:`clear-XXXX-live.vhdx` file.
+   * When finised, open VM settings, select Firmware Section and in Secure Boot
+     config, **uncheck** Enable Secure Boot.
+
+     +  Currently Clear Linux does not boot with secure boot enabled.
+
+#. Finally, connect to your new VM and start it. You should see a prompt asking for
+   a user; use::
+
+      > User: root
+
+   and set a root user password.
+
+.. _Windows Server Virtualization: https://www.microsoft.com/en-us/server-cloud/solutions/virtualization.aspx
+.. _Microsoft documentation: https://www.microsoft.com/en-us/server-cloud/solutions/virtualization.aspx
+.. _latest: https://download.clearlinux.org/image/
+.. _7zip: http://www.7-zip.org/
+.. _VirtualBox: https://www.virtualbox.org/
+.. _QEMU: http://wiki.qemu.org/Links
+.. _Generation 2: https://technet.microsoft.com/en-us/library/dn282285.aspx

source/vm/index.rst

@@ -1,12 +1,12 @@
-Running in a virtualized environment
-####################################
-
-.. toctree::
-   :maxdepth: 2
-
-   vm-kvm
-   vm-virtualbox
-   vm-vmware-esxi
-   vm-vmware-player
-   vm-hyper-v
-
+Running in a virtualized environment
+####################################
+
+.. toctree::
+   :maxdepth: 2
+
+   kvm
+   virtualbox
+   vmware/esxi
+   vmware/player
+   hyper-v
+

source/vm/kvm.rst

@@ -1,52 +1,52 @@
-.. _vm-kvm:
-
-Using KVM
-#########
-
-The easiest way to get started in a virtualized environment is to download
-a recent KVM image from the `images`_ directory. Here you'll find a kvm
-image file, the UEFI firmware helper, and the KVM start helper script.
-
-
-Starter script
-==============
-
-To start the image, run the `qemu shell script`_ available in the
-`images`_ directory.
-
-SSH is needed for remote logins; however, SSH not enabled by default. To enable
-it, log in through serial console with the username ``root``. After setting the
-password, enable root login via SSH by configuring :file:`/etc/ssh/sshd_config`
-with this line::
-
-    PermitRootLogin yes
-
-Now you may connect from host via SSH through 2223::
-
-    $ ssh -p 10022 root@localhost
-
-Alternatively, there are a few other ways to approach this.
-
-*  To run the script without modifying its permissions::
-
-   $ bash start_qemu.sh clr_image
-
-*  To run it as a background process::
-
-   $ bash start_qemu.sh clr_image &
-
-*  If you'd like to run the script with execute permission::
-
-   $ chmod +x start_qemu.sh
-   $ ./start_qemu.sh clr_image
-
-*  And to run it as a background process::
-
-   $ ./start_qemu.sh clr_image &
-
-If you run into any trouble with qemu getting locked up, try editing the `qemu shell script`_
-and removing the ``aio=threads``
-
-
-.. _qemu shell script: http://download.clearlinux.org/image/start_qemu.sh
+.. _vm-kvm:
+
+Using KVM
+#########
+
+The easiest way to get started in a virtualized environment is to download
+a recent KVM image from the `images`_ directory. Here you'll find a kvm
+image file, the UEFI firmware helper, and the KVM start helper script.
+
+
+Starter script
+==============
+
+To start the image, run the `qemu shell script`_ available in the
+`images`_ directory.
+
+SSH is needed for remote logins; however, SSH not enabled by default. To enable
+it, log in through serial console with the username ``root``. After setting the
+password, enable root login via SSH by configuring :file:`/etc/ssh/sshd_config`
+with this line::
+
+    PermitRootLogin yes
+
+Now you may connect from host via SSH through 2223::
+
+    $ ssh -p 10022 root@localhost
+
+Alternatively, there are a few other ways to approach this.
+
+*  To run the script without modifying its permissions::
+
+   $ bash start_qemu.sh clr_image
+
+*  To run it as a background process::
+
+   $ bash start_qemu.sh clr_image &
+
+*  If you'd like to run the script with execute permission::
+
+   $ chmod +x start_qemu.sh
+   $ ./start_qemu.sh clr_image
+
+*  And to run it as a background process::
+
+   $ ./start_qemu.sh clr_image &
+
+If you run into any trouble with qemu getting locked up, try editing the `qemu shell script`_
+and removing the ``aio=threads``
+
+
+.. _qemu shell script: http://download.clearlinux.org/image/start_qemu.sh
 .. _images: http://download.clearlinux.org/image/

source/vm/virtualbox.rst

@@ -1,136 +1,136 @@
-.. _vm-virtualbox:
-
-Using VirtualBox
-################
-
-This section explains how to run Clear Linux OS for Intel® Architecture
-inside a `VirtualBox`_\* environment.
-
-Download VirtualBox
-===================
-
-VirtualBox is a hypervisor supported by Oracle. You can
-download it from the `official VirtualBox website`_ and select
-the operating system you are using.
-
-Download **version 5.0 or greater** to ensure support for
-the :abbr:`AVX (Advanced Vector Extensions)` needed to run
-Clear Linux OS for Intel Architecture.
-
-
-Create a virtual machine in VirtualBox
-======================================
-
-#. Download the `latest`_ live version (clear-XXXX-live.img.xz)
-   from https://download.clearlinux.org/image/.
-
-#. Decompress the downloaded image. Uncompressed image size is ~ **5GB**.
-
-   - On Linux ::
-
-       $ xz -d clear-XXXX-live.img.xz
-
-   - On Windows you can use `7zip`_.
-
-#. To convert a raw image to :abbr:`VDI (VirtualBox Disk Image)`
-   format, you can use one of the following commands::
-
-      $ VBoxManage convertfromraw clear-XXXX-live.img clear-XXXX-live.vdi --format VDI
-
-   or::
-
-      $ vbox-img convert --srcfilename clear-XXXX-live.img --dstfilename clear-XXXX-live.vdi --srcformat raw --dstformat vdi
-
-
-   Note: Be sure you have Virtual box directory in your PATH (i.e.: on Windows
-   :file:`C:\\Program Files\\Oracle\\VirtualBox`).
-
-#. Create a virtual machine using the VirtualBox assistant:
-
-   * Type: **Linux**
-   * Version: **Linux 2.6 / 3.x / 4.x (64-bit)**
-   * Attach the virtual disk created in the step number 3 as virtual hard disk file
-
-#. After it is created, go to settings to enable **EFI support**
-
-   * System -> Enable EFI (special OSes only)
-
-
-Run your new VM
-===============
-
-Clear Linux OS for Intel Architecture supports VirtualBox kernel modules used
-by the Linux kernel 4.4 :abbr:`LTS (Long Term Support)` (*kernel-lts bundle*).
-This kernel was selected because Clear Linux OS's main kernel
-(``kernel-native``) bundle keeps up-to-date with the upstream Linux kernel, 
-and sometimes VirtualBox kernel modules aren't compatible with pre-kernel
-releases.
-
-In the first boot, Clear Linux will ask for a login user, type **root** and
-then the system will ask you for a new password.
-
-To install the VirtualBox kernel modules, here are the steps:
-
-#. Install the bundle that supports VirtualBox modules::
-
-     # swupd bundle-add kernel-lts
-
-#. Set a timeout in the bootmanager to shows a menu at boot time::
-
-     # clr-boot-manager set-timeout 10
-
-#. Update the bootloader entries with::
-
-     # clr-boot-manager update
-
-#. Reboot your system with::
-
-     # reboot
-
-   and choose LTS kernel version.
-
-#. (*Optional*) Unset timeout to boot directly to LTS version::
-
-     # clr-boot-manager set-timeout 0
-
-#. (*Mandatory*) Update bootmanger to use always LTS version::
-
-     # clr-boot-manager update
-
-
-Install Guest Additions
------------------------
-
-The kernel modules are shipped with the ``kernel-lts`` bundle; however,
-you'll need to install the *user* Linux Guest Additions. To install the 
-VirtualBox Guest Additions, follow these steps:
-
-#. Install the **sysadmin-basic** bundle::
-
-     # swupd bundle-add sysadmin-basic
-
-#. Insert Guest Additions CD image using *Devices* menu
-
-#. Install Linux users Guest Additions::
-
-     # install-vbox-lga
-
-#. Reboot your system::
-
-     # reboot
-
-#. (*Optional*) To use Clear Linux graphical user interface, add the GUI bundle::
-
-     # swupd bundle-add os-utils-gui
-
-   once the ``os-utils-gui`` bundle is installed, start your graphical 
-   user interface with::
-
-     # startxfce4
-
-   Clear Linux doesn't provide a graphical display manager.
-
-.. _official VirtualBox website: https://www.virtualbox.org/wiki/Downloads
-.. _VirtualBox: https://www.virtualbox.org/
-.. _latest: https://download.clearlinux.org/image/
-.. _7zip: http://www.7-zip.org/
+.. _vm-virtualbox:
+
+Using VirtualBox
+################
+
+This section explains how to run Clear Linux OS for Intel® Architecture
+inside a `VirtualBox`_\* environment.
+
+Download VirtualBox
+===================
+
+VirtualBox is a hypervisor supported by Oracle. You can
+download it from the `official VirtualBox website`_ and select
+the operating system you are using.
+
+Download **version 5.0 or greater** to ensure support for
+the :abbr:`AVX (Advanced Vector Extensions)` needed to run
+Clear Linux OS for Intel Architecture.
+
+
+Create a virtual machine in VirtualBox
+======================================
+
+#. Download the `latest`_ live version (clear-XXXX-live.img.xz)
+   from https://download.clearlinux.org/image/.
+
+#. Decompress the downloaded image. Uncompressed image size is ~ **5GB**.
+
+   - On Linux ::
+
+       $ xz -d clear-XXXX-live.img.xz
+
+   - On Windows you can use `7zip`_.
+
+#. To convert a raw image to :abbr:`VDI (VirtualBox Disk Image)`
+   format, you can use one of the following commands::
+
+      $ VBoxManage convertfromraw clear-XXXX-live.img clear-XXXX-live.vdi --format VDI
+
+   or::
+
+      $ vbox-img convert --srcfilename clear-XXXX-live.img --dstfilename clear-XXXX-live.vdi --srcformat raw --dstformat vdi
+
+
+   Note: Be sure you have Virtual box directory in your PATH (i.e.: on Windows
+   :file:`C:\\Program Files\\Oracle\\VirtualBox`).
+
+#. Create a virtual machine using the VirtualBox assistant:
+
+   * Type: **Linux**
+   * Version: **Linux 2.6 / 3.x / 4.x (64-bit)**
+   * Attach the virtual disk created in the step number 3 as virtual hard disk file
+
+#. After it is created, go to settings to enable **EFI support**
+
+   * System -> Enable EFI (special OSes only)
+
+
+Run your new VM
+===============
+
+Clear Linux OS for Intel Architecture supports VirtualBox kernel modules used
+by the Linux kernel 4.4 :abbr:`LTS (Long Term Support)` (*kernel-lts bundle*).
+This kernel was selected because Clear Linux OS's main kernel
+(``kernel-native``) bundle keeps up-to-date with the upstream Linux kernel, 
+and sometimes VirtualBox kernel modules aren't compatible with pre-kernel
+releases.
+
+In the first boot, Clear Linux will ask for a login user, type **root** and
+then the system will ask you for a new password.
+
+To install the VirtualBox kernel modules, here are the steps:
+
+#. Install the bundle that supports VirtualBox modules::
+
+     # swupd bundle-add kernel-lts
+
+#. Set a timeout in the bootmanager to shows a menu at boot time::
+
+     # clr-boot-manager set-timeout 10
+
+#. Update the bootloader entries with::
+
+     # clr-boot-manager update
+
+#. Reboot your system with::
+
+     # reboot
+
+   and choose LTS kernel version.
+
+#. (*Optional*) Unset timeout to boot directly to LTS version::
+
+     # clr-boot-manager set-timeout 0
+
+#. (*Mandatory*) Update bootmanger to use always LTS version::
+
+     # clr-boot-manager update
+
+
+Install Guest Additions
+-----------------------
+
+The kernel modules are shipped with the ``kernel-lts`` bundle; however,
+you'll need to install the *user* Linux Guest Additions. To install the 
+VirtualBox Guest Additions, follow these steps:
+
+#. Install the **sysadmin-basic** bundle::
+
+     # swupd bundle-add sysadmin-basic
+
+#. Insert Guest Additions CD image using *Devices* menu
+
+#. Install Linux users Guest Additions::
+
+     # install-vbox-lga
+
+#. Reboot your system::
+
+     # reboot
+
+#. (*Optional*) To use Clear Linux graphical user interface, add the GUI bundle::
+
+     # swupd bundle-add os-utils-gui
+
+   once the ``os-utils-gui`` bundle is installed, start your graphical 
+   user interface with::
+
+     # startxfce4
+
+   Clear Linux doesn't provide a graphical display manager.
+
+.. _official VirtualBox website: https://www.virtualbox.org/wiki/Downloads
+.. _VirtualBox: https://www.virtualbox.org/
+.. _latest: https://download.clearlinux.org/image/
+.. _7zip: http://www.7-zip.org/

source/vm/vmware/esxi.rst

@@ -1,83 +1,83 @@
-.. _vm-vmware-esxi:
-
-Using *VMware** ESXi guest
-##########################
-
-
-This topic, which is based on *VMware vSphere 6*, explains how to use Clear Linux* OS
-for Intel® Architecture as ESXi Guest.
-
-Run Clear Linux OS for Intel Architecture
-=========================================
-
-#. Download the `latest`_ live version of the disk image.
-
-#. Decompress the downloaded image. Uncompressed image size is ~ **5GB**.
-
-#. Create a virtual machine with the following configuration:
-
-   - **Guest OS**: Linux, Distribution Other 3.x Linux (64-bits)
-
-   - **UEFI support**: Clear Linux uses `systemd-boot` as the UEFI boot manager
-     for EFI images. Find the settings for this option using the vSphere GUI; go
-     to the configuration settings of the virtual machine and select
-     **EFI boot firmware**.
-
-   - **IDE disk**: Convert to vmdk and attach the Clear Linux image you downloaded
-     above. To convert Clear Linux image to VMware disk (vmdk) you can use the
-     ``qemu-img`` command::
-
-       $ qemu-img convert -f raw -O vmdk  -p clear-vmware.img clear-vmware.vmdk
-
-#. Start the virtual machine
-
-
-Using an optimized kernel for *VMware*
-======================================
-
-Clear Linux provides an optional bundle called *kernel-vmware* that contains a
-specialized kernel with specific configuration for VMware hypervisor, including:
-
-* **vmw_balloon** -- A technique for memory reclamation that works like a
-  balloon. A guest can be inflated to reclaim physical memory. The balloon
-  can also be deflated to allow the guest free memory pages.
-
-* **vmw_pvscsi** -- A driver that allows use of the para-virtualized SCSI provided
-  by *VMware* hypervisors.
-
-* **vmxnet3** -- Allows use of VMware virtual ethernet NICs.
-
-* **vmwgfx** -- Allows use of a DRM driver for the VMware virtual hardware
-
-To use these features, add the ``kernel-vmware`` bundle to your Clear Linux install::
-
-   # swupd bundle-add kernel-vmware
-
-Now turn off the virtual machine and change the configuration as follows:
-
-  - **Guest OS**: Linux / 3.x Linux (64-bits)
-
-  - **UEFI support**: Clear Linux uses `systemd-boot` as the UEFI boot manager
-    for EFI images. To add UEFI support, go to "Configuration settings of the
-    virtual machine" -> "General Tab" -> "And select EFI boot firmware"
-
-  - **SCSI Para-virtualized disk**: Convert the Clear Linux image to an SCSI
-    VMware disk image and re-attach it.
-
-    #. Extract the image from the EXSi server to one Linux machine and use
-       ``qemu-img`` command::
-
-       $ qemu-img convert -f raw -O vmdk -o adapter_type=lsilogic -o compat6 -p clear-vmware.img clear-vmware.vmdk
-
-    #. Transfer the Clear Linux image to the VMware ESXi server and use the
-       :command:`vmkfstools` command (you need to access to ESXi command line )::
-
-       $ vmkfstools -i clear-vmware.vmdk -d zeroedthick clear-vmware-fix.vmdk
-
-    #. Add the converted image to the guest by using VMware vSphere virtual
-       machine settings
-
-Finally, start the modified virtual machine.
-
-.. _latest: https://download.clearlinux.org/image/
-
+.. _vm-vmware-esxi:
+
+Using *VMware** ESXi guest
+##########################
+
+
+This topic, which is based on *VMware vSphere 6*, explains how to use Clear Linux* OS
+for Intel® Architecture as ESXi Guest.
+
+Run Clear Linux OS for Intel Architecture
+=========================================
+
+#. Download the `latest`_ live version of the disk image.
+
+#. Decompress the downloaded image. Uncompressed image size is ~ **5GB**.
+
+#. Create a virtual machine with the following configuration:
+
+   - **Guest OS**: Linux, Distribution Other 3.x Linux (64-bits)
+
+   - **UEFI support**: Clear Linux uses `systemd-boot` as the UEFI boot manager
+     for EFI images. Find the settings for this option using the vSphere GUI; go
+     to the configuration settings of the virtual machine and select
+     **EFI boot firmware**.
+
+   - **IDE disk**: Convert to vmdk and attach the Clear Linux image you downloaded
+     above. To convert Clear Linux image to VMware disk (vmdk) you can use the
+     ``qemu-img`` command::
+
+       $ qemu-img convert -f raw -O vmdk  -p clear-vmware.img clear-vmware.vmdk
+
+#. Start the virtual machine
+
+
+Using an optimized kernel for *VMware*
+======================================
+
+Clear Linux provides an optional bundle called *kernel-vmware* that contains a
+specialized kernel with specific configuration for VMware hypervisor, including:
+
+* **vmw_balloon** -- A technique for memory reclamation that works like a
+  balloon. A guest can be inflated to reclaim physical memory. The balloon
+  can also be deflated to allow the guest free memory pages.
+
+* **vmw_pvscsi** -- A driver that allows use of the para-virtualized SCSI provided
+  by *VMware* hypervisors.
+
+* **vmxnet3** -- Allows use of VMware virtual ethernet NICs.
+
+* **vmwgfx** -- Allows use of a DRM driver for the VMware virtual hardware
+
+To use these features, add the ``kernel-vmware`` bundle to your Clear Linux install::
+
+   # swupd bundle-add kernel-vmware
+
+Now turn off the virtual machine and change the configuration as follows:
+
+  - **Guest OS**: Linux / 3.x Linux (64-bits)
+
+  - **UEFI support**: Clear Linux uses `systemd-boot` as the UEFI boot manager
+    for EFI images. To add UEFI support, go to "Configuration settings of the
+    virtual machine" -> "General Tab" -> "And select EFI boot firmware"
+
+  - **SCSI Para-virtualized disk**: Convert the Clear Linux image to an SCSI
+    VMware disk image and re-attach it.
+
+    #. Extract the image from the EXSi server to one Linux machine and use
+       ``qemu-img`` command::
+
+       $ qemu-img convert -f raw -O vmdk -o adapter_type=lsilogic -o compat6 -p clear-vmware.img clear-vmware.vmdk
+
+    #. Transfer the Clear Linux image to the VMware ESXi server and use the
+       :command:`vmkfstools` command (you need to access to ESXi command line )::
+
+       $ vmkfstools -i clear-vmware.vmdk -d zeroedthick clear-vmware-fix.vmdk
+
+    #. Add the converted image to the guest by using VMware vSphere virtual
+       machine settings
+
+Finally, start the modified virtual machine.
+
+.. _latest: https://download.clearlinux.org/image/
+

source/vm/vmware/player.rst

@@ -1,99 +1,99 @@
-.. _vm-vmware-player:
-
-Using VMware* Player
-####################
-
-This section explains how to run Clear Linux OS for Intel® Architecture 
-within a `VMware Player`_ environment.
-
-Install VMware Player
-=====================
-
-VMware Workstation Player, formerly VMware Player, is a virtualization
-software package for x64 computers running Microsoft Windows or Linux. Download
-VMware player from the `VMware website`_.
-
-Player on Linux
----------------
-
-For the Linux option, you should have a ``VMware-Player-[version]_FILE.bundle`` file. To
-install it, run:
-
-::
-
-  $ sudo bash ./VMware-Player-[version].x86_64.bundle
-
-Player on Windows
------------------
-
-Follow the instructions from the Setup Assistant.
-
-
-Prepare Image
-=============
-
-#. Download the `latest`_ Clear Linux OS for Intel Architecture **live** 
-   disk image, named ``[clear-[version_number]-live.img.xz]``.
-
-#. Decompress the image. Uncompressed image size ~ **5GB**.
-
-   * On Linux ::
-
-        $ unxz clear-VERSION-live.img.xz
-
-   * On Windows you can use `7zip`_.
-
-#. Convert the installer to :abbr:`VMDK (Virtual Machine Disk)` format.
-
-   * On Linux, you can use ``qemu-img convert``::
-
-      $ qemu-img convert -O vmdk clear-VERSION-live.img clear.vmdk
-
-   * On Windows, you can convert the live image to vmdk format (from raw format to vmdk)
-    with a tool like VBoxManage from `VirtualBox`_.
-
-
-Run using VMware* Player
-========================
-
-
-#. Create a new virtual machine.
-
-#. Click on “Create a new Virtual Machine”.
-
-   * Select “**I will install the operating system later**”, and click on “Next”.
-   * Select “**Linux**” as “Guest operating system” and version **Other Linux 3.x kernel 64-bit**.
-   * Type a name for the new virtual machine.
-   * Perform the *remaining steps* using the default options.
-
-#. Change boot type to EFI.  You must change the VMware virtual machine *configuration*
-   to **Support EFI firmware**; you can do this by editing the configuration ``.vmx``
-   file located in the virtual machine folder and adding the following line::
-
-     firmware = "efi"
-
-#. Attach the prepared image as SATA disk.  And when you have a new virtual machine,
-   edit its configuration as follows:
-
-   * Click on “Edit virtual machine settings”.
-   * Remove any default attached hard disk.
-   * Click on “Add” option below devices list tab and choose Hard disk.
-
-      * Choose **SATA** as the virtual disk type.
-      * Use the existing Clear Linux OS for Intel Architecture virtual disk
-
-     The live disk must be set as ``SATA 0:1 Hard Disk (SATA)``; you can verify
-     this under the “Advanced" section of the disk settings.
-
-Start the virtual machine
-=========================
-
-After configuring the settings above, start the virtual machine.
-
-
-.. _VMware website: https://www.vmware.com/products/player/playerpro-evaluation.html
-.. _VMware Player: http://www.vmware.com/products/player/
-.. _latest: https://download.clearlinux.org/image/
-.. _7zip: http://www.7-zip.org/
-.. _VirtualBox: https://www.virtualbox.org/
-
+.. _vm-vmware-player:
+
+Using VMware* Player
+####################
+
+This section explains how to run Clear Linux OS for Intel® Architecture 
+within a `VMware Player`_ environment.
+
+Install VMware Player
+=====================
+
+VMware Workstation Player, formerly VMware Player, is a virtualization
+software package for x64 computers running Microsoft Windows or Linux. Download
+VMware player from the `VMware website`_.
+
+Player on Linux
+---------------
+
+For the Linux option, you should have a ``VMware-Player-[version]_FILE.bundle`` file. To
+install it, run:
+
+::
+
+  $ sudo bash ./VMware-Player-[version].x86_64.bundle
+
+Player on Windows
+-----------------
+
+Follow the instructions from the Setup Assistant.
+
+
+Prepare Image
+=============
+
+#. Download the `latest`_ Clear Linux OS for Intel Architecture **live** 
+   disk image, named ``[clear-[version_number]-live.img.xz]``.
+
+#. Decompress the image. Uncompressed image size ~ **5GB**.
+
+   * On Linux ::
+
+        $ unxz clear-VERSION-live.img.xz
+
+   * On Windows you can use `7zip`_.
+
+#. Convert the installer to :abbr:`VMDK (Virtual Machine Disk)` format.
+
+   * On Linux, you can use ``qemu-img convert``::
+
+      $ qemu-img convert -O vmdk clear-VERSION-live.img clear.vmdk
+
+   * On Windows, you can convert the live image to vmdk format (from raw format to vmdk)
+    with a tool like VBoxManage from `VirtualBox`_.
+
+
+Run using VMware* Player
+========================
+
+
+#. Create a new virtual machine.
+
+#. Click on “Create a new Virtual Machine”.
+
+   * Select “**I will install the operating system later**”, and click on “Next”.
+   * Select “**Linux**” as “Guest operating system” and version **Other Linux 3.x kernel 64-bit**.
+   * Type a name for the new virtual machine.
+   * Perform the *remaining steps* using the default options.
+
+#. Change boot type to EFI.  You must change the VMware virtual machine *configuration*
+   to **Support EFI firmware**; you can do this by editing the configuration ``.vmx``
+   file located in the virtual machine folder and adding the following line::
+
+     firmware = "efi"
+
+#. Attach the prepared image as SATA disk.  And when you have a new virtual machine,
+   edit its configuration as follows:
+
+   * Click on “Edit virtual machine settings”.
+   * Remove any default attached hard disk.
+   * Click on “Add” option below devices list tab and choose Hard disk.
+
+      * Choose **SATA** as the virtual disk type.
+      * Use the existing Clear Linux OS for Intel Architecture virtual disk
+
+     The live disk must be set as ``SATA 0:1 Hard Disk (SATA)``; you can verify
+     this under the “Advanced" section of the disk settings.
+
+Start the virtual machine
+=========================
+
+After configuring the settings above, start the virtual machine.
+
+
+.. _VMware website: https://www.vmware.com/products/player/playerpro-evaluation.html
+.. _VMware Player: http://www.vmware.com/products/player/
+.. _latest: https://download.clearlinux.org/image/
+.. _7zip: http://www.7-zip.org/
+.. _VirtualBox: https://www.virtualbox.org/
+