diff --git a/.gitignore b/.gitignore deleted file mode 100644 index 38c70b718..000000000 --- a/.gitignore +++ /dev/null @@ -1,4 +0,0 @@ -plantuml.jar -/_build -/.tox - diff --git a/Makefile b/Makefile deleted file mode 100644 index fe710c701..000000000 --- a/Makefile +++ /dev/null @@ -1,159 +0,0 @@ -# Makefile for Sphinx documentation - -# You can set these variables from the command line. -SPHINXOPTS = -SPHINXBUILD = sphinx-build -PAPER = -BUILDDIR = _build - -# 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 gettext - -help: - @echo "Please use \`make ' where 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 " 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 " pdf to make PDF using rst2pdf" - @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 " linkcheck to check all external links for integrity" - @echo " doctest to run all doctests embedded in the documentation (if enabled)" - -clean: - -rm -rf $(BUILDDIR)/* - -html: - $(SPHINXBUILD) -b html -W $(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/fuel.qhcp" - @echo "To view the help file:" - @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/fuel.qhc" - -devhelp: - $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp - @echo - @echo "Build finished." - @echo "To view the help file:" - @echo "# mkdir -p $$HOME/.local/share/devhelp/fuel" - @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/fuel" - @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." - -pdf: - $(SPHINXBUILD) -b pdf $(ALLSPHINXOPTS) $(BUILDDIR)/pdf - @echo - @echo "Build finished; the PDF file is in $(BUILDDIR)/pdf." - -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." diff --git a/README.rst b/README.rst new file mode 100644 index 000000000..86e34d67c --- /dev/null +++ b/README.rst @@ -0,0 +1,10 @@ +This project is no longer maintained. + +The contents of this repository are still available in the Git +source code management system. To see the contents of this +repository before it reached its end of life, please check out the +previous commit with "git checkout HEAD^1". + +For any further questions, please email +openstack-discuss@lists.openstack.org or join #openstack-dev on +Freenode. diff --git a/_images/deliverables/d_install_rpm.png b/_images/deliverables/d_install_rpm.png deleted file mode 100644 index 666f816a2..000000000 Binary files a/_images/deliverables/d_install_rpm.png and /dev/null differ diff --git a/_images/deliverables/d_install_w_internet.png b/_images/deliverables/d_install_w_internet.png deleted file mode 100644 index be37102e7..000000000 Binary files a/_images/deliverables/d_install_w_internet.png and /dev/null differ diff --git a/_images/deliverables/d_install_wo_internet.png b/_images/deliverables/d_install_wo_internet.png deleted file mode 100644 index 736b3de66..000000000 Binary files a/_images/deliverables/d_install_wo_internet.png and /dev/null differ diff --git a/_images/deliverables/scr_change_hostname.png b/_images/deliverables/scr_change_hostname.png deleted file mode 100644 index 0ad592102..000000000 Binary files a/_images/deliverables/scr_change_hostname.png and /dev/null differ diff --git a/_images/deliverables/scr_change_pass_ui.png b/_images/deliverables/scr_change_pass_ui.png deleted file mode 100644 index e29c5af44..000000000 Binary files a/_images/deliverables/scr_change_pass_ui.png and /dev/null differ diff --git a/_images/deliverables/scr_fuel_log_in.png b/_images/deliverables/scr_fuel_log_in.png deleted file mode 100644 index 37721487c..000000000 Binary files a/_images/deliverables/scr_fuel_log_in.png and /dev/null differ diff --git a/_images/deliverables/scr_fuel_setup.png b/_images/deliverables/scr_fuel_setup.png deleted file mode 100644 index 96c4c2747..000000000 Binary files a/_images/deliverables/scr_fuel_setup.png and /dev/null differ diff --git a/_images/deliverables/scr_ironic_baremetal_nic_example.png b/_images/deliverables/scr_ironic_baremetal_nic_example.png deleted file mode 100644 index 393b6bd2c..000000000 Binary files a/_images/deliverables/scr_ironic_baremetal_nic_example.png and /dev/null differ diff --git a/_images/deliverables/scr_partition-disks.png b/_images/deliverables/scr_partition-disks.png deleted file mode 100644 index 0cabd39ec..000000000 Binary files a/_images/deliverables/scr_partition-disks.png and /dev/null differ diff --git a/_images/deliverables/scr_plugin_versioning.png b/_images/deliverables/scr_plugin_versioning.png deleted file mode 100644 index 5eabe9cf1..000000000 Binary files a/_images/deliverables/scr_plugin_versioning.png and /dev/null differ diff --git a/_images/source/d_install_w_internet.svg b/_images/source/d_install_w_internet.svg deleted file mode 100644 index 0b7c0c7bc..000000000 --- a/_images/source/d_install_w_internet.svg +++ /dev/null @@ -1 +0,0 @@ - \ No newline at end of file diff --git a/_images/source/d_install_wo_internet.svg b/_images/source/d_install_wo_internet.svg deleted file mode 100644 index 44498d0e2..000000000 --- a/_images/source/d_install_wo_internet.svg +++ /dev/null @@ -1 +0,0 @@ - \ No newline at end of file diff --git a/_images/title-page.png b/_images/title-page.png deleted file mode 100644 index 371c74d62..000000000 Binary files a/_images/title-page.png and /dev/null differ diff --git a/_templates/fuel.style b/_templates/fuel.style deleted file mode 100644 index 7db34640a..000000000 --- a/_templates/fuel.style +++ /dev/null @@ -1,50 +0,0 @@ -#embeddedFonts: [ [ "PT Sans" ], [ "PT Mono" ], [ "PT Serif" ] ] -# ["PT_Sans-CaptionBold.ttf", "PT_Sans-Bold.ttf", PT_Sans-Italic.ttf, PTF75F.ttf, PT_Sans-BoldItalic.ttf, -# PT_Sans-Narrow.ttf, PTF76F.ttf, PT_Sans-Bold_0.ttf, PT_Sans-NarrowBold.ttf, -# PTZ55F.ttf, PT_Sans-Caption.ttf, PT_Sans-Regular.ttf] - -fontsAlias: - stdBold: PT Sans Bold - stdBoldItalic: PT Sans Bold Italic - stdFont: PT Sans - stdItalic: PT Sans Italic - stdMono: PT Mono - stdMonoBold: PT Mono Bold - stdMonoBoldItalic: PT Mono Bold - stdMonoItalic: PT Mono - stdSans: PT Sans - stdSansBold: PT Sans Bold - stdSansBoldItalic: PT Sans BoldItalic - stdSansItalic: PT Sans Italic - stdSerif: PT Serif - -pageSetup: - firstTemplate: coverPage -# size: LETTER - -pageTemplates: - coverPage: - frames: [] - [0cm, 0cm, 100%, 100%] - background : _images/title-page.png - showHeader : false - showFooter : false - oneColumn: - frames: [] - [0cm, 0cm, 100%, 100%] - showHeader : true - showFooter : true - -styles: - seealso: - backColor: transparent - borderColor: transparent - parent: admonition - - seealso-heading: - parent: heading - fontName: PT Sans - fontSize: 150% - keepWithNext: true - spaceBefore: 0 - spaceAfter: 10 diff --git a/_templates/openstackdocs/css.html b/_templates/openstackdocs/css.html deleted file mode 100644 index 60204a95f..000000000 --- a/_templates/openstackdocs/css.html +++ /dev/null @@ -1,20 +0,0 @@ - - - - - - - - - - - - - - - - - diff --git a/_templates/openstackdocs/footer.html b/_templates/openstackdocs/footer.html deleted file mode 100644 index 9c35ce118..000000000 --- a/_templates/openstackdocs/footer.html +++ /dev/null @@ -1,56 +0,0 @@ - diff --git a/_templates/openstackdocs/header.html b/_templates/openstackdocs/header.html deleted file mode 100644 index 8071d1f07..000000000 --- a/_templates/openstackdocs/header.html +++ /dev/null @@ -1,107 +0,0 @@ - diff --git a/_templates/openstackdocs/layout.html b/_templates/openstackdocs/layout.html deleted file mode 100644 index 919315e46..000000000 --- a/_templates/openstackdocs/layout.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - -{% block header %}{% endblock %} - OpenStack Docs: {{ title }} - - - -{{ metatags }} -{% include 'css.html' %} -{%- for cssfile in css_files %} - -{%- endfor %} - {# FAVICON #} -{% if favicon %} - -{% endif %} -{% if theme_analytics_tracking_code %} - - - -{% endif %} - - -{% include 'header.html' %} -
-
-
-{% include 'titlerow.html' %} -
-
updated: {{ last_updated }}
-
-
-
-
-{% include 'localtoc.html' %} -
-
-{% block body %}{% endblock %} -
-
-
-
- {% if prev %} - - {% endif %} - {% if next %} - - {% endif %} - -
-
-
updated: {{ last_updated }}
-
-
-
-{% include 'license_cc.html' %} -
-
- - found an error? report a bug - questions? -
-
-
-{% include 'sidebartoc.html' %} -
-
-{% include 'footer.html' %} -{% include 'script_footer.html' %} - - diff --git a/_templates/openstackdocs/license_cc.html b/_templates/openstackdocs/license_cc.html deleted file mode 100644 index bdecb0158..000000000 --- a/_templates/openstackdocs/license_cc.html +++ /dev/null @@ -1,9 +0,0 @@ - - Creative Commons Attribution 3.0 License - -

- Except where otherwise noted, this document is licensed under - Creative Commons - Attribution 3.0 License. See all - OpenStack Legal Documents. -

diff --git a/_templates/openstackdocs/localtoc.html b/_templates/openstackdocs/localtoc.html deleted file mode 100644 index cccd5e366..000000000 --- a/_templates/openstackdocs/localtoc.html +++ /dev/null @@ -1,4 +0,0 @@ -{%- if display_toc %} -
Contents
-{{ toc }} -{%- endif %} diff --git a/_templates/openstackdocs/navigation.html b/_templates/openstackdocs/navigation.html deleted file mode 100644 index 8a78522b4..000000000 --- a/_templates/openstackdocs/navigation.html +++ /dev/null @@ -1,29 +0,0 @@ - diff --git a/_templates/openstackdocs/script_footer.html b/_templates/openstackdocs/script_footer.html deleted file mode 100644 index 707c6b921..000000000 --- a/_templates/openstackdocs/script_footer.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - - - - - - - - - - - - - - - diff --git a/_templates/openstackdocs/script_search.html b/_templates/openstackdocs/script_search.html deleted file mode 100644 index 98c9e9e86..000000000 --- a/_templates/openstackdocs/script_search.html +++ /dev/null @@ -1,28 +0,0 @@ - - diff --git a/_templates/openstackdocs/sidebartoc.html b/_templates/openstackdocs/sidebartoc.html deleted file mode 100644 index f37e70558..000000000 --- a/_templates/openstackdocs/sidebartoc.html +++ /dev/null @@ -1,12 +0,0 @@ -
-
- -
-
-
-
-

{{ _('Contents') }}

 - {{ toctree(maxdepth=theme_globaltoc_depth|toint, collapse=False, includehidden=theme_globaltoc_includehidden|tobool) }} -
-
-
diff --git a/_templates/openstackdocs/static/css/bootstrap.min.css b/_templates/openstackdocs/static/css/bootstrap.min.css deleted file mode 100644 index 702d8ccab..000000000 --- a/_templates/openstackdocs/static/css/bootstrap.min.css +++ /dev/null @@ -1,5 +0,0 @@ -/*! - * Bootstrap v3.2.0 (http://getbootstrap.com) - * Copyright 2011-2014 Twitter, Inc. - * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE) - *//*! normalize.css v3.0.1 | MIT License | git.io/normalize */html{font-family:sans-serif;-webkit-text-size-adjust:100%;-ms-text-size-adjust:100%}body{margin:0}article,aside,details,figcaption,figure,footer,header,hgroup,main,nav,section,summary{display:block}audio,canvas,progress,video{display:inline-block;vertical-align:baseline}audio:not([controls]){display:none;height:0}[hidden],template{display:none}a{background:0 0}a:active,a:hover{outline:0}abbr[title]{border-bottom:1px dotted}b,strong{font-weight:700}dfn{font-style:italic}h1{margin:.67em 0;font-size:2em}mark{color:#000;background:#ff0}small{font-size:80%}sub,sup{position:relative;font-size:75%;line-height:0;vertical-align:baseline}sup{top:-.5em}sub{bottom:-.25em}img{border:0}svg:not(:root){overflow:hidden}figure{margin:1em 40px}hr{height:0;-webkit-box-sizing:content-box;-moz-box-sizing:content-box;box-sizing:content-box}pre{overflow:auto}code,kbd,pre,samp{font-family:monospace,monospace;font-size:1em}button,input,optgroup,select,textarea{margin:0;font:inherit;color:inherit}button{overflow:visible}button,select{text-transform:none}button,html input[type=button],input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer}button[disabled],html input[disabled]{cursor:default}button::-moz-focus-inner,input::-moz-focus-inner{padding:0;border:0}input{line-height:normal}input[type=checkbox],input[type=radio]{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box;padding:0}input[type=number]::-webkit-inner-spin-button,input[type=number]::-webkit-outer-spin-button{height:auto}input[type=search]{-webkit-box-sizing:content-box;-moz-box-sizing:content-box;box-sizing:content-box;-webkit-appearance:textfield}input[type=search]::-webkit-search-cancel-button,input[type=search]::-webkit-search-decoration{-webkit-appearance:none}fieldset{padding:.35em .625em .75em;margin:0 2px;border:1px solid silver}legend{padding:0;border:0}textarea{overflow:auto}optgroup{font-weight:700}table{border-spacing:0;border-collapse:collapse}td,th{padding:0}@media print{*{color:#000!important;text-shadow:none!important;background:transparent!important;-webkit-box-shadow:none!important;box-shadow:none!important}a,a:visited{text-decoration:underline}a[href]:after{content:" (" attr(href) ")"}abbr[title]:after{content:" (" attr(title) ")"}a[href^="javascript:"]:after,a[href^="#"]:after{content:""}pre,blockquote{border:1px solid #999;page-break-inside:avoid}thead{display:table-header-group}tr,img{page-break-inside:avoid}img{max-width:100%!important}p,h2,h3{orphans:3;widows:3}h2,h3{page-break-after:avoid}select{background:#fff!important}.navbar{display:none}.table td,.table th{background-color:#fff!important}.btn>.caret,.dropup>.btn>.caret{border-top-color:#000!important}.label{border:1px solid #000}.table{border-collapse:collapse!important}.table-bordered th,.table-bordered td{border:1px solid #ddd!important}}@font-face{font-family:'Glyphicons Halflings';src:url(../fonts/glyphicons-halflings-regular.eot);src:url(../fonts/glyphicons-halflings-regular.eot?#iefix) format('embedded-opentype'),url(../fonts/glyphicons-halflings-regular.woff) format('woff'),url(../fonts/glyphicons-halflings-regular.ttf) format('truetype'),url(../fonts/glyphicons-halflings-regular.svg#glyphicons_halflingsregular) format('svg')}.glyphicon{position:relative;top:1px;display:inline-block;font-family:'Glyphicons Halflings';font-style:normal;font-weight:400;line-height:1;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale}.glyphicon-asterisk:before{content:"\2a"}.glyphicon-plus:before{content:"\2b"}.glyphicon-euro:before{content:"\20ac"}.glyphicon-minus:before{content:"\2212"}.glyphicon-cloud:before{content:"\2601"}.glyphicon-envelope:before{content:"\2709"}.glyphicon-pencil:before{content:"\270f"}.glyphicon-glass:before{content:"\e001"}.glyphicon-music:before{content:"\e002"}.glyphicon-search:before{content:"\e003"}.glyphicon-heart:before{content:"\e005"}.glyphicon-star:before{content:"\e006"}.glyphicon-star-empty:before{content:"\e007"}.glyphicon-user:before{content:"\e008"}.glyphicon-film:before{content:"\e009"}.glyphicon-th-large:before{content:"\e010"}.glyphicon-th:before{content:"\e011"}.glyphicon-th-list:before{content:"\e012"}.glyphicon-ok:before{content:"\e013"}.glyphicon-remove:before{content:"\e014"}.glyphicon-zoom-in:before{content:"\e015"}.glyphicon-zoom-out:before{content:"\e016"}.glyphicon-off:before{content:"\e017"}.glyphicon-signal:before{content:"\e018"}.glyphicon-cog:before{content:"\e019"}.glyphicon-trash:before{content:"\e020"}.glyphicon-home:before{content:"\e021"}.glyphicon-file:before{content:"\e022"}.glyphicon-time:before{content:"\e023"}.glyphicon-road:before{content:"\e024"}.glyphicon-download-alt:before{content:"\e025"}.glyphicon-download:before{content:"\e026"}.glyphicon-upload:before{content:"\e027"}.glyphicon-inbox:before{content:"\e028"}.glyphicon-play-circle:before{content:"\e029"}.glyphicon-repeat:before{content:"\e030"}.glyphicon-refresh:before{content:"\e031"}.glyphicon-list-alt:before{content:"\e032"}.glyphicon-lock:before{content:"\e033"}.glyphicon-flag:before{content:"\e034"}.glyphicon-headphones:before{content:"\e035"}.glyphicon-volume-off:before{content:"\e036"}.glyphicon-volume-down:before{content:"\e037"}.glyphicon-volume-up:before{content:"\e038"}.glyphicon-qrcode:before{content:"\e039"}.glyphicon-barcode:before{content:"\e040"}.glyphicon-tag:before{content:"\e041"}.glyphicon-tags:before{content:"\e042"}.glyphicon-book:before{content:"\e043"}.glyphicon-bookmark:before{content:"\e044"}.glyphicon-print:before{content:"\e045"}.glyphicon-camera:before{content:"\e046"}.glyphicon-font:before{content:"\e047"}.glyphicon-bold:before{content:"\e048"}.glyphicon-italic:before{content:"\e049"}.glyphicon-text-height:before{content:"\e050"}.glyphicon-text-width:before{content:"\e051"}.glyphicon-align-left:before{content:"\e052"}.glyphicon-align-center:before{content:"\e053"}.glyphicon-align-right:before{content:"\e054"}.glyphicon-align-justify:before{content:"\e055"}.glyphicon-list:before{content:"\e056"}.glyphicon-indent-left:before{content:"\e057"}.glyphicon-indent-right:before{content:"\e058"}.glyphicon-facetime-video:before{content:"\e059"}.glyphicon-picture:before{content:"\e060"}.glyphicon-map-marker:before{content:"\e062"}.glyphicon-adjust:before{content:"\e063"}.glyphicon-tint:before{content:"\e064"}.glyphicon-edit:before{content:"\e065"}.glyphicon-share:before{content:"\e066"}.glyphicon-check:before{content:"\e067"}.glyphicon-move:before{content:"\e068"}.glyphicon-step-backward:before{content:"\e069"}.glyphicon-fast-backward:before{content:"\e070"}.glyphicon-backward:before{content:"\e071"}.glyphicon-play:before{content:"\e072"}.glyphicon-pause:before{content:"\e073"}.glyphicon-stop:before{content:"\e074"}.glyphicon-forward:before{content:"\e075"}.glyphicon-fast-forward:before{content:"\e076"}.glyphicon-step-forward:before{content:"\e077"}.glyphicon-eject:before{content:"\e078"}.glyphicon-chevron-left:before{content:"\e079"}.glyphicon-chevron-right:before{content:"\e080"}.glyphicon-plus-sign:before{content:"\e081"}.glyphicon-minus-sign:before{content:"\e082"}.glyphicon-remove-sign:before{content:"\e083"}.glyphicon-ok-sign:before{content:"\e084"}.glyphicon-question-sign:before{content:"\e085"}.glyphicon-info-sign:before{content:"\e086"}.glyphicon-screenshot:before{content:"\e087"}.glyphicon-remove-circle:before{content:"\e088"}.glyphicon-ok-circle:before{content:"\e089"}.glyphicon-ban-circle:before{content:"\e090"}.glyphicon-arrow-left:before{content:"\e091"}.glyphicon-arrow-right:before{content:"\e092"}.glyphicon-arrow-up:before{content:"\e093"}.glyphicon-arrow-down:before{content:"\e094"}.glyphicon-share-alt:before{content:"\e095"}.glyphicon-resize-full:before{content:"\e096"}.glyphicon-resize-small:before{content:"\e097"}.glyphicon-exclamation-sign:before{content:"\e101"}.glyphicon-gift:before{content:"\e102"}.glyphicon-leaf:before{content:"\e103"}.glyphicon-fire:before{content:"\e104"}.glyphicon-eye-open:before{content:"\e105"}.glyphicon-eye-close:before{content:"\e106"}.glyphicon-warning-sign:before{content:"\e107"}.glyphicon-plane:before{content:"\e108"}.glyphicon-calendar:before{content:"\e109"}.glyphicon-random:before{content:"\e110"}.glyphicon-comment:before{content:"\e111"}.glyphicon-magnet:before{content:"\e112"}.glyphicon-chevron-up:before{content:"\e113"}.glyphicon-chevron-down:before{content:"\e114"}.glyphicon-retweet:before{content:"\e115"}.glyphicon-shopping-cart:before{content:"\e116"}.glyphicon-folder-close:before{content:"\e117"}.glyphicon-folder-open:before{content:"\e118"}.glyphicon-resize-vertical:before{content:"\e119"}.glyphicon-resize-horizontal:before{content:"\e120"}.glyphicon-hdd:before{content:"\e121"}.glyphicon-bullhorn:before{content:"\e122"}.glyphicon-bell:before{content:"\e123"}.glyphicon-certificate:before{content:"\e124"}.glyphicon-thumbs-up:before{content:"\e125"}.glyphicon-thumbs-down:before{content:"\e126"}.glyphicon-hand-right:before{content:"\e127"}.glyphicon-hand-left:before{content:"\e128"}.glyphicon-hand-up:before{content:"\e129"}.glyphicon-hand-down:before{content:"\e130"}.glyphicon-circle-arrow-right:before{content:"\e131"}.glyphicon-circle-arrow-left:before{content:"\e132"}.glyphicon-circle-arrow-up:before{content:"\e133"}.glyphicon-circle-arrow-down:before{content:"\e134"}.glyphicon-globe:before{content:"\e135"}.glyphicon-wrench:before{content:"\e136"}.glyphicon-tasks:before{content:"\e137"}.glyphicon-filter:before{content:"\e138"}.glyphicon-briefcase:before{content:"\e139"}.glyphicon-fullscreen:before{content:"\e140"}.glyphicon-dashboard:before{content:"\e141"}.glyphicon-paperclip:before{content:"\e142"}.glyphicon-heart-empty:before{content:"\e143"}.glyphicon-link:before{content:"\e144"}.glyphicon-phone:before{content:"\e145"}.glyphicon-pushpin:before{content:"\e146"}.glyphicon-usd:before{content:"\e148"}.glyphicon-gbp:before{content:"\e149"}.glyphicon-sort:before{content:"\e150"}.glyphicon-sort-by-alphabet:before{content:"\e151"}.glyphicon-sort-by-alphabet-alt:before{content:"\e152"}.glyphicon-sort-by-order:before{content:"\e153"}.glyphicon-sort-by-order-alt:before{content:"\e154"}.glyphicon-sort-by-attributes:before{content:"\e155"}.glyphicon-sort-by-attributes-alt:before{content:"\e156"}.glyphicon-unchecked:before{content:"\e157"}.glyphicon-expand:before{content:"\e158"}.glyphicon-collapse-down:before{content:"\e159"}.glyphicon-collapse-up:before{content:"\e160"}.glyphicon-log-in:before{content:"\e161"}.glyphicon-flash:before{content:"\e162"}.glyphicon-log-out:before{content:"\e163"}.glyphicon-new-window:before{content:"\e164"}.glyphicon-record:before{content:"\e165"}.glyphicon-save:before{content:"\e166"}.glyphicon-open:before{content:"\e167"}.glyphicon-saved:before{content:"\e168"}.glyphicon-import:before{content:"\e169"}.glyphicon-export:before{content:"\e170"}.glyphicon-send:before{content:"\e171"}.glyphicon-floppy-disk:before{content:"\e172"}.glyphicon-floppy-saved:before{content:"\e173"}.glyphicon-floppy-remove:before{content:"\e174"}.glyphicon-floppy-save:before{content:"\e175"}.glyphicon-floppy-open:before{content:"\e176"}.glyphicon-credit-card:before{content:"\e177"}.glyphicon-transfer:before{content:"\e178"}.glyphicon-cutlery:before{content:"\e179"}.glyphicon-header:before{content:"\e180"}.glyphicon-compressed:before{content:"\e181"}.glyphicon-earphone:before{content:"\e182"}.glyphicon-phone-alt:before{content:"\e183"}.glyphicon-tower:before{content:"\e184"}.glyphicon-stats:before{content:"\e185"}.glyphicon-sd-video:before{content:"\e186"}.glyphicon-hd-video:before{content:"\e187"}.glyphicon-subtitles:before{content:"\e188"}.glyphicon-sound-stereo:before{content:"\e189"}.glyphicon-sound-dolby:before{content:"\e190"}.glyphicon-sound-5-1:before{content:"\e191"}.glyphicon-sound-6-1:before{content:"\e192"}.glyphicon-sound-7-1:before{content:"\e193"}.glyphicon-copyright-mark:before{content:"\e194"}.glyphicon-registration-mark:before{content:"\e195"}.glyphicon-cloud-download:before{content:"\e197"}.glyphicon-cloud-upload:before{content:"\e198"}.glyphicon-tree-conifer:before{content:"\e199"}.glyphicon-tree-deciduous:before{content:"\e200"}*{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}:before,:after{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}html{font-size:10px;-webkit-tap-highlight-color:rgba(0,0,0,0)}body{font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:14px;line-height:1.42857143;color:#333;background-color:#fff}input,button,select,textarea{font-family:inherit;font-size:inherit;line-height:inherit}a{color:#428bca;text-decoration:none}a:hover,a:focus{color:#2a6496;text-decoration:underline}a:focus{outline:thin dotted;outline:5px auto -webkit-focus-ring-color;outline-offset:-2px}figure{margin:0}img{vertical-align:middle}.img-responsive,.thumbnail>img,.thumbnail a>img,.carousel-inner>.item>img,.carousel-inner>.item>a>img{display:block;width:100%;max-width:100%;height:auto}.img-rounded{border-radius:6px}.img-thumbnail{display:inline-block;width:100% \9;max-width:100%;height:auto;padding:4px;line-height:1.42857143;background-color:#fff;border:1px solid #ddd;border-radius:4px;-webkit-transition:all .2s ease-in-out;-o-transition:all .2s ease-in-out;transition:all .2s ease-in-out}.img-circle{border-radius:50%}hr{margin-top:20px;margin-bottom:20px;border:0;border-top:1px solid #eee}.sr-only{position:absolute;width:1px;height:1px;padding:0;margin:-1px;overflow:hidden;clip:rect(0,0,0,0);border:0}.sr-only-focusable:active,.sr-only-focusable:focus{position:static;width:auto;height:auto;margin:0;overflow:visible;clip:auto}h1,h2,h3,h4,h5,h6,.h1,.h2,.h3,.h4,.h5,.h6{font-family:inherit;font-weight:500;line-height:1.1;color:inherit}h1 small,h2 small,h3 small,h4 small,h5 small,h6 small,.h1 small,.h2 small,.h3 small,.h4 small,.h5 small,.h6 small,h1 .small,h2 .small,h3 .small,h4 .small,h5 .small,h6 .small,.h1 .small,.h2 .small,.h3 .small,.h4 .small,.h5 .small,.h6 .small{font-weight:400;line-height:1;color:#777}h1,.h1,h2,.h2,h3,.h3{margin-top:20px;margin-bottom:10px}h1 small,.h1 small,h2 small,.h2 small,h3 small,.h3 small,h1 .small,.h1 .small,h2 .small,.h2 .small,h3 .small,.h3 .small{font-size:65%}h4,.h4,h5,.h5,h6,.h6{margin-top:10px;margin-bottom:10px}h4 small,.h4 small,h5 small,.h5 small,h6 small,.h6 small,h4 .small,.h4 .small,h5 .small,.h5 .small,h6 .small,.h6 .small{font-size:75%}h1,.h1{font-size:36px}h2,.h2{font-size:30px}h3,.h3{font-size:24px}h4,.h4{font-size:18px}h5,.h5{font-size:14px}h6,.h6{font-size:12px}p{margin:0 0 10px}.lead{margin-bottom:20px;font-size:16px;font-weight:300;line-height:1.4}@media (min-width:768px){.lead{font-size:21px}}small,.small{font-size:85%}cite{font-style:normal}mark,.mark{padding:.2em;background-color:#fcf8e3}.text-left{text-align:left}.text-right{text-align:right}.text-center{text-align:center}.text-justify{text-align:justify}.text-nowrap{white-space:nowrap}.text-lowercase{text-transform:lowercase}.text-uppercase{text-transform:uppercase}.text-capitalize{text-transform:capitalize}.text-muted{color:#777}.text-primary{color:#428bca}a.text-primary:hover{color:#3071a9}.text-success{color:#3c763d}a.text-success:hover{color:#2b542c}.text-info{color:#31708f}a.text-info:hover{color:#245269}.text-warning{color:#8a6d3b}a.text-warning:hover{color:#66512c}.text-danger{color:#a94442}a.text-danger:hover{color:#843534}.bg-primary{color:#fff;background-color:#428bca}a.bg-primary:hover{background-color:#3071a9}.bg-success{background-color:#dff0d8}a.bg-success:hover{background-color:#c1e2b3}.bg-info{background-color:#d9edf7}a.bg-info:hover{background-color:#afd9ee}.bg-warning{background-color:#fcf8e3}a.bg-warning:hover{background-color:#f7ecb5}.bg-danger{background-color:#f2dede}a.bg-danger:hover{background-color:#e4b9b9}.page-header{padding-bottom:9px;margin:40px 0 20px;border-bottom:1px solid #eee}ul,ol{margin-top:0;margin-bottom:10px}ul ul,ol ul,ul ol,ol ol{margin-bottom:0}.list-unstyled{padding-left:0;list-style:none}.list-inline{padding-left:0;margin-left:-5px;list-style:none}.list-inline>li{display:inline-block;padding-right:5px;padding-left:5px}dl{margin-top:0;margin-bottom:20px}dt,dd{line-height:1.42857143}dt{font-weight:700}dd{margin-left:0}@media (min-width:768px){.dl-horizontal dt{float:left;width:160px;overflow:hidden;clear:left;text-align:right;text-overflow:ellipsis;white-space:nowrap}.dl-horizontal dd{margin-left:180px}}abbr[title],abbr[data-original-title]{cursor:help;border-bottom:1px dotted #777}.initialism{font-size:90%;text-transform:uppercase}blockquote{padding:10px 20px;margin:0 0 20px;font-size:17.5px;border-left:5px solid #eee}blockquote p:last-child,blockquote ul:last-child,blockquote ol:last-child{margin-bottom:0}blockquote footer,blockquote small,blockquote .small{display:block;font-size:80%;line-height:1.42857143;color:#777}blockquote footer:before,blockquote small:before,blockquote .small:before{content:'\2014 \00A0'}.blockquote-reverse,blockquote.pull-right{padding-right:15px;padding-left:0;text-align:right;border-right:5px solid #eee;border-left:0}.blockquote-reverse footer:before,blockquote.pull-right footer:before,.blockquote-reverse small:before,blockquote.pull-right small:before,.blockquote-reverse .small:before,blockquote.pull-right .small:before{content:''}.blockquote-reverse footer:after,blockquote.pull-right footer:after,.blockquote-reverse small:after,blockquote.pull-right small:after,.blockquote-reverse .small:after,blockquote.pull-right .small:after{content:'\00A0 \2014'}blockquote:before,blockquote:after{content:""}address{margin-bottom:20px;font-style:normal;line-height:1.42857143}code,kbd,pre,samp{font-family:Menlo,Monaco,Consolas,"Courier New",monospace}code{padding:2px 4px;font-size:90%;color:#c7254e;background-color:#f9f2f4;border-radius:4px}kbd{padding:2px 4px;font-size:90%;color:#fff;background-color:#333;border-radius:3px;-webkit-box-shadow:inset 0 -1px 0 rgba(0,0,0,.25);box-shadow:inset 0 -1px 0 rgba(0,0,0,.25)}kbd kbd{padding:0;font-size:100%;-webkit-box-shadow:none;box-shadow:none}pre{display:block;padding:9.5px;margin:0 0 10px;font-size:13px;line-height:1.42857143;word-break:break-all;word-wrap:break-word;background-color:#f5f5f5;border:1px solid #ccc;border-radius:4px}pre code{padding:0;font-size:inherit;color:inherit;white-space:pre-wrap;background-color:transparent;border-radius:0}.pre-scrollable{max-height:340px;overflow-y:scroll}.container{padding-right:15px;padding-left:15px;margin-right:auto;margin-left:auto}@media (min-width:768px){.container{width:750px}}@media (min-width:992px){.container{width:970px}}@media (min-width:1200px){.container{width:1170px}}.container-fluid{padding-right:15px;padding-left:15px;margin-right:auto;margin-left:auto}.row{margin-right:-15px;margin-left:-15px}.col-xs-1,.col-sm-1,.col-md-1,.col-lg-1,.col-xs-2,.col-sm-2,.col-md-2,.col-lg-2,.col-xs-3,.col-sm-3,.col-md-3,.col-lg-3,.col-xs-4,.col-sm-4,.col-md-4,.col-lg-4,.col-xs-5,.col-sm-5,.col-md-5,.col-lg-5,.col-xs-6,.col-sm-6,.col-md-6,.col-lg-6,.col-xs-7,.col-sm-7,.col-md-7,.col-lg-7,.col-xs-8,.col-sm-8,.col-md-8,.col-lg-8,.col-xs-9,.col-sm-9,.col-md-9,.col-lg-9,.col-xs-10,.col-sm-10,.col-md-10,.col-lg-10,.col-xs-11,.col-sm-11,.col-md-11,.col-lg-11,.col-xs-12,.col-sm-12,.col-md-12,.col-lg-12{position:relative;min-height:1px;padding-right:15px;padding-left:15px}.col-xs-1,.col-xs-2,.col-xs-3,.col-xs-4,.col-xs-5,.col-xs-6,.col-xs-7,.col-xs-8,.col-xs-9,.col-xs-10,.col-xs-11,.col-xs-12{float:left}.col-xs-12{width:100%}.col-xs-11{width:91.66666667%}.col-xs-10{width:83.33333333%}.col-xs-9{width:75%}.col-xs-8{width:66.66666667%}.col-xs-7{width:58.33333333%}.col-xs-6{width:50%}.col-xs-5{width:41.66666667%}.col-xs-4{width:33.33333333%}.col-xs-3{width:25%}.col-xs-2{width:16.66666667%}.col-xs-1{width:8.33333333%}.col-xs-pull-12{right:100%}.col-xs-pull-11{right:91.66666667%}.col-xs-pull-10{right:83.33333333%}.col-xs-pull-9{right:75%}.col-xs-pull-8{right:66.66666667%}.col-xs-pull-7{right:58.33333333%}.col-xs-pull-6{right:50%}.col-xs-pull-5{right:41.66666667%}.col-xs-pull-4{right:33.33333333%}.col-xs-pull-3{right:25%}.col-xs-pull-2{right:16.66666667%}.col-xs-pull-1{right:8.33333333%}.col-xs-pull-0{right:auto}.col-xs-push-12{left:100%}.col-xs-push-11{left:91.66666667%}.col-xs-push-10{left:83.33333333%}.col-xs-push-9{left:75%}.col-xs-push-8{left:66.66666667%}.col-xs-push-7{left:58.33333333%}.col-xs-push-6{left:50%}.col-xs-push-5{left:41.66666667%}.col-xs-push-4{left:33.33333333%}.col-xs-push-3{left:25%}.col-xs-push-2{left:16.66666667%}.col-xs-push-1{left:8.33333333%}.col-xs-push-0{left:auto}.col-xs-offset-12{margin-left:100%}.col-xs-offset-11{margin-left:91.66666667%}.col-xs-offset-10{margin-left:83.33333333%}.col-xs-offset-9{margin-left:75%}.col-xs-offset-8{margin-left:66.66666667%}.col-xs-offset-7{margin-left:58.33333333%}.col-xs-offset-6{margin-left:50%}.col-xs-offset-5{margin-left:41.66666667%}.col-xs-offset-4{margin-left:33.33333333%}.col-xs-offset-3{margin-left:25%}.col-xs-offset-2{margin-left:16.66666667%}.col-xs-offset-1{margin-left:8.33333333%}.col-xs-offset-0{margin-left:0}@media (min-width:768px){.col-sm-1,.col-sm-2,.col-sm-3,.col-sm-4,.col-sm-5,.col-sm-6,.col-sm-7,.col-sm-8,.col-sm-9,.col-sm-10,.col-sm-11,.col-sm-12{float:left}.col-sm-12{width:100%}.col-sm-11{width:91.66666667%}.col-sm-10{width:83.33333333%}.col-sm-9{width:75%}.col-sm-8{width:66.66666667%}.col-sm-7{width:58.33333333%}.col-sm-6{width:50%}.col-sm-5{width:41.66666667%}.col-sm-4{width:33.33333333%}.col-sm-3{width:25%}.col-sm-2{width:16.66666667%}.col-sm-1{width:8.33333333%}.col-sm-pull-12{right:100%}.col-sm-pull-11{right:91.66666667%}.col-sm-pull-10{right:83.33333333%}.col-sm-pull-9{right:75%}.col-sm-pull-8{right:66.66666667%}.col-sm-pull-7{right:58.33333333%}.col-sm-pull-6{right:50%}.col-sm-pull-5{right:41.66666667%}.col-sm-pull-4{right:33.33333333%}.col-sm-pull-3{right:25%}.col-sm-pull-2{right:16.66666667%}.col-sm-pull-1{right:8.33333333%}.col-sm-pull-0{right:auto}.col-sm-push-12{left:100%}.col-sm-push-11{left:91.66666667%}.col-sm-push-10{left:83.33333333%}.col-sm-push-9{left:75%}.col-sm-push-8{left:66.66666667%}.col-sm-push-7{left:58.33333333%}.col-sm-push-6{left:50%}.col-sm-push-5{left:41.66666667%}.col-sm-push-4{left:33.33333333%}.col-sm-push-3{left:25%}.col-sm-push-2{left:16.66666667%}.col-sm-push-1{left:8.33333333%}.col-sm-push-0{left:auto}.col-sm-offset-12{margin-left:100%}.col-sm-offset-11{margin-left:91.66666667%}.col-sm-offset-10{margin-left:83.33333333%}.col-sm-offset-9{margin-left:75%}.col-sm-offset-8{margin-left:66.66666667%}.col-sm-offset-7{margin-left:58.33333333%}.col-sm-offset-6{margin-left:50%}.col-sm-offset-5{margin-left:41.66666667%}.col-sm-offset-4{margin-left:33.33333333%}.col-sm-offset-3{margin-left:25%}.col-sm-offset-2{margin-left:16.66666667%}.col-sm-offset-1{margin-left:8.33333333%}.col-sm-offset-0{margin-left:0}}@media (min-width:992px){.col-md-1,.col-md-2,.col-md-3,.col-md-4,.col-md-5,.col-md-6,.col-md-7,.col-md-8,.col-md-9,.col-md-10,.col-md-11,.col-md-12{float:left}.col-md-12{width:100%}.col-md-11{width:91.66666667%}.col-md-10{width:83.33333333%}.col-md-9{width:75%}.col-md-8{width:66.66666667%}.col-md-7{width:58.33333333%}.col-md-6{width:50%}.col-md-5{width:41.66666667%}.col-md-4{width:33.33333333%}.col-md-3{width:25%}.col-md-2{width:16.66666667%}.col-md-1{width:8.33333333%}.col-md-pull-12{right:100%}.col-md-pull-11{right:91.66666667%}.col-md-pull-10{right:83.33333333%}.col-md-pull-9{right:75%}.col-md-pull-8{right:66.66666667%}.col-md-pull-7{right:58.33333333%}.col-md-pull-6{right:50%}.col-md-pull-5{right:41.66666667%}.col-md-pull-4{right:33.33333333%}.col-md-pull-3{right:25%}.col-md-pull-2{right:16.66666667%}.col-md-pull-1{right:8.33333333%}.col-md-pull-0{right:auto}.col-md-push-12{left:100%}.col-md-push-11{left:91.66666667%}.col-md-push-10{left:83.33333333%}.col-md-push-9{left:75%}.col-md-push-8{left:66.66666667%}.col-md-push-7{left:58.33333333%}.col-md-push-6{left:50%}.col-md-push-5{left:41.66666667%}.col-md-push-4{left:33.33333333%}.col-md-push-3{left:25%}.col-md-push-2{left:16.66666667%}.col-md-push-1{left:8.33333333%}.col-md-push-0{left:auto}.col-md-offset-12{margin-left:100%}.col-md-offset-11{margin-left:91.66666667%}.col-md-offset-10{margin-left:83.33333333%}.col-md-offset-9{margin-left:75%}.col-md-offset-8{margin-left:66.66666667%}.col-md-offset-7{margin-left:58.33333333%}.col-md-offset-6{margin-left:50%}.col-md-offset-5{margin-left:41.66666667%}.col-md-offset-4{margin-left:33.33333333%}.col-md-offset-3{margin-left:25%}.col-md-offset-2{margin-left:16.66666667%}.col-md-offset-1{margin-left:8.33333333%}.col-md-offset-0{margin-left:0}}@media (min-width:1200px){.col-lg-1,.col-lg-2,.col-lg-3,.col-lg-4,.col-lg-5,.col-lg-6,.col-lg-7,.col-lg-8,.col-lg-9,.col-lg-10,.col-lg-11,.col-lg-12{float:left}.col-lg-12{width:100%}.col-lg-11{width:91.66666667%}.col-lg-10{width:83.33333333%}.col-lg-9{width:75%}.col-lg-8{width:66.66666667%}.col-lg-7{width:58.33333333%}.col-lg-6{width:50%}.col-lg-5{width:41.66666667%}.col-lg-4{width:33.33333333%}.col-lg-3{width:25%}.col-lg-2{width:16.66666667%}.col-lg-1{width:8.33333333%}.col-lg-pull-12{right:100%}.col-lg-pull-11{right:91.66666667%}.col-lg-pull-10{right:83.33333333%}.col-lg-pull-9{right:75%}.col-lg-pull-8{right:66.66666667%}.col-lg-pull-7{right:58.33333333%}.col-lg-pull-6{right:50%}.col-lg-pull-5{right:41.66666667%}.col-lg-pull-4{right:33.33333333%}.col-lg-pull-3{right:25%}.col-lg-pull-2{right:16.66666667%}.col-lg-pull-1{right:8.33333333%}.col-lg-pull-0{right:auto}.col-lg-push-12{left:100%}.col-lg-push-11{left:91.66666667%}.col-lg-push-10{left:83.33333333%}.col-lg-push-9{left:75%}.col-lg-push-8{left:66.66666667%}.col-lg-push-7{left:58.33333333%}.col-lg-push-6{left:50%}.col-lg-push-5{left:41.66666667%}.col-lg-push-4{left:33.33333333%}.col-lg-push-3{left:25%}.col-lg-push-2{left:16.66666667%}.col-lg-push-1{left:8.33333333%}.col-lg-push-0{left:auto}.col-lg-offset-12{margin-left:100%}.col-lg-offset-11{margin-left:91.66666667%}.col-lg-offset-10{margin-left:83.33333333%}.col-lg-offset-9{margin-left:75%}.col-lg-offset-8{margin-left:66.66666667%}.col-lg-offset-7{margin-left:58.33333333%}.col-lg-offset-6{margin-left:50%}.col-lg-offset-5{margin-left:41.66666667%}.col-lg-offset-4{margin-left:33.33333333%}.col-lg-offset-3{margin-left:25%}.col-lg-offset-2{margin-left:16.66666667%}.col-lg-offset-1{margin-left:8.33333333%}.col-lg-offset-0{margin-left:0}}table{background-color:transparent}th{text-align:left}.table{width:100%;max-width:100%;margin-bottom:20px}.table>thead>tr>th,.table>tbody>tr>th,.table>tfoot>tr>th,.table>thead>tr>td,.table>tbody>tr>td,.table>tfoot>tr>td{padding:8px;line-height:1.42857143;vertical-align:top;border-top:1px solid #ddd}.table>thead>tr>th{vertical-align:bottom;border-bottom:2px solid #ddd}.table>caption+thead>tr:first-child>th,.table>colgroup+thead>tr:first-child>th,.table>thead:first-child>tr:first-child>th,.table>caption+thead>tr:first-child>td,.table>colgroup+thead>tr:first-child>td,.table>thead:first-child>tr:first-child>td{border-top:0}.table>tbody+tbody{border-top:2px solid #ddd}.table .table{background-color:#fff}.table-condensed>thead>tr>th,.table-condensed>tbody>tr>th,.table-condensed>tfoot>tr>th,.table-condensed>thead>tr>td,.table-condensed>tbody>tr>td,.table-condensed>tfoot>tr>td{padding:5px}.table-bordered{border:1px solid #ddd}.table-bordered>thead>tr>th,.table-bordered>tbody>tr>th,.table-bordered>tfoot>tr>th,.table-bordered>thead>tr>td,.table-bordered>tbody>tr>td,.table-bordered>tfoot>tr>td{border:1px solid #ddd}.table-bordered>thead>tr>th,.table-bordered>thead>tr>td{border-bottom-width:2px}.table-striped>tbody>tr:nth-child(odd)>td,.table-striped>tbody>tr:nth-child(odd)>th{background-color:#f9f9f9}.table-hover>tbody>tr:hover>td,.table-hover>tbody>tr:hover>th{background-color:#f5f5f5}table col[class*=col-]{position:static;display:table-column;float:none}table td[class*=col-],table th[class*=col-]{position:static;display:table-cell;float:none}.table>thead>tr>td.active,.table>tbody>tr>td.active,.table>tfoot>tr>td.active,.table>thead>tr>th.active,.table>tbody>tr>th.active,.table>tfoot>tr>th.active,.table>thead>tr.active>td,.table>tbody>tr.active>td,.table>tfoot>tr.active>td,.table>thead>tr.active>th,.table>tbody>tr.active>th,.table>tfoot>tr.active>th{background-color:#f5f5f5}.table-hover>tbody>tr>td.active:hover,.table-hover>tbody>tr>th.active:hover,.table-hover>tbody>tr.active:hover>td,.table-hover>tbody>tr:hover>.active,.table-hover>tbody>tr.active:hover>th{background-color:#e8e8e8}.table>thead>tr>td.success,.table>tbody>tr>td.success,.table>tfoot>tr>td.success,.table>thead>tr>th.success,.table>tbody>tr>th.success,.table>tfoot>tr>th.success,.table>thead>tr.success>td,.table>tbody>tr.success>td,.table>tfoot>tr.success>td,.table>thead>tr.success>th,.table>tbody>tr.success>th,.table>tfoot>tr.success>th{background-color:#dff0d8}.table-hover>tbody>tr>td.success:hover,.table-hover>tbody>tr>th.success:hover,.table-hover>tbody>tr.success:hover>td,.table-hover>tbody>tr:hover>.success,.table-hover>tbody>tr.success:hover>th{background-color:#d0e9c6}.table>thead>tr>td.info,.table>tbody>tr>td.info,.table>tfoot>tr>td.info,.table>thead>tr>th.info,.table>tbody>tr>th.info,.table>tfoot>tr>th.info,.table>thead>tr.info>td,.table>tbody>tr.info>td,.table>tfoot>tr.info>td,.table>thead>tr.info>th,.table>tbody>tr.info>th,.table>tfoot>tr.info>th{background-color:#d9edf7}.table-hover>tbody>tr>td.info:hover,.table-hover>tbody>tr>th.info:hover,.table-hover>tbody>tr.info:hover>td,.table-hover>tbody>tr:hover>.info,.table-hover>tbody>tr.info:hover>th{background-color:#c4e3f3}.table>thead>tr>td.warning,.table>tbody>tr>td.warning,.table>tfoot>tr>td.warning,.table>thead>tr>th.warning,.table>tbody>tr>th.warning,.table>tfoot>tr>th.warning,.table>thead>tr.warning>td,.table>tbody>tr.warning>td,.table>tfoot>tr.warning>td,.table>thead>tr.warning>th,.table>tbody>tr.warning>th,.table>tfoot>tr.warning>th{background-color:#fcf8e3}.table-hover>tbody>tr>td.warning:hover,.table-hover>tbody>tr>th.warning:hover,.table-hover>tbody>tr.warning:hover>td,.table-hover>tbody>tr:hover>.warning,.table-hover>tbody>tr.warning:hover>th{background-color:#faf2cc}.table>thead>tr>td.danger,.table>tbody>tr>td.danger,.table>tfoot>tr>td.danger,.table>thead>tr>th.danger,.table>tbody>tr>th.danger,.table>tfoot>tr>th.danger,.table>thead>tr.danger>td,.table>tbody>tr.danger>td,.table>tfoot>tr.danger>td,.table>thead>tr.danger>th,.table>tbody>tr.danger>th,.table>tfoot>tr.danger>th{background-color:#f2dede}.table-hover>tbody>tr>td.danger:hover,.table-hover>tbody>tr>th.danger:hover,.table-hover>tbody>tr.danger:hover>td,.table-hover>tbody>tr:hover>.danger,.table-hover>tbody>tr.danger:hover>th{background-color:#ebcccc}@media screen and (max-width:767px){.table-responsive{width:100%;margin-bottom:15px;overflow-x:auto;overflow-y:hidden;-webkit-overflow-scrolling:touch;-ms-overflow-style:-ms-autohiding-scrollbar;border:1px solid #ddd}.table-responsive>.table{margin-bottom:0}.table-responsive>.table>thead>tr>th,.table-responsive>.table>tbody>tr>th,.table-responsive>.table>tfoot>tr>th,.table-responsive>.table>thead>tr>td,.table-responsive>.table>tbody>tr>td,.table-responsive>.table>tfoot>tr>td{white-space:nowrap}.table-responsive>.table-bordered{border:0}.table-responsive>.table-bordered>thead>tr>th:first-child,.table-responsive>.table-bordered>tbody>tr>th:first-child,.table-responsive>.table-bordered>tfoot>tr>th:first-child,.table-responsive>.table-bordered>thead>tr>td:first-child,.table-responsive>.table-bordered>tbody>tr>td:first-child,.table-responsive>.table-bordered>tfoot>tr>td:first-child{border-left:0}.table-responsive>.table-bordered>thead>tr>th:last-child,.table-responsive>.table-bordered>tbody>tr>th:last-child,.table-responsive>.table-bordered>tfoot>tr>th:last-child,.table-responsive>.table-bordered>thead>tr>td:last-child,.table-responsive>.table-bordered>tbody>tr>td:last-child,.table-responsive>.table-bordered>tfoot>tr>td:last-child{border-right:0}.table-responsive>.table-bordered>tbody>tr:last-child>th,.table-responsive>.table-bordered>tfoot>tr:last-child>th,.table-responsive>.table-bordered>tbody>tr:last-child>td,.table-responsive>.table-bordered>tfoot>tr:last-child>td{border-bottom:0}}fieldset{min-width:0;padding:0;margin:0;border:0}legend{display:block;width:100%;padding:0;margin-bottom:20px;font-size:21px;line-height:inherit;color:#333;border:0;border-bottom:1px solid #e5e5e5}label{display:inline-block;max-width:100%;margin-bottom:5px;font-weight:700}input[type=search]{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}input[type=radio],input[type=checkbox]{margin:4px 0 0;margin-top:1px \9;line-height:normal}input[type=file]{display:block}input[type=range]{display:block;width:100%}select[multiple],select[size]{height:auto}input[type=file]:focus,input[type=radio]:focus,input[type=checkbox]:focus{outline:thin dotted;outline:5px auto -webkit-focus-ring-color;outline-offset:-2px}output{display:block;padding-top:7px;font-size:14px;line-height:1.42857143;color:#555}.form-control{display:block;width:100%;height:34px;padding:6px 12px;font-size:14px;line-height:1.42857143;color:#555;background-color:#fff;background-image:none;border:1px solid #ccc;border-radius:4px;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,.075);box-shadow:inset 0 1px 1px rgba(0,0,0,.075);-webkit-transition:border-color ease-in-out .15s,-webkit-box-shadow ease-in-out .15s;-o-transition:border-color ease-in-out .15s,box-shadow ease-in-out .15s;transition:border-color ease-in-out .15s,box-shadow ease-in-out .15s}.form-control:focus{border-color:#66afe9;outline:0;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,.075),0 0 8px rgba(102,175,233,.6);box-shadow:inset 0 1px 1px rgba(0,0,0,.075),0 0 8px rgba(102,175,233,.6)}.form-control::-moz-placeholder{color:#777;opacity:1}.form-control:-ms-input-placeholder{color:#777}.form-control::-webkit-input-placeholder{color:#777}.form-control[disabled],.form-control[readonly],fieldset[disabled] .form-control{cursor:not-allowed;background-color:#eee;opacity:1}textarea.form-control{height:auto}input[type=search]{-webkit-appearance:none}input[type=date],input[type=time],input[type=datetime-local],input[type=month]{line-height:34px;line-height:1.42857143 \0}input[type=date].input-sm,input[type=time].input-sm,input[type=datetime-local].input-sm,input[type=month].input-sm{line-height:30px}input[type=date].input-lg,input[type=time].input-lg,input[type=datetime-local].input-lg,input[type=month].input-lg{line-height:46px}.form-group{margin-bottom:15px}.radio,.checkbox{position:relative;display:block;min-height:20px;margin-top:10px;margin-bottom:10px}.radio label,.checkbox label{padding-left:20px;margin-bottom:0;font-weight:400;cursor:pointer}.radio input[type=radio],.radio-inline input[type=radio],.checkbox input[type=checkbox],.checkbox-inline input[type=checkbox]{position:absolute;margin-top:4px \9;margin-left:-20px}.radio+.radio,.checkbox+.checkbox{margin-top:-5px}.radio-inline,.checkbox-inline{display:inline-block;padding-left:20px;margin-bottom:0;font-weight:400;vertical-align:middle;cursor:pointer}.radio-inline+.radio-inline,.checkbox-inline+.checkbox-inline{margin-top:0;margin-left:10px}input[type=radio][disabled],input[type=checkbox][disabled],input[type=radio].disabled,input[type=checkbox].disabled,fieldset[disabled] input[type=radio],fieldset[disabled] input[type=checkbox]{cursor:not-allowed}.radio-inline.disabled,.checkbox-inline.disabled,fieldset[disabled] .radio-inline,fieldset[disabled] .checkbox-inline{cursor:not-allowed}.radio.disabled label,.checkbox.disabled label,fieldset[disabled] .radio label,fieldset[disabled] .checkbox label{cursor:not-allowed}.form-control-static{padding-top:7px;padding-bottom:7px;margin-bottom:0}.form-control-static.input-lg,.form-control-static.input-sm{padding-right:0;padding-left:0}.input-sm,.form-horizontal .form-group-sm .form-control{height:30px;padding:5px 10px;font-size:12px;line-height:1.5;border-radius:3px}select.input-sm{height:30px;line-height:30px}textarea.input-sm,select[multiple].input-sm{height:auto}.input-lg,.form-horizontal .form-group-lg .form-control{height:46px;padding:10px 16px;font-size:18px;line-height:1.33;border-radius:6px}select.input-lg{height:46px;line-height:46px}textarea.input-lg,select[multiple].input-lg{height:auto}.has-feedback{position:relative}.has-feedback .form-control{padding-right:42.5px}.form-control-feedback{position:absolute;top:25px;right:0;z-index:2;display:block;width:34px;height:34px;line-height:34px;text-align:center}.input-lg+.form-control-feedback{width:46px;height:46px;line-height:46px}.input-sm+.form-control-feedback{width:30px;height:30px;line-height:30px}.has-success .help-block,.has-success .control-label,.has-success .radio,.has-success .checkbox,.has-success .radio-inline,.has-success .checkbox-inline{color:#3c763d}.has-success .form-control{border-color:#3c763d;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,.075);box-shadow:inset 0 1px 1px rgba(0,0,0,.075)}.has-success .form-control:focus{border-color:#2b542c;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,.075),0 0 6px #67b168;box-shadow:inset 0 1px 1px rgba(0,0,0,.075),0 0 6px #67b168}.has-success .input-group-addon{color:#3c763d;background-color:#dff0d8;border-color:#3c763d}.has-success .form-control-feedback{color:#3c763d}.has-warning .help-block,.has-warning .control-label,.has-warning .radio,.has-warning .checkbox,.has-warning .radio-inline,.has-warning .checkbox-inline{color:#8a6d3b}.has-warning .form-control{border-color:#8a6d3b;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,.075);box-shadow:inset 0 1px 1px rgba(0,0,0,.075)}.has-warning .form-control:focus{border-color:#66512c;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,.075),0 0 6px #c0a16b;box-shadow:inset 0 1px 1px rgba(0,0,0,.075),0 0 6px #c0a16b}.has-warning .input-group-addon{color:#8a6d3b;background-color:#fcf8e3;border-color:#8a6d3b}.has-warning .form-control-feedback{color:#8a6d3b}.has-error .help-block,.has-error .control-label,.has-error .radio,.has-error .checkbox,.has-error .radio-inline,.has-error .checkbox-inline{color:#a94442}.has-error .form-control{border-color:#a94442;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,.075);box-shadow:inset 0 1px 1px rgba(0,0,0,.075)}.has-error .form-control:focus{border-color:#843534;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,.075),0 0 6px #ce8483;box-shadow:inset 0 1px 1px rgba(0,0,0,.075),0 0 6px #ce8483}.has-error .input-group-addon{color:#a94442;background-color:#f2dede;border-color:#a94442}.has-error .form-control-feedback{color:#a94442}.has-feedback label.sr-only~.form-control-feedback{top:0}.help-block{display:block;margin-top:5px;margin-bottom:10px;color:#737373}@media (min-width:768px){.form-inline .form-group{display:inline-block;margin-bottom:0;vertical-align:middle}.form-inline .form-control{display:inline-block;width:auto;vertical-align:middle}.form-inline .input-group{display:inline-table;vertical-align:middle}.form-inline .input-group .input-group-addon,.form-inline .input-group .input-group-btn,.form-inline .input-group .form-control{width:auto}.form-inline .input-group>.form-control{width:100%}.form-inline .control-label{margin-bottom:0;vertical-align:middle}.form-inline .radio,.form-inline .checkbox{display:inline-block;margin-top:0;margin-bottom:0;vertical-align:middle}.form-inline .radio label,.form-inline .checkbox label{padding-left:0}.form-inline .radio input[type=radio],.form-inline .checkbox input[type=checkbox]{position:relative;margin-left:0}.form-inline .has-feedback .form-control-feedback{top:0}}.form-horizontal .radio,.form-horizontal .checkbox,.form-horizontal .radio-inline,.form-horizontal .checkbox-inline{padding-top:7px;margin-top:0;margin-bottom:0}.form-horizontal .radio,.form-horizontal .checkbox{min-height:27px}.form-horizontal .form-group{margin-right:-15px;margin-left:-15px}@media (min-width:768px){.form-horizontal .control-label{padding-top:7px;margin-bottom:0;text-align:right}}.form-horizontal .has-feedback .form-control-feedback{top:0;right:15px}@media (min-width:768px){.form-horizontal .form-group-lg .control-label{padding-top:14.3px}}@media (min-width:768px){.form-horizontal .form-group-sm .control-label{padding-top:6px}}.btn{display:inline-block;padding:6px 12px;margin-bottom:0;font-size:14px;font-weight:400;line-height:1.42857143;text-align:center;white-space:nowrap;vertical-align:middle;cursor:pointer;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none;background-image:none;border:1px solid transparent;border-radius:4px}.btn:focus,.btn:active:focus,.btn.active:focus{outline:thin dotted;outline:5px auto -webkit-focus-ring-color;outline-offset:-2px}.btn:hover,.btn:focus{color:#333;text-decoration:none}.btn:active,.btn.active{background-image:none;outline:0;-webkit-box-shadow:inset 0 3px 5px rgba(0,0,0,.125);box-shadow:inset 0 3px 5px rgba(0,0,0,.125)}.btn.disabled,.btn[disabled],fieldset[disabled] .btn{pointer-events:none;cursor:not-allowed;filter:alpha(opacity=65);-webkit-box-shadow:none;box-shadow:none;opacity:.65}.btn-default{color:#333;background-color:#fff;border-color:#ccc}.btn-default:hover,.btn-default:focus,.btn-default:active,.btn-default.active,.open>.dropdown-toggle.btn-default{color:#333;background-color:#e6e6e6;border-color:#adadad}.btn-default:active,.btn-default.active,.open>.dropdown-toggle.btn-default{background-image:none}.btn-default.disabled,.btn-default[disabled],fieldset[disabled] .btn-default,.btn-default.disabled:hover,.btn-default[disabled]:hover,fieldset[disabled] .btn-default:hover,.btn-default.disabled:focus,.btn-default[disabled]:focus,fieldset[disabled] .btn-default:focus,.btn-default.disabled:active,.btn-default[disabled]:active,fieldset[disabled] .btn-default:active,.btn-default.disabled.active,.btn-default[disabled].active,fieldset[disabled] .btn-default.active{background-color:#fff;border-color:#ccc}.btn-default .badge{color:#fff;background-color:#333}.btn-primary{color:#fff;background-color:#428bca;border-color:#357ebd}.btn-primary:hover,.btn-primary:focus,.btn-primary:active,.btn-primary.active,.open>.dropdown-toggle.btn-primary{color:#fff;background-color:#3071a9;border-color:#285e8e}.btn-primary:active,.btn-primary.active,.open>.dropdown-toggle.btn-primary{background-image:none}.btn-primary.disabled,.btn-primary[disabled],fieldset[disabled] .btn-primary,.btn-primary.disabled:hover,.btn-primary[disabled]:hover,fieldset[disabled] .btn-primary:hover,.btn-primary.disabled:focus,.btn-primary[disabled]:focus,fieldset[disabled] .btn-primary:focus,.btn-primary.disabled:active,.btn-primary[disabled]:active,fieldset[disabled] .btn-primary:active,.btn-primary.disabled.active,.btn-primary[disabled].active,fieldset[disabled] .btn-primary.active{background-color:#428bca;border-color:#357ebd}.btn-primary .badge{color:#428bca;background-color:#fff}.btn-success{color:#fff;background-color:#5cb85c;border-color:#4cae4c}.btn-success:hover,.btn-success:focus,.btn-success:active,.btn-success.active,.open>.dropdown-toggle.btn-success{color:#fff;background-color:#449d44;border-color:#398439}.btn-success:active,.btn-success.active,.open>.dropdown-toggle.btn-success{background-image:none}.btn-success.disabled,.btn-success[disabled],fieldset[disabled] .btn-success,.btn-success.disabled:hover,.btn-success[disabled]:hover,fieldset[disabled] .btn-success:hover,.btn-success.disabled:focus,.btn-success[disabled]:focus,fieldset[disabled] .btn-success:focus,.btn-success.disabled:active,.btn-success[disabled]:active,fieldset[disabled] .btn-success:active,.btn-success.disabled.active,.btn-success[disabled].active,fieldset[disabled] .btn-success.active{background-color:#5cb85c;border-color:#4cae4c}.btn-success .badge{color:#5cb85c;background-color:#fff}.btn-info{color:#fff;background-color:#5bc0de;border-color:#46b8da}.btn-info:hover,.btn-info:focus,.btn-info:active,.btn-info.active,.open>.dropdown-toggle.btn-info{color:#fff;background-color:#31b0d5;border-color:#269abc}.btn-info:active,.btn-info.active,.open>.dropdown-toggle.btn-info{background-image:none}.btn-info.disabled,.btn-info[disabled],fieldset[disabled] .btn-info,.btn-info.disabled:hover,.btn-info[disabled]:hover,fieldset[disabled] .btn-info:hover,.btn-info.disabled:focus,.btn-info[disabled]:focus,fieldset[disabled] .btn-info:focus,.btn-info.disabled:active,.btn-info[disabled]:active,fieldset[disabled] .btn-info:active,.btn-info.disabled.active,.btn-info[disabled].active,fieldset[disabled] .btn-info.active{background-color:#5bc0de;border-color:#46b8da}.btn-info .badge{color:#5bc0de;background-color:#fff}.btn-warning{color:#fff;background-color:#f0ad4e;border-color:#eea236}.btn-warning:hover,.btn-warning:focus,.btn-warning:active,.btn-warning.active,.open>.dropdown-toggle.btn-warning{color:#fff;background-color:#ec971f;border-color:#d58512}.btn-warning:active,.btn-warning.active,.open>.dropdown-toggle.btn-warning{background-image:none}.btn-warning.disabled,.btn-warning[disabled],fieldset[disabled] .btn-warning,.btn-warning.disabled:hover,.btn-warning[disabled]:hover,fieldset[disabled] .btn-warning:hover,.btn-warning.disabled:focus,.btn-warning[disabled]:focus,fieldset[disabled] .btn-warning:focus,.btn-warning.disabled:active,.btn-warning[disabled]:active,fieldset[disabled] .btn-warning:active,.btn-warning.disabled.active,.btn-warning[disabled].active,fieldset[disabled] .btn-warning.active{background-color:#f0ad4e;border-color:#eea236}.btn-warning .badge{color:#f0ad4e;background-color:#fff}.btn-danger{color:#fff;background-color:#d9534f;border-color:#d43f3a}.btn-danger:hover,.btn-danger:focus,.btn-danger:active,.btn-danger.active,.open>.dropdown-toggle.btn-danger{color:#fff;background-color:#c9302c;border-color:#ac2925}.btn-danger:active,.btn-danger.active,.open>.dropdown-toggle.btn-danger{background-image:none}.btn-danger.disabled,.btn-danger[disabled],fieldset[disabled] .btn-danger,.btn-danger.disabled:hover,.btn-danger[disabled]:hover,fieldset[disabled] .btn-danger:hover,.btn-danger.disabled:focus,.btn-danger[disabled]:focus,fieldset[disabled] .btn-danger:focus,.btn-danger.disabled:active,.btn-danger[disabled]:active,fieldset[disabled] .btn-danger:active,.btn-danger.disabled.active,.btn-danger[disabled].active,fieldset[disabled] .btn-danger.active{background-color:#d9534f;border-color:#d43f3a}.btn-danger .badge{color:#d9534f;background-color:#fff}.btn-link{font-weight:400;color:#428bca;cursor:pointer;border-radius:0}.btn-link,.btn-link:active,.btn-link[disabled],fieldset[disabled] .btn-link{background-color:transparent;-webkit-box-shadow:none;box-shadow:none}.btn-link,.btn-link:hover,.btn-link:focus,.btn-link:active{border-color:transparent}.btn-link:hover,.btn-link:focus{color:#2a6496;text-decoration:underline;background-color:transparent}.btn-link[disabled]:hover,fieldset[disabled] .btn-link:hover,.btn-link[disabled]:focus,fieldset[disabled] .btn-link:focus{color:#777;text-decoration:none}.btn-lg,.btn-group-lg>.btn{padding:10px 16px;font-size:18px;line-height:1.33;border-radius:6px}.btn-sm,.btn-group-sm>.btn{padding:5px 10px;font-size:12px;line-height:1.5;border-radius:3px}.btn-xs,.btn-group-xs>.btn{padding:1px 5px;font-size:12px;line-height:1.5;border-radius:3px}.btn-block{display:block;width:100%}.btn-block+.btn-block{margin-top:5px}input[type=submit].btn-block,input[type=reset].btn-block,input[type=button].btn-block{width:100%}.fade{opacity:0;-webkit-transition:opacity .15s linear;-o-transition:opacity .15s linear;transition:opacity .15s linear}.fade.in{opacity:1}.collapse{display:none}.collapse.in{display:block}tr.collapse.in{display:table-row}tbody.collapse.in{display:table-row-group}.collapsing{position:relative;height:0;overflow:hidden;-webkit-transition:height .35s ease;-o-transition:height .35s ease;transition:height .35s ease}.caret{display:inline-block;width:0;height:0;margin-left:2px;vertical-align:middle;border-top:4px solid;border-right:4px solid transparent;border-left:4px solid transparent}.dropdown{position:relative}.dropdown-toggle:focus{outline:0}.dropdown-menu{position:absolute;top:100%;left:0;z-index:1000;display:none;float:left;min-width:160px;padding:5px 0;margin:2px 0 0;font-size:14px;text-align:left;list-style:none;background-color:#fff;-webkit-background-clip:padding-box;background-clip:padding-box;border:1px solid #ccc;border:1px solid rgba(0,0,0,.15);border-radius:4px;-webkit-box-shadow:0 6px 12px rgba(0,0,0,.175);box-shadow:0 6px 12px rgba(0,0,0,.175)}.dropdown-menu.pull-right{right:0;left:auto}.dropdown-menu .divider{height:1px;margin:9px 0;overflow:hidden;background-color:#e5e5e5}.dropdown-menu>li>a{display:block;padding:3px 20px;clear:both;font-weight:400;line-height:1.42857143;color:#333;white-space:nowrap}.dropdown-menu>li>a:hover,.dropdown-menu>li>a:focus{color:#262626;text-decoration:none;background-color:#f5f5f5}.dropdown-menu>.active>a,.dropdown-menu>.active>a:hover,.dropdown-menu>.active>a:focus{color:#fff;text-decoration:none;background-color:#428bca;outline:0}.dropdown-menu>.disabled>a,.dropdown-menu>.disabled>a:hover,.dropdown-menu>.disabled>a:focus{color:#777}.dropdown-menu>.disabled>a:hover,.dropdown-menu>.disabled>a:focus{text-decoration:none;cursor:not-allowed;background-color:transparent;background-image:none;filter:progid:DXImageTransform.Microsoft.gradient(enabled=false)}.open>.dropdown-menu{display:block}.open>a{outline:0}.dropdown-menu-right{right:0;left:auto}.dropdown-menu-left{right:auto;left:0}.dropdown-header{display:block;padding:3px 20px;font-size:12px;line-height:1.42857143;color:#777;white-space:nowrap}.dropdown-backdrop{position:fixed;top:0;right:0;bottom:0;left:0;z-index:990}.pull-right>.dropdown-menu{right:0;left:auto}.dropup .caret,.navbar-fixed-bottom .dropdown .caret{content:"";border-top:0;border-bottom:4px solid}.dropup .dropdown-menu,.navbar-fixed-bottom .dropdown .dropdown-menu{top:auto;bottom:100%;margin-bottom:1px}@media (min-width:768px){.navbar-right .dropdown-menu{right:0;left:auto}.navbar-right .dropdown-menu-left{right:auto;left:0}}.btn-group,.btn-group-vertical{position:relative;display:inline-block;vertical-align:middle}.btn-group>.btn,.btn-group-vertical>.btn{position:relative;float:left}.btn-group>.btn:hover,.btn-group-vertical>.btn:hover,.btn-group>.btn:focus,.btn-group-vertical>.btn:focus,.btn-group>.btn:active,.btn-group-vertical>.btn:active,.btn-group>.btn.active,.btn-group-vertical>.btn.active{z-index:2}.btn-group>.btn:focus,.btn-group-vertical>.btn:focus{outline:0}.btn-group .btn+.btn,.btn-group .btn+.btn-group,.btn-group .btn-group+.btn,.btn-group .btn-group+.btn-group{margin-left:-1px}.btn-toolbar{margin-left:-5px}.btn-toolbar .btn-group,.btn-toolbar .input-group{float:left}.btn-toolbar>.btn,.btn-toolbar>.btn-group,.btn-toolbar>.input-group{margin-left:5px}.btn-group>.btn:not(:first-child):not(:last-child):not(.dropdown-toggle){border-radius:0}.btn-group>.btn:first-child{margin-left:0}.btn-group>.btn:first-child:not(:last-child):not(.dropdown-toggle){border-top-right-radius:0;border-bottom-right-radius:0}.btn-group>.btn:last-child:not(:first-child),.btn-group>.dropdown-toggle:not(:first-child){border-top-left-radius:0;border-bottom-left-radius:0}.btn-group>.btn-group{float:left}.btn-group>.btn-group:not(:first-child):not(:last-child)>.btn{border-radius:0}.btn-group>.btn-group:first-child>.btn:last-child,.btn-group>.btn-group:first-child>.dropdown-toggle{border-top-right-radius:0;border-bottom-right-radius:0}.btn-group>.btn-group:last-child>.btn:first-child{border-top-left-radius:0;border-bottom-left-radius:0}.btn-group .dropdown-toggle:active,.btn-group.open .dropdown-toggle{outline:0}.btn-group>.btn+.dropdown-toggle{padding-right:8px;padding-left:8px}.btn-group>.btn-lg+.dropdown-toggle{padding-right:12px;padding-left:12px}.btn-group.open .dropdown-toggle{-webkit-box-shadow:inset 0 3px 5px rgba(0,0,0,.125);box-shadow:inset 0 3px 5px rgba(0,0,0,.125)}.btn-group.open .dropdown-toggle.btn-link{-webkit-box-shadow:none;box-shadow:none}.btn .caret{margin-left:0}.btn-lg .caret{border-width:5px 5px 0;border-bottom-width:0}.dropup .btn-lg .caret{border-width:0 5px 5px}.btn-group-vertical>.btn,.btn-group-vertical>.btn-group,.btn-group-vertical>.btn-group>.btn{display:block;float:none;width:100%;max-width:100%}.btn-group-vertical>.btn-group>.btn{float:none}.btn-group-vertical>.btn+.btn,.btn-group-vertical>.btn+.btn-group,.btn-group-vertical>.btn-group+.btn,.btn-group-vertical>.btn-group+.btn-group{margin-top:-1px;margin-left:0}.btn-group-vertical>.btn:not(:first-child):not(:last-child){border-radius:0}.btn-group-vertical>.btn:first-child:not(:last-child){border-top-right-radius:4px;border-bottom-right-radius:0;border-bottom-left-radius:0}.btn-group-vertical>.btn:last-child:not(:first-child){border-top-left-radius:0;border-top-right-radius:0;border-bottom-left-radius:4px}.btn-group-vertical>.btn-group:not(:first-child):not(:last-child)>.btn{border-radius:0}.btn-group-vertical>.btn-group:first-child:not(:last-child)>.btn:last-child,.btn-group-vertical>.btn-group:first-child:not(:last-child)>.dropdown-toggle{border-bottom-right-radius:0;border-bottom-left-radius:0}.btn-group-vertical>.btn-group:last-child:not(:first-child)>.btn:first-child{border-top-left-radius:0;border-top-right-radius:0}.btn-group-justified{display:table;width:100%;table-layout:fixed;border-collapse:separate}.btn-group-justified>.btn,.btn-group-justified>.btn-group{display:table-cell;float:none;width:1%}.btn-group-justified>.btn-group .btn{width:100%}.btn-group-justified>.btn-group .dropdown-menu{left:auto}[data-toggle=buttons]>.btn>input[type=radio],[data-toggle=buttons]>.btn>input[type=checkbox]{position:absolute;z-index:-1;filter:alpha(opacity=0);opacity:0}.input-group{position:relative;display:table;border-collapse:separate}.input-group[class*=col-]{float:none;padding-right:0;padding-left:0}.input-group .form-control{position:relative;z-index:2;float:left;width:100%;margin-bottom:0}.input-group-lg>.form-control,.input-group-lg>.input-group-addon,.input-group-lg>.input-group-btn>.btn{height:46px;padding:10px 16px;font-size:18px;line-height:1.33;border-radius:6px}select.input-group-lg>.form-control,select.input-group-lg>.input-group-addon,select.input-group-lg>.input-group-btn>.btn{height:46px;line-height:46px}textarea.input-group-lg>.form-control,textarea.input-group-lg>.input-group-addon,textarea.input-group-lg>.input-group-btn>.btn,select[multiple].input-group-lg>.form-control,select[multiple].input-group-lg>.input-group-addon,select[multiple].input-group-lg>.input-group-btn>.btn{height:auto}.input-group-sm>.form-control,.input-group-sm>.input-group-addon,.input-group-sm>.input-group-btn>.btn{height:30px;padding:5px 10px;font-size:12px;line-height:1.5;border-radius:3px}select.input-group-sm>.form-control,select.input-group-sm>.input-group-addon,select.input-group-sm>.input-group-btn>.btn{height:30px;line-height:30px}textarea.input-group-sm>.form-control,textarea.input-group-sm>.input-group-addon,textarea.input-group-sm>.input-group-btn>.btn,select[multiple].input-group-sm>.form-control,select[multiple].input-group-sm>.input-group-addon,select[multiple].input-group-sm>.input-group-btn>.btn{height:auto}.input-group-addon,.input-group-btn,.input-group .form-control{display:table-cell}.input-group-addon:not(:first-child):not(:last-child),.input-group-btn:not(:first-child):not(:last-child),.input-group .form-control:not(:first-child):not(:last-child){border-radius:0}.input-group-addon,.input-group-btn{width:1%;white-space:nowrap;vertical-align:middle}.input-group-addon{padding:6px 12px;font-size:14px;font-weight:400;line-height:1;color:#555;text-align:center;background-color:#eee;border:1px solid #ccc;border-radius:4px}.input-group-addon.input-sm{padding:5px 10px;font-size:12px;border-radius:3px}.input-group-addon.input-lg{padding:10px 16px;font-size:18px;border-radius:6px}.input-group-addon input[type=radio],.input-group-addon input[type=checkbox]{margin-top:0}.input-group .form-control:first-child,.input-group-addon:first-child,.input-group-btn:first-child>.btn,.input-group-btn:first-child>.btn-group>.btn,.input-group-btn:first-child>.dropdown-toggle,.input-group-btn:last-child>.btn:not(:last-child):not(.dropdown-toggle),.input-group-btn:last-child>.btn-group:not(:last-child)>.btn{border-top-right-radius:0;border-bottom-right-radius:0}.input-group-addon:first-child{border-right:0}.input-group .form-control:last-child,.input-group-addon:last-child,.input-group-btn:last-child>.btn,.input-group-btn:last-child>.btn-group>.btn,.input-group-btn:last-child>.dropdown-toggle,.input-group-btn:first-child>.btn:not(:first-child),.input-group-btn:first-child>.btn-group:not(:first-child)>.btn{border-top-left-radius:0;border-bottom-left-radius:0}.input-group-addon:last-child{border-left:0}.input-group-btn{position:relative;font-size:0;white-space:nowrap}.input-group-btn>.btn{position:relative}.input-group-btn>.btn+.btn{margin-left:-1px}.input-group-btn>.btn:hover,.input-group-btn>.btn:focus,.input-group-btn>.btn:active{z-index:2}.input-group-btn:first-child>.btn,.input-group-btn:first-child>.btn-group{margin-right:-1px}.input-group-btn:last-child>.btn,.input-group-btn:last-child>.btn-group{margin-left:-1px}.nav{padding-left:0;margin-bottom:0;list-style:none}.nav>li{position:relative;display:block}.nav>li>a{position:relative;display:block;padding:10px 15px}.nav>li>a:hover,.nav>li>a:focus{text-decoration:none;background-color:#eee}.nav>li.disabled>a{color:#777}.nav>li.disabled>a:hover,.nav>li.disabled>a:focus{color:#777;text-decoration:none;cursor:not-allowed;background-color:transparent}.nav .open>a,.nav .open>a:hover,.nav .open>a:focus{background-color:#eee;border-color:#428bca}.nav .nav-divider{height:1px;margin:9px 0;overflow:hidden;background-color:#e5e5e5}.nav>li>a>img{max-width:none}.nav-tabs{border-bottom:1px solid #ddd}.nav-tabs>li{float:left;margin-bottom:-1px}.nav-tabs>li>a{margin-right:2px;line-height:1.42857143;border:1px solid transparent;border-radius:4px 4px 0 0}.nav-tabs>li>a:hover{border-color:#eee #eee #ddd}.nav-tabs>li.active>a,.nav-tabs>li.active>a:hover,.nav-tabs>li.active>a:focus{color:#555;cursor:default;background-color:#fff;border:1px solid #ddd;border-bottom-color:transparent}.nav-tabs.nav-justified{width:100%;border-bottom:0}.nav-tabs.nav-justified>li{float:none}.nav-tabs.nav-justified>li>a{margin-bottom:5px;text-align:center}.nav-tabs.nav-justified>.dropdown .dropdown-menu{top:auto;left:auto}@media (min-width:768px){.nav-tabs.nav-justified>li{display:table-cell;width:1%}.nav-tabs.nav-justified>li>a{margin-bottom:0}}.nav-tabs.nav-justified>li>a{margin-right:0;border-radius:4px}.nav-tabs.nav-justified>.active>a,.nav-tabs.nav-justified>.active>a:hover,.nav-tabs.nav-justified>.active>a:focus{border:1px solid #ddd}@media (min-width:768px){.nav-tabs.nav-justified>li>a{border-bottom:1px solid #ddd;border-radius:4px 4px 0 0}.nav-tabs.nav-justified>.active>a,.nav-tabs.nav-justified>.active>a:hover,.nav-tabs.nav-justified>.active>a:focus{border-bottom-color:#fff}}.nav-pills>li{float:left}.nav-pills>li>a{border-radius:4px}.nav-pills>li+li{margin-left:2px}.nav-pills>li.active>a,.nav-pills>li.active>a:hover,.nav-pills>li.active>a:focus{color:#fff;background-color:#428bca}.nav-stacked>li{float:none}.nav-stacked>li+li{margin-top:2px;margin-left:0}.nav-justified{width:100%}.nav-justified>li{float:none}.nav-justified>li>a{margin-bottom:5px;text-align:center}.nav-justified>.dropdown .dropdown-menu{top:auto;left:auto}@media (min-width:768px){.nav-justified>li{display:table-cell;width:1%}.nav-justified>li>a{margin-bottom:0}}.nav-tabs-justified{border-bottom:0}.nav-tabs-justified>li>a{margin-right:0;border-radius:4px}.nav-tabs-justified>.active>a,.nav-tabs-justified>.active>a:hover,.nav-tabs-justified>.active>a:focus{border:1px solid #ddd}@media (min-width:768px){.nav-tabs-justified>li>a{border-bottom:1px solid #ddd;border-radius:4px 4px 0 0}.nav-tabs-justified>.active>a,.nav-tabs-justified>.active>a:hover,.nav-tabs-justified>.active>a:focus{border-bottom-color:#fff}}.tab-content>.tab-pane{display:none}.tab-content>.active{display:block}.nav-tabs .dropdown-menu{margin-top:-1px;border-top-left-radius:0;border-top-right-radius:0}.navbar{position:relative;min-height:50px;margin-bottom:20px;border:1px solid transparent}@media (min-width:768px){.navbar{border-radius:4px}}@media (min-width:768px){.navbar-header{float:left}}.navbar-collapse{padding-right:15px;padding-left:15px;overflow-x:visible;-webkit-overflow-scrolling:touch;border-top:1px solid transparent;-webkit-box-shadow:inset 0 1px 0 rgba(255,255,255,.1);box-shadow:inset 0 1px 0 rgba(255,255,255,.1)}.navbar-collapse.in{overflow-y:auto}@media (min-width:768px){.navbar-collapse{width:auto;border-top:0;-webkit-box-shadow:none;box-shadow:none}.navbar-collapse.collapse{display:block!important;height:auto!important;padding-bottom:0;overflow:visible!important}.navbar-collapse.in{overflow-y:visible}.navbar-fixed-top .navbar-collapse,.navbar-static-top .navbar-collapse,.navbar-fixed-bottom .navbar-collapse{padding-right:0;padding-left:0}}.navbar-fixed-top .navbar-collapse,.navbar-fixed-bottom .navbar-collapse{max-height:340px}@media (max-width:480px) and (orientation:landscape){.navbar-fixed-top .navbar-collapse,.navbar-fixed-bottom .navbar-collapse{max-height:200px}}.container>.navbar-header,.container-fluid>.navbar-header,.container>.navbar-collapse,.container-fluid>.navbar-collapse{margin-right:-15px;margin-left:-15px}@media (min-width:768px){.container>.navbar-header,.container-fluid>.navbar-header,.container>.navbar-collapse,.container-fluid>.navbar-collapse{margin-right:0;margin-left:0}}.navbar-static-top{z-index:1000;border-width:0 0 1px}@media (min-width:768px){.navbar-static-top{border-radius:0}}.navbar-fixed-top,.navbar-fixed-bottom{position:fixed;right:0;left:0;z-index:1030;-webkit-transform:translate3d(0,0,0);-o-transform:translate3d(0,0,0);transform:translate3d(0,0,0)}@media (min-width:768px){.navbar-fixed-top,.navbar-fixed-bottom{border-radius:0}}.navbar-fixed-top{top:0;border-width:0 0 1px}.navbar-fixed-bottom{bottom:0;margin-bottom:0;border-width:1px 0 0}.navbar-brand{float:left;height:50px;padding:15px 15px;font-size:18px;line-height:20px}.navbar-brand:hover,.navbar-brand:focus{text-decoration:none}@media (min-width:768px){.navbar>.container .navbar-brand,.navbar>.container-fluid .navbar-brand{margin-left:-15px}}.navbar-toggle{position:relative;float:right;padding:9px 10px;margin-top:8px;margin-right:15px;margin-bottom:8px;background-color:transparent;background-image:none;border:1px solid transparent;border-radius:4px}.navbar-toggle:focus{outline:0}.navbar-toggle .icon-bar{display:block;width:22px;height:2px;border-radius:1px}.navbar-toggle .icon-bar+.icon-bar{margin-top:4px}@media (min-width:768px){.navbar-toggle{display:none}}.navbar-nav{margin:7.5px -15px}.navbar-nav>li>a{padding-top:10px;padding-bottom:10px;line-height:20px}@media (max-width:767px){.navbar-nav .open .dropdown-menu{position:static;float:none;width:auto;margin-top:0;background-color:transparent;border:0;-webkit-box-shadow:none;box-shadow:none}.navbar-nav .open .dropdown-menu>li>a,.navbar-nav .open .dropdown-menu .dropdown-header{padding:5px 15px 5px 25px}.navbar-nav .open .dropdown-menu>li>a{line-height:20px}.navbar-nav .open .dropdown-menu>li>a:hover,.navbar-nav .open .dropdown-menu>li>a:focus{background-image:none}}@media (min-width:768px){.navbar-nav{float:left;margin:0}.navbar-nav>li{float:left}.navbar-nav>li>a{padding-top:15px;padding-bottom:15px}.navbar-nav.navbar-right:last-child{margin-right:-15px}}@media (min-width:768px){.navbar-left{float:left!important}.navbar-right{float:right!important}}.navbar-form{padding:10px 15px;margin-top:8px;margin-right:-15px;margin-bottom:8px;margin-left:-15px;border-top:1px solid transparent;border-bottom:1px solid transparent;-webkit-box-shadow:inset 0 1px 0 rgba(255,255,255,.1),0 1px 0 rgba(255,255,255,.1);box-shadow:inset 0 1px 0 rgba(255,255,255,.1),0 1px 0 rgba(255,255,255,.1)}@media (min-width:768px){.navbar-form .form-group{display:inline-block;margin-bottom:0;vertical-align:middle}.navbar-form .form-control{display:inline-block;width:auto;vertical-align:middle}.navbar-form .input-group{display:inline-table;vertical-align:middle}.navbar-form .input-group .input-group-addon,.navbar-form .input-group .input-group-btn,.navbar-form .input-group .form-control{width:auto}.navbar-form .input-group>.form-control{width:100%}.navbar-form .control-label{margin-bottom:0;vertical-align:middle}.navbar-form .radio,.navbar-form .checkbox{display:inline-block;margin-top:0;margin-bottom:0;vertical-align:middle}.navbar-form .radio label,.navbar-form .checkbox label{padding-left:0}.navbar-form .radio input[type=radio],.navbar-form .checkbox input[type=checkbox]{position:relative;margin-left:0}.navbar-form .has-feedback .form-control-feedback{top:0}}@media (max-width:767px){.navbar-form .form-group{margin-bottom:5px}}@media (min-width:768px){.navbar-form{width:auto;padding-top:0;padding-bottom:0;margin-right:0;margin-left:0;border:0;-webkit-box-shadow:none;box-shadow:none}.navbar-form.navbar-right:last-child{margin-right:-15px}}.navbar-nav>li>.dropdown-menu{margin-top:0;border-top-left-radius:0;border-top-right-radius:0}.navbar-fixed-bottom .navbar-nav>li>.dropdown-menu{border-bottom-right-radius:0;border-bottom-left-radius:0}.navbar-btn{margin-top:8px;margin-bottom:8px}.navbar-btn.btn-sm{margin-top:10px;margin-bottom:10px}.navbar-btn.btn-xs{margin-top:14px;margin-bottom:14px}.navbar-text{margin-top:15px;margin-bottom:15px}@media (min-width:768px){.navbar-text{float:left;margin-right:15px;margin-left:15px}.navbar-text.navbar-right:last-child{margin-right:0}}.navbar-default{background-color:#f8f8f8;border-color:#e7e7e7}.navbar-default .navbar-brand{color:#777}.navbar-default .navbar-brand:hover,.navbar-default .navbar-brand:focus{color:#5e5e5e;background-color:transparent}.navbar-default .navbar-text{color:#777}.navbar-default .navbar-nav>li>a{color:#777}.navbar-default .navbar-nav>li>a:hover,.navbar-default .navbar-nav>li>a:focus{color:#333;background-color:transparent}.navbar-default .navbar-nav>.active>a,.navbar-default .navbar-nav>.active>a:hover,.navbar-default .navbar-nav>.active>a:focus{color:#555;background-color:#e7e7e7}.navbar-default .navbar-nav>.disabled>a,.navbar-default .navbar-nav>.disabled>a:hover,.navbar-default .navbar-nav>.disabled>a:focus{color:#ccc;background-color:transparent}.navbar-default .navbar-toggle{border-color:#ddd}.navbar-default .navbar-toggle:hover,.navbar-default .navbar-toggle:focus{background-color:#ddd}.navbar-default .navbar-toggle .icon-bar{background-color:#888}.navbar-default .navbar-collapse,.navbar-default .navbar-form{border-color:#e7e7e7}.navbar-default .navbar-nav>.open>a,.navbar-default .navbar-nav>.open>a:hover,.navbar-default .navbar-nav>.open>a:focus{color:#555;background-color:#e7e7e7}@media (max-width:767px){.navbar-default .navbar-nav .open .dropdown-menu>li>a{color:#777}.navbar-default .navbar-nav .open .dropdown-menu>li>a:hover,.navbar-default .navbar-nav .open .dropdown-menu>li>a:focus{color:#333;background-color:transparent}.navbar-default .navbar-nav .open .dropdown-menu>.active>a,.navbar-default .navbar-nav .open .dropdown-menu>.active>a:hover,.navbar-default .navbar-nav .open .dropdown-menu>.active>a:focus{color:#555;background-color:#e7e7e7}.navbar-default .navbar-nav .open .dropdown-menu>.disabled>a,.navbar-default .navbar-nav .open .dropdown-menu>.disabled>a:hover,.navbar-default .navbar-nav .open .dropdown-menu>.disabled>a:focus{color:#ccc;background-color:transparent}}.navbar-default .navbar-link{color:#777}.navbar-default .navbar-link:hover{color:#333}.navbar-default .btn-link{color:#777}.navbar-default .btn-link:hover,.navbar-default .btn-link:focus{color:#333}.navbar-default .btn-link[disabled]:hover,fieldset[disabled] .navbar-default .btn-link:hover,.navbar-default .btn-link[disabled]:focus,fieldset[disabled] .navbar-default .btn-link:focus{color:#ccc}.navbar-inverse{background-color:#222;border-color:#080808}.navbar-inverse .navbar-brand{color:#777}.navbar-inverse .navbar-brand:hover,.navbar-inverse .navbar-brand:focus{color:#fff;background-color:transparent}.navbar-inverse .navbar-text{color:#777}.navbar-inverse .navbar-nav>li>a{color:#777}.navbar-inverse .navbar-nav>li>a:hover,.navbar-inverse .navbar-nav>li>a:focus{color:#fff;background-color:transparent}.navbar-inverse .navbar-nav>.active>a,.navbar-inverse .navbar-nav>.active>a:hover,.navbar-inverse .navbar-nav>.active>a:focus{color:#fff;background-color:#080808}.navbar-inverse .navbar-nav>.disabled>a,.navbar-inverse .navbar-nav>.disabled>a:hover,.navbar-inverse .navbar-nav>.disabled>a:focus{color:#444;background-color:transparent}.navbar-inverse .navbar-toggle{border-color:#333}.navbar-inverse .navbar-toggle:hover,.navbar-inverse .navbar-toggle:focus{background-color:#333}.navbar-inverse .navbar-toggle .icon-bar{background-color:#fff}.navbar-inverse .navbar-collapse,.navbar-inverse .navbar-form{border-color:#101010}.navbar-inverse .navbar-nav>.open>a,.navbar-inverse .navbar-nav>.open>a:hover,.navbar-inverse .navbar-nav>.open>a:focus{color:#fff;background-color:#080808}@media (max-width:767px){.navbar-inverse .navbar-nav .open .dropdown-menu>.dropdown-header{border-color:#080808}.navbar-inverse .navbar-nav .open .dropdown-menu .divider{background-color:#080808}.navbar-inverse .navbar-nav .open .dropdown-menu>li>a{color:#777}.navbar-inverse .navbar-nav .open .dropdown-menu>li>a:hover,.navbar-inverse .navbar-nav .open .dropdown-menu>li>a:focus{color:#fff;background-color:transparent}.navbar-inverse .navbar-nav .open .dropdown-menu>.active>a,.navbar-inverse .navbar-nav .open .dropdown-menu>.active>a:hover,.navbar-inverse .navbar-nav .open .dropdown-menu>.active>a:focus{color:#fff;background-color:#080808}.navbar-inverse .navbar-nav .open .dropdown-menu>.disabled>a,.navbar-inverse .navbar-nav .open .dropdown-menu>.disabled>a:hover,.navbar-inverse .navbar-nav .open .dropdown-menu>.disabled>a:focus{color:#444;background-color:transparent}}.navbar-inverse .navbar-link{color:#777}.navbar-inverse .navbar-link:hover{color:#fff}.navbar-inverse .btn-link{color:#777}.navbar-inverse .btn-link:hover,.navbar-inverse .btn-link:focus{color:#fff}.navbar-inverse .btn-link[disabled]:hover,fieldset[disabled] .navbar-inverse .btn-link:hover,.navbar-inverse .btn-link[disabled]:focus,fieldset[disabled] .navbar-inverse .btn-link:focus{color:#444}.breadcrumb{padding:8px 15px;margin-bottom:20px;list-style:none;background-color:#f5f5f5;border-radius:4px}.breadcrumb>li{display:inline-block}.breadcrumb>li+li:before{padding:0 5px;color:#ccc;content:"/\00a0"}.breadcrumb>.active{color:#777}.pagination{display:inline-block;padding-left:0;margin:20px 0;border-radius:4px}.pagination>li{display:inline}.pagination>li>a,.pagination>li>span{position:relative;float:left;padding:6px 12px;margin-left:-1px;line-height:1.42857143;color:#428bca;text-decoration:none;background-color:#fff;border:1px solid #ddd}.pagination>li:first-child>a,.pagination>li:first-child>span{margin-left:0;border-top-left-radius:4px;border-bottom-left-radius:4px}.pagination>li:last-child>a,.pagination>li:last-child>span{border-top-right-radius:4px;border-bottom-right-radius:4px}.pagination>li>a:hover,.pagination>li>span:hover,.pagination>li>a:focus,.pagination>li>span:focus{color:#2a6496;background-color:#eee;border-color:#ddd}.pagination>.active>a,.pagination>.active>span,.pagination>.active>a:hover,.pagination>.active>span:hover,.pagination>.active>a:focus,.pagination>.active>span:focus{z-index:2;color:#fff;cursor:default;background-color:#428bca;border-color:#428bca}.pagination>.disabled>span,.pagination>.disabled>span:hover,.pagination>.disabled>span:focus,.pagination>.disabled>a,.pagination>.disabled>a:hover,.pagination>.disabled>a:focus{color:#777;cursor:not-allowed;background-color:#fff;border-color:#ddd}.pagination-lg>li>a,.pagination-lg>li>span{padding:10px 16px;font-size:18px}.pagination-lg>li:first-child>a,.pagination-lg>li:first-child>span{border-top-left-radius:6px;border-bottom-left-radius:6px}.pagination-lg>li:last-child>a,.pagination-lg>li:last-child>span{border-top-right-radius:6px;border-bottom-right-radius:6px}.pagination-sm>li>a,.pagination-sm>li>span{padding:5px 10px;font-size:12px}.pagination-sm>li:first-child>a,.pagination-sm>li:first-child>span{border-top-left-radius:3px;border-bottom-left-radius:3px}.pagination-sm>li:last-child>a,.pagination-sm>li:last-child>span{border-top-right-radius:3px;border-bottom-right-radius:3px}.pager{padding-left:0;margin:20px 0;text-align:center;list-style:none}.pager li{display:inline}.pager li>a,.pager li>span{display:inline-block;padding:5px 14px;background-color:#fff;border:1px solid #ddd;border-radius:15px}.pager li>a:hover,.pager li>a:focus{text-decoration:none;background-color:#eee}.pager .next>a,.pager .next>span{float:right}.pager .previous>a,.pager .previous>span{float:left}.pager .disabled>a,.pager .disabled>a:hover,.pager .disabled>a:focus,.pager .disabled>span{color:#777;cursor:not-allowed;background-color:#fff}.label{display:inline;padding:.2em .6em .3em;font-size:75%;font-weight:700;line-height:1;color:#fff;text-align:center;white-space:nowrap;vertical-align:baseline;border-radius:.25em}a.label:hover,a.label:focus{color:#fff;text-decoration:none;cursor:pointer}.label:empty{display:none}.btn .label{position:relative;top:-1px}.label-default{background-color:#777}.label-default[href]:hover,.label-default[href]:focus{background-color:#5e5e5e}.label-primary{background-color:#428bca}.label-primary[href]:hover,.label-primary[href]:focus{background-color:#3071a9}.label-success{background-color:#5cb85c}.label-success[href]:hover,.label-success[href]:focus{background-color:#449d44}.label-info{background-color:#5bc0de}.label-info[href]:hover,.label-info[href]:focus{background-color:#31b0d5}.label-warning{background-color:#f0ad4e}.label-warning[href]:hover,.label-warning[href]:focus{background-color:#ec971f}.label-danger{background-color:#d9534f}.label-danger[href]:hover,.label-danger[href]:focus{background-color:#c9302c}.badge{display:inline-block;min-width:10px;padding:3px 7px;font-size:12px;font-weight:700;line-height:1;color:#fff;text-align:center;white-space:nowrap;vertical-align:baseline;background-color:#777;border-radius:10px}.badge:empty{display:none}.btn .badge{position:relative;top:-1px}.btn-xs .badge{top:0;padding:1px 5px}a.badge:hover,a.badge:focus{color:#fff;text-decoration:none;cursor:pointer}a.list-group-item.active>.badge,.nav-pills>.active>a>.badge{color:#428bca;background-color:#fff}.nav-pills>li>a>.badge{margin-left:3px}.jumbotron{padding:30px;margin-bottom:30px;color:inherit;background-color:#eee}.jumbotron h1,.jumbotron .h1{color:inherit}.jumbotron p{margin-bottom:15px;font-size:21px;font-weight:200}.jumbotron>hr{border-top-color:#d5d5d5}.container .jumbotron{border-radius:6px}.jumbotron .container{max-width:100%}@media screen and (min-width:768px){.jumbotron{padding-top:48px;padding-bottom:48px}.container .jumbotron{padding-right:60px;padding-left:60px}.jumbotron h1,.jumbotron .h1{font-size:63px}}.thumbnail{display:block;padding:4px;margin-bottom:20px;line-height:1.42857143;background-color:#fff;border:1px solid #ddd;border-radius:4px;-webkit-transition:all .2s ease-in-out;-o-transition:all .2s ease-in-out;transition:all .2s ease-in-out}.thumbnail>img,.thumbnail a>img{margin-right:auto;margin-left:auto}a.thumbnail:hover,a.thumbnail:focus,a.thumbnail.active{border-color:#428bca}.thumbnail .caption{padding:9px;color:#333}.alert{padding:15px;margin-bottom:20px;border:1px solid transparent;border-radius:4px}.alert h4{margin-top:0;color:inherit}.alert .alert-link{font-weight:700}.alert>p,.alert>ul{margin-bottom:0}.alert>p+p{margin-top:5px}.alert-dismissable,.alert-dismissible{padding-right:35px}.alert-dismissable .close,.alert-dismissible .close{position:relative;top:-2px;right:-21px;color:inherit}.alert-success{color:#3c763d;background-color:#dff0d8;border-color:#d6e9c6}.alert-success hr{border-top-color:#c9e2b3}.alert-success .alert-link{color:#2b542c}.alert-info{color:#31708f;background-color:#d9edf7;border-color:#bce8f1}.alert-info hr{border-top-color:#a6e1ec}.alert-info .alert-link{color:#245269}.alert-warning{color:#8a6d3b;background-color:#fcf8e3;border-color:#faebcc}.alert-warning hr{border-top-color:#f7e1b5}.alert-warning .alert-link{color:#66512c}.alert-danger{color:#a94442;background-color:#f2dede;border-color:#ebccd1}.alert-danger hr{border-top-color:#e4b9c0}.alert-danger .alert-link{color:#843534}@-webkit-keyframes progress-bar-stripes{from{background-position:40px 0}to{background-position:0 0}}@-o-keyframes progress-bar-stripes{from{background-position:40px 0}to{background-position:0 0}}@keyframes progress-bar-stripes{from{background-position:40px 0}to{background-position:0 0}}.progress{height:20px;margin-bottom:20px;overflow:hidden;background-color:#f5f5f5;border-radius:4px;-webkit-box-shadow:inset 0 1px 2px rgba(0,0,0,.1);box-shadow:inset 0 1px 2px rgba(0,0,0,.1)}.progress-bar{float:left;width:0;height:100%;font-size:12px;line-height:20px;color:#fff;text-align:center;background-color:#428bca;-webkit-box-shadow:inset 0 -1px 0 rgba(0,0,0,.15);box-shadow:inset 0 -1px 0 rgba(0,0,0,.15);-webkit-transition:width .6s ease;-o-transition:width .6s ease;transition:width .6s ease}.progress-striped .progress-bar,.progress-bar-striped{background-image:-webkit-linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent);background-image:-o-linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent);background-image:linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent);-webkit-background-size:40px 40px;background-size:40px 40px}.progress.active .progress-bar,.progress-bar.active{-webkit-animation:progress-bar-stripes 2s linear infinite;-o-animation:progress-bar-stripes 2s linear infinite;animation:progress-bar-stripes 2s linear infinite}.progress-bar[aria-valuenow="1"],.progress-bar[aria-valuenow="2"]{min-width:30px}.progress-bar[aria-valuenow="0"]{min-width:30px;color:#777;background-color:transparent;background-image:none;-webkit-box-shadow:none;box-shadow:none}.progress-bar-success{background-color:#5cb85c}.progress-striped .progress-bar-success{background-image:-webkit-linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent);background-image:-o-linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent);background-image:linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent)}.progress-bar-info{background-color:#5bc0de}.progress-striped .progress-bar-info{background-image:-webkit-linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent);background-image:-o-linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent);background-image:linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent)}.progress-bar-warning{background-color:#f0ad4e}.progress-striped .progress-bar-warning{background-image:-webkit-linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent);background-image:-o-linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent);background-image:linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent)}.progress-bar-danger{background-color:#d9534f}.progress-striped .progress-bar-danger{background-image:-webkit-linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent);background-image:-o-linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent);background-image:linear-gradient(45deg,rgba(255,255,255,.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,.15) 50%,rgba(255,255,255,.15) 75%,transparent 75%,transparent)}.media,.media-body{overflow:hidden;zoom:1}.media,.media .media{margin-top:15px}.media:first-child{margin-top:0}.media-object{display:block}.media-heading{margin:0 0 5px}.media>.pull-left{margin-right:10px}.media>.pull-right{margin-left:10px}.media-list{padding-left:0;list-style:none}.list-group{padding-left:0;margin-bottom:20px}.list-group-item{position:relative;display:block;padding:10px 15px;margin-bottom:-1px;background-color:#fff;border:1px solid #ddd}.list-group-item:first-child{border-top-left-radius:4px;border-top-right-radius:4px}.list-group-item:last-child{margin-bottom:0;border-bottom-right-radius:4px;border-bottom-left-radius:4px}.list-group-item>.badge{float:right}.list-group-item>.badge+.badge{margin-right:5px}a.list-group-item{color:#555}a.list-group-item .list-group-item-heading{color:#333}a.list-group-item:hover,a.list-group-item:focus{color:#555;text-decoration:none;background-color:#f5f5f5}.list-group-item.disabled,.list-group-item.disabled:hover,.list-group-item.disabled:focus{color:#777;background-color:#eee}.list-group-item.disabled .list-group-item-heading,.list-group-item.disabled:hover .list-group-item-heading,.list-group-item.disabled:focus .list-group-item-heading{color:inherit}.list-group-item.disabled .list-group-item-text,.list-group-item.disabled:hover .list-group-item-text,.list-group-item.disabled:focus .list-group-item-text{color:#777}.list-group-item.active,.list-group-item.active:hover,.list-group-item.active:focus{z-index:2;color:#fff;background-color:#428bca;border-color:#428bca}.list-group-item.active .list-group-item-heading,.list-group-item.active:hover .list-group-item-heading,.list-group-item.active:focus .list-group-item-heading,.list-group-item.active .list-group-item-heading>small,.list-group-item.active:hover .list-group-item-heading>small,.list-group-item.active:focus .list-group-item-heading>small,.list-group-item.active .list-group-item-heading>.small,.list-group-item.active:hover .list-group-item-heading>.small,.list-group-item.active:focus .list-group-item-heading>.small{color:inherit}.list-group-item.active .list-group-item-text,.list-group-item.active:hover .list-group-item-text,.list-group-item.active:focus .list-group-item-text{color:#e1edf7}.list-group-item-success{color:#3c763d;background-color:#dff0d8}a.list-group-item-success{color:#3c763d}a.list-group-item-success .list-group-item-heading{color:inherit}a.list-group-item-success:hover,a.list-group-item-success:focus{color:#3c763d;background-color:#d0e9c6}a.list-group-item-success.active,a.list-group-item-success.active:hover,a.list-group-item-success.active:focus{color:#fff;background-color:#3c763d;border-color:#3c763d}.list-group-item-info{color:#31708f;background-color:#d9edf7}a.list-group-item-info{color:#31708f}a.list-group-item-info .list-group-item-heading{color:inherit}a.list-group-item-info:hover,a.list-group-item-info:focus{color:#31708f;background-color:#c4e3f3}a.list-group-item-info.active,a.list-group-item-info.active:hover,a.list-group-item-info.active:focus{color:#fff;background-color:#31708f;border-color:#31708f}.list-group-item-warning{color:#8a6d3b;background-color:#fcf8e3}a.list-group-item-warning{color:#8a6d3b}a.list-group-item-warning .list-group-item-heading{color:inherit}a.list-group-item-warning:hover,a.list-group-item-warning:focus{color:#8a6d3b;background-color:#faf2cc}a.list-group-item-warning.active,a.list-group-item-warning.active:hover,a.list-group-item-warning.active:focus{color:#fff;background-color:#8a6d3b;border-color:#8a6d3b}.list-group-item-danger{color:#a94442;background-color:#f2dede}a.list-group-item-danger{color:#a94442}a.list-group-item-danger .list-group-item-heading{color:inherit}a.list-group-item-danger:hover,a.list-group-item-danger:focus{color:#a94442;background-color:#ebcccc}a.list-group-item-danger.active,a.list-group-item-danger.active:hover,a.list-group-item-danger.active:focus{color:#fff;background-color:#a94442;border-color:#a94442}.list-group-item-heading{margin-top:0;margin-bottom:5px}.list-group-item-text{margin-bottom:0;line-height:1.3}.panel{margin-bottom:20px;background-color:#fff;border:1px solid transparent;border-radius:4px;-webkit-box-shadow:0 1px 1px rgba(0,0,0,.05);box-shadow:0 1px 1px rgba(0,0,0,.05)}.panel-body{padding:15px}.panel-heading{padding:10px 15px;border-bottom:1px solid transparent;border-top-left-radius:3px;border-top-right-radius:3px}.panel-heading>.dropdown .dropdown-toggle{color:inherit}.panel-title{margin-top:0;margin-bottom:0;font-size:16px;color:inherit}.panel-title>a{color:inherit}.panel-footer{padding:10px 15px;background-color:#f5f5f5;border-top:1px solid #ddd;border-bottom-right-radius:3px;border-bottom-left-radius:3px}.panel>.list-group{margin-bottom:0}.panel>.list-group .list-group-item{border-width:1px 0;border-radius:0}.panel>.list-group:first-child .list-group-item:first-child{border-top:0;border-top-left-radius:3px;border-top-right-radius:3px}.panel>.list-group:last-child .list-group-item:last-child{border-bottom:0;border-bottom-right-radius:3px;border-bottom-left-radius:3px}.panel-heading+.list-group .list-group-item:first-child{border-top-width:0}.list-group+.panel-footer{border-top-width:0}.panel>.table,.panel>.table-responsive>.table,.panel>.panel-collapse>.table{margin-bottom:0}.panel>.table:first-child,.panel>.table-responsive:first-child>.table:first-child{border-top-left-radius:3px;border-top-right-radius:3px}.panel>.table:first-child>thead:first-child>tr:first-child td:first-child,.panel>.table-responsive:first-child>.table:first-child>thead:first-child>tr:first-child td:first-child,.panel>.table:first-child>tbody:first-child>tr:first-child td:first-child,.panel>.table-responsive:first-child>.table:first-child>tbody:first-child>tr:first-child td:first-child,.panel>.table:first-child>thead:first-child>tr:first-child th:first-child,.panel>.table-responsive:first-child>.table:first-child>thead:first-child>tr:first-child th:first-child,.panel>.table:first-child>tbody:first-child>tr:first-child th:first-child,.panel>.table-responsive:first-child>.table:first-child>tbody:first-child>tr:first-child th:first-child{border-top-left-radius:3px}.panel>.table:first-child>thead:first-child>tr:first-child td:last-child,.panel>.table-responsive:first-child>.table:first-child>thead:first-child>tr:first-child td:last-child,.panel>.table:first-child>tbody:first-child>tr:first-child td:last-child,.panel>.table-responsive:first-child>.table:first-child>tbody:first-child>tr:first-child td:last-child,.panel>.table:first-child>thead:first-child>tr:first-child th:last-child,.panel>.table-responsive:first-child>.table:first-child>thead:first-child>tr:first-child th:last-child,.panel>.table:first-child>tbody:first-child>tr:first-child th:last-child,.panel>.table-responsive:first-child>.table:first-child>tbody:first-child>tr:first-child th:last-child{border-top-right-radius:3px}.panel>.table:last-child,.panel>.table-responsive:last-child>.table:last-child{border-bottom-right-radius:3px;border-bottom-left-radius:3px}.panel>.table:last-child>tbody:last-child>tr:last-child td:first-child,.panel>.table-responsive:last-child>.table:last-child>tbody:last-child>tr:last-child td:first-child,.panel>.table:last-child>tfoot:last-child>tr:last-child td:first-child,.panel>.table-responsive:last-child>.table:last-child>tfoot:last-child>tr:last-child td:first-child,.panel>.table:last-child>tbody:last-child>tr:last-child th:first-child,.panel>.table-responsive:last-child>.table:last-child>tbody:last-child>tr:last-child th:first-child,.panel>.table:last-child>tfoot:last-child>tr:last-child th:first-child,.panel>.table-responsive:last-child>.table:last-child>tfoot:last-child>tr:last-child th:first-child{border-bottom-left-radius:3px}.panel>.table:last-child>tbody:last-child>tr:last-child td:last-child,.panel>.table-responsive:last-child>.table:last-child>tbody:last-child>tr:last-child td:last-child,.panel>.table:last-child>tfoot:last-child>tr:last-child td:last-child,.panel>.table-responsive:last-child>.table:last-child>tfoot:last-child>tr:last-child td:last-child,.panel>.table:last-child>tbody:last-child>tr:last-child th:last-child,.panel>.table-responsive:last-child>.table:last-child>tbody:last-child>tr:last-child th:last-child,.panel>.table:last-child>tfoot:last-child>tr:last-child th:last-child,.panel>.table-responsive:last-child>.table:last-child>tfoot:last-child>tr:last-child th:last-child{border-bottom-right-radius:3px}.panel>.panel-body+.table,.panel>.panel-body+.table-responsive{border-top:1px solid #ddd}.panel>.table>tbody:first-child>tr:first-child th,.panel>.table>tbody:first-child>tr:first-child td{border-top:0}.panel>.table-bordered,.panel>.table-responsive>.table-bordered{border:0}.panel>.table-bordered>thead>tr>th:first-child,.panel>.table-responsive>.table-bordered>thead>tr>th:first-child,.panel>.table-bordered>tbody>tr>th:first-child,.panel>.table-responsive>.table-bordered>tbody>tr>th:first-child,.panel>.table-bordered>tfoot>tr>th:first-child,.panel>.table-responsive>.table-bordered>tfoot>tr>th:first-child,.panel>.table-bordered>thead>tr>td:first-child,.panel>.table-responsive>.table-bordered>thead>tr>td:first-child,.panel>.table-bordered>tbody>tr>td:first-child,.panel>.table-responsive>.table-bordered>tbody>tr>td:first-child,.panel>.table-bordered>tfoot>tr>td:first-child,.panel>.table-responsive>.table-bordered>tfoot>tr>td:first-child{border-left:0}.panel>.table-bordered>thead>tr>th:last-child,.panel>.table-responsive>.table-bordered>thead>tr>th:last-child,.panel>.table-bordered>tbody>tr>th:last-child,.panel>.table-responsive>.table-bordered>tbody>tr>th:last-child,.panel>.table-bordered>tfoot>tr>th:last-child,.panel>.table-responsive>.table-bordered>tfoot>tr>th:last-child,.panel>.table-bordered>thead>tr>td:last-child,.panel>.table-responsive>.table-bordered>thead>tr>td:last-child,.panel>.table-bordered>tbody>tr>td:last-child,.panel>.table-responsive>.table-bordered>tbody>tr>td:last-child,.panel>.table-bordered>tfoot>tr>td:last-child,.panel>.table-responsive>.table-bordered>tfoot>tr>td:last-child{border-right:0}.panel>.table-bordered>thead>tr:first-child>td,.panel>.table-responsive>.table-bordered>thead>tr:first-child>td,.panel>.table-bordered>tbody>tr:first-child>td,.panel>.table-responsive>.table-bordered>tbody>tr:first-child>td,.panel>.table-bordered>thead>tr:first-child>th,.panel>.table-responsive>.table-bordered>thead>tr:first-child>th,.panel>.table-bordered>tbody>tr:first-child>th,.panel>.table-responsive>.table-bordered>tbody>tr:first-child>th{border-bottom:0}.panel>.table-bordered>tbody>tr:last-child>td,.panel>.table-responsive>.table-bordered>tbody>tr:last-child>td,.panel>.table-bordered>tfoot>tr:last-child>td,.panel>.table-responsive>.table-bordered>tfoot>tr:last-child>td,.panel>.table-bordered>tbody>tr:last-child>th,.panel>.table-responsive>.table-bordered>tbody>tr:last-child>th,.panel>.table-bordered>tfoot>tr:last-child>th,.panel>.table-responsive>.table-bordered>tfoot>tr:last-child>th{border-bottom:0}.panel>.table-responsive{margin-bottom:0;border:0}.panel-group{margin-bottom:20px}.panel-group .panel{margin-bottom:0;border-radius:4px}.panel-group .panel+.panel{margin-top:5px}.panel-group .panel-heading{border-bottom:0}.panel-group .panel-heading+.panel-collapse>.panel-body{border-top:1px solid #ddd}.panel-group .panel-footer{border-top:0}.panel-group .panel-footer+.panel-collapse .panel-body{border-bottom:1px solid #ddd}.panel-default{border-color:#ddd}.panel-default>.panel-heading{color:#333;background-color:#f5f5f5;border-color:#ddd}.panel-default>.panel-heading+.panel-collapse>.panel-body{border-top-color:#ddd}.panel-default>.panel-heading .badge{color:#f5f5f5;background-color:#333}.panel-default>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#ddd}.panel-primary{border-color:#428bca}.panel-primary>.panel-heading{color:#fff;background-color:#428bca;border-color:#428bca}.panel-primary>.panel-heading+.panel-collapse>.panel-body{border-top-color:#428bca}.panel-primary>.panel-heading .badge{color:#428bca;background-color:#fff}.panel-primary>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#428bca}.panel-success{border-color:#d6e9c6}.panel-success>.panel-heading{color:#3c763d;background-color:#dff0d8;border-color:#d6e9c6}.panel-success>.panel-heading+.panel-collapse>.panel-body{border-top-color:#d6e9c6}.panel-success>.panel-heading .badge{color:#dff0d8;background-color:#3c763d}.panel-success>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#d6e9c6}.panel-info{border-color:#bce8f1}.panel-info>.panel-heading{color:#31708f;background-color:#d9edf7;border-color:#bce8f1}.panel-info>.panel-heading+.panel-collapse>.panel-body{border-top-color:#bce8f1}.panel-info>.panel-heading .badge{color:#d9edf7;background-color:#31708f}.panel-info>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#bce8f1}.panel-warning{border-color:#faebcc}.panel-warning>.panel-heading{color:#8a6d3b;background-color:#fcf8e3;border-color:#faebcc}.panel-warning>.panel-heading+.panel-collapse>.panel-body{border-top-color:#faebcc}.panel-warning>.panel-heading .badge{color:#fcf8e3;background-color:#8a6d3b}.panel-warning>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#faebcc}.panel-danger{border-color:#ebccd1}.panel-danger>.panel-heading{color:#a94442;background-color:#f2dede;border-color:#ebccd1}.panel-danger>.panel-heading+.panel-collapse>.panel-body{border-top-color:#ebccd1}.panel-danger>.panel-heading .badge{color:#f2dede;background-color:#a94442}.panel-danger>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#ebccd1}.embed-responsive{position:relative;display:block;height:0;padding:0;overflow:hidden}.embed-responsive .embed-responsive-item,.embed-responsive iframe,.embed-responsive embed,.embed-responsive object{position:absolute;top:0;bottom:0;left:0;width:100%;height:100%;border:0}.embed-responsive.embed-responsive-16by9{padding-bottom:56.25%}.embed-responsive.embed-responsive-4by3{padding-bottom:75%}.well{min-height:20px;padding:19px;margin-bottom:20px;background-color:#f5f5f5;border:1px solid #e3e3e3;border-radius:4px;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,.05);box-shadow:inset 0 1px 1px rgba(0,0,0,.05)}.well blockquote{border-color:#ddd;border-color:rgba(0,0,0,.15)}.well-lg{padding:24px;border-radius:6px}.well-sm{padding:9px;border-radius:3px}.close{float:right;font-size:21px;font-weight:700;line-height:1;color:#000;text-shadow:0 1px 0 #fff;filter:alpha(opacity=20);opacity:.2}.close:hover,.close:focus{color:#000;text-decoration:none;cursor:pointer;filter:alpha(opacity=50);opacity:.5}button.close{-webkit-appearance:none;padding:0;cursor:pointer;background:0 0;border:0}.modal-open{overflow:hidden}.modal{position:fixed;top:0;right:0;bottom:0;left:0;z-index:1050;display:none;overflow:hidden;-webkit-overflow-scrolling:touch;outline:0}.modal.fade .modal-dialog{-webkit-transition:-webkit-transform .3s ease-out;-o-transition:-o-transform .3s ease-out;transition:transform .3s ease-out;-webkit-transform:translate3d(0,-25%,0);-o-transform:translate3d(0,-25%,0);transform:translate3d(0,-25%,0)}.modal.in .modal-dialog{-webkit-transform:translate3d(0,0,0);-o-transform:translate3d(0,0,0);transform:translate3d(0,0,0)}.modal-open .modal{overflow-x:hidden;overflow-y:auto}.modal-dialog{position:relative;width:auto;margin:10px}.modal-content{position:relative;background-color:#fff;-webkit-background-clip:padding-box;background-clip:padding-box;border:1px solid #999;border:1px solid rgba(0,0,0,.2);border-radius:6px;outline:0;-webkit-box-shadow:0 3px 9px rgba(0,0,0,.5);box-shadow:0 3px 9px rgba(0,0,0,.5)}.modal-backdrop{position:fixed;top:0;right:0;bottom:0;left:0;z-index:1040;background-color:#000}.modal-backdrop.fade{filter:alpha(opacity=0);opacity:0}.modal-backdrop.in{filter:alpha(opacity=50);opacity:.5}.modal-header{min-height:16.43px;padding:15px;border-bottom:1px solid #e5e5e5}.modal-header .close{margin-top:-2px}.modal-title{margin:0;line-height:1.42857143}.modal-body{position:relative;padding:15px}.modal-footer{padding:15px;text-align:right;border-top:1px solid #e5e5e5}.modal-footer .btn+.btn{margin-bottom:0;margin-left:5px}.modal-footer .btn-group .btn+.btn{margin-left:-1px}.modal-footer .btn-block+.btn-block{margin-left:0}.modal-scrollbar-measure{position:absolute;top:-9999px;width:50px;height:50px;overflow:scroll}@media (min-width:768px){.modal-dialog{width:600px;margin:30px auto}.modal-content{-webkit-box-shadow:0 5px 15px rgba(0,0,0,.5);box-shadow:0 5px 15px rgba(0,0,0,.5)}.modal-sm{width:300px}}@media (min-width:992px){.modal-lg{width:900px}}.tooltip{position:absolute;z-index:1070;display:block;font-size:12px;line-height:1.4;visibility:visible;filter:alpha(opacity=0);opacity:0}.tooltip.in{filter:alpha(opacity=90);opacity:.9}.tooltip.top{padding:5px 0;margin-top:-3px}.tooltip.right{padding:0 5px;margin-left:3px}.tooltip.bottom{padding:5px 0;margin-top:3px}.tooltip.left{padding:0 5px;margin-left:-3px}.tooltip-inner{max-width:200px;padding:3px 8px;color:#fff;text-align:center;text-decoration:none;background-color:#000;border-radius:4px}.tooltip-arrow{position:absolute;width:0;height:0;border-color:transparent;border-style:solid}.tooltip.top .tooltip-arrow{bottom:0;left:50%;margin-left:-5px;border-width:5px 5px 0;border-top-color:#000}.tooltip.top-left .tooltip-arrow{bottom:0;left:5px;border-width:5px 5px 0;border-top-color:#000}.tooltip.top-right .tooltip-arrow{right:5px;bottom:0;border-width:5px 5px 0;border-top-color:#000}.tooltip.right .tooltip-arrow{top:50%;left:0;margin-top:-5px;border-width:5px 5px 5px 0;border-right-color:#000}.tooltip.left .tooltip-arrow{top:50%;right:0;margin-top:-5px;border-width:5px 0 5px 5px;border-left-color:#000}.tooltip.bottom .tooltip-arrow{top:0;left:50%;margin-left:-5px;border-width:0 5px 5px;border-bottom-color:#000}.tooltip.bottom-left .tooltip-arrow{top:0;left:5px;border-width:0 5px 5px;border-bottom-color:#000}.tooltip.bottom-right .tooltip-arrow{top:0;right:5px;border-width:0 5px 5px;border-bottom-color:#000}.popover{position:absolute;top:0;left:0;z-index:1060;display:none;max-width:276px;padding:1px;text-align:left;white-space:normal;background-color:#fff;-webkit-background-clip:padding-box;background-clip:padding-box;border:1px solid #ccc;border:1px solid rgba(0,0,0,.2);border-radius:6px;-webkit-box-shadow:0 5px 10px rgba(0,0,0,.2);box-shadow:0 5px 10px rgba(0,0,0,.2)}.popover.top{margin-top:-10px}.popover.right{margin-left:10px}.popover.bottom{margin-top:10px}.popover.left{margin-left:-10px}.popover-title{padding:8px 14px;margin:0;font-size:14px;font-weight:400;line-height:18px;background-color:#f7f7f7;border-bottom:1px solid #ebebeb;border-radius:5px 5px 0 0}.popover-content{padding:9px 14px}.popover>.arrow,.popover>.arrow:after{position:absolute;display:block;width:0;height:0;border-color:transparent;border-style:solid}.popover>.arrow{border-width:11px}.popover>.arrow:after{content:"";border-width:10px}.popover.top>.arrow{bottom:-11px;left:50%;margin-left:-11px;border-top-color:#999;border-top-color:rgba(0,0,0,.25);border-bottom-width:0}.popover.top>.arrow:after{bottom:1px;margin-left:-10px;content:" ";border-top-color:#fff;border-bottom-width:0}.popover.right>.arrow{top:50%;left:-11px;margin-top:-11px;border-right-color:#999;border-right-color:rgba(0,0,0,.25);border-left-width:0}.popover.right>.arrow:after{bottom:-10px;left:1px;content:" ";border-right-color:#fff;border-left-width:0}.popover.bottom>.arrow{top:-11px;left:50%;margin-left:-11px;border-top-width:0;border-bottom-color:#999;border-bottom-color:rgba(0,0,0,.25)}.popover.bottom>.arrow:after{top:1px;margin-left:-10px;content:" ";border-top-width:0;border-bottom-color:#fff}.popover.left>.arrow{top:50%;right:-11px;margin-top:-11px;border-right-width:0;border-left-color:#999;border-left-color:rgba(0,0,0,.25)}.popover.left>.arrow:after{right:1px;bottom:-10px;content:" ";border-right-width:0;border-left-color:#fff}.carousel{position:relative}.carousel-inner{position:relative;width:100%;overflow:hidden}.carousel-inner>.item{position:relative;display:none;-webkit-transition:.6s ease-in-out left;-o-transition:.6s ease-in-out left;transition:.6s ease-in-out left}.carousel-inner>.item>img,.carousel-inner>.item>a>img{line-height:1}.carousel-inner>.active,.carousel-inner>.next,.carousel-inner>.prev{display:block}.carousel-inner>.active{left:0}.carousel-inner>.next,.carousel-inner>.prev{position:absolute;top:0;width:100%}.carousel-inner>.next{left:100%}.carousel-inner>.prev{left:-100%}.carousel-inner>.next.left,.carousel-inner>.prev.right{left:0}.carousel-inner>.active.left{left:-100%}.carousel-inner>.active.right{left:100%}.carousel-control{position:absolute;top:0;bottom:0;left:0;width:15%;font-size:20px;color:#fff;text-align:center;text-shadow:0 1px 2px rgba(0,0,0,.6);filter:alpha(opacity=50);opacity:.5}.carousel-control.left{background-image:-webkit-linear-gradient(left,rgba(0,0,0,.5) 0,rgba(0,0,0,.0001) 100%);background-image:-o-linear-gradient(left,rgba(0,0,0,.5) 0,rgba(0,0,0,.0001) 100%);background-image:-webkit-gradient(linear,left top,right top,from(rgba(0,0,0,.5)),to(rgba(0,0,0,.0001)));background-image:linear-gradient(to right,rgba(0,0,0,.5) 0,rgba(0,0,0,.0001) 100%);filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#80000000', endColorstr='#00000000', GradientType=1);background-repeat:repeat-x}.carousel-control.right{right:0;left:auto;background-image:-webkit-linear-gradient(left,rgba(0,0,0,.0001) 0,rgba(0,0,0,.5) 100%);background-image:-o-linear-gradient(left,rgba(0,0,0,.0001) 0,rgba(0,0,0,.5) 100%);background-image:-webkit-gradient(linear,left top,right top,from(rgba(0,0,0,.0001)),to(rgba(0,0,0,.5)));background-image:linear-gradient(to right,rgba(0,0,0,.0001) 0,rgba(0,0,0,.5) 100%);filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#00000000', endColorstr='#80000000', GradientType=1);background-repeat:repeat-x}.carousel-control:hover,.carousel-control:focus{color:#fff;text-decoration:none;filter:alpha(opacity=90);outline:0;opacity:.9}.carousel-control .icon-prev,.carousel-control .icon-next,.carousel-control .glyphicon-chevron-left,.carousel-control .glyphicon-chevron-right{position:absolute;top:50%;z-index:5;display:inline-block}.carousel-control .icon-prev,.carousel-control .glyphicon-chevron-left{left:50%;margin-left:-10px}.carousel-control .icon-next,.carousel-control .glyphicon-chevron-right{right:50%;margin-right:-10px}.carousel-control .icon-prev,.carousel-control .icon-next{width:20px;height:20px;margin-top:-10px;font-family:serif}.carousel-control .icon-prev:before{content:'\2039'}.carousel-control .icon-next:before{content:'\203a'}.carousel-indicators{position:absolute;bottom:10px;left:50%;z-index:15;width:60%;padding-left:0;margin-left:-30%;text-align:center;list-style:none}.carousel-indicators li{display:inline-block;width:10px;height:10px;margin:1px;text-indent:-999px;cursor:pointer;background-color:#000 \9;background-color:rgba(0,0,0,0);border:1px solid #fff;border-radius:10px}.carousel-indicators .active{width:12px;height:12px;margin:0;background-color:#fff}.carousel-caption{position:absolute;right:15%;bottom:20px;left:15%;z-index:10;padding-top:20px;padding-bottom:20px;color:#fff;text-align:center;text-shadow:0 1px 2px rgba(0,0,0,.6)}.carousel-caption .btn{text-shadow:none}@media screen and (min-width:768px){.carousel-control .glyphicon-chevron-left,.carousel-control .glyphicon-chevron-right,.carousel-control .icon-prev,.carousel-control .icon-next{width:30px;height:30px;margin-top:-15px;font-size:30px}.carousel-control .glyphicon-chevron-left,.carousel-control .icon-prev{margin-left:-15px}.carousel-control .glyphicon-chevron-right,.carousel-control .icon-next{margin-right:-15px}.carousel-caption{right:20%;left:20%;padding-bottom:30px}.carousel-indicators{bottom:20px}}.clearfix:before,.clearfix:after,.dl-horizontal dd:before,.dl-horizontal dd:after,.container:before,.container:after,.container-fluid:before,.container-fluid:after,.row:before,.row:after,.form-horizontal .form-group:before,.form-horizontal .form-group:after,.btn-toolbar:before,.btn-toolbar:after,.btn-group-vertical>.btn-group:before,.btn-group-vertical>.btn-group:after,.nav:before,.nav:after,.navbar:before,.navbar:after,.navbar-header:before,.navbar-header:after,.navbar-collapse:before,.navbar-collapse:after,.pager:before,.pager:after,.panel-body:before,.panel-body:after,.modal-footer:before,.modal-footer:after{display:table;content:" "}.clearfix:after,.dl-horizontal dd:after,.container:after,.container-fluid:after,.row:after,.form-horizontal .form-group:after,.btn-toolbar:after,.btn-group-vertical>.btn-group:after,.nav:after,.navbar:after,.navbar-header:after,.navbar-collapse:after,.pager:after,.panel-body:after,.modal-footer:after{clear:both}.center-block{display:block;margin-right:auto;margin-left:auto}.pull-right{float:right!important}.pull-left{float:left!important}.hide{display:none!important}.show{display:block!important}.invisible{visibility:hidden}.text-hide{font:0/0 a;color:transparent;text-shadow:none;background-color:transparent;border:0}.hidden{display:none!important;visibility:hidden!important}.affix{position:fixed;-webkit-transform:translate3d(0,0,0);-o-transform:translate3d(0,0,0);transform:translate3d(0,0,0)}@-ms-viewport{width:device-width}.visible-xs,.visible-sm,.visible-md,.visible-lg{display:none!important}.visible-xs-block,.visible-xs-inline,.visible-xs-inline-block,.visible-sm-block,.visible-sm-inline,.visible-sm-inline-block,.visible-md-block,.visible-md-inline,.visible-md-inline-block,.visible-lg-block,.visible-lg-inline,.visible-lg-inline-block{display:none!important}@media (max-width:767px){.visible-xs{display:block!important}table.visible-xs{display:table}tr.visible-xs{display:table-row!important}th.visible-xs,td.visible-xs{display:table-cell!important}}@media (max-width:767px){.visible-xs-block{display:block!important}}@media (max-width:767px){.visible-xs-inline{display:inline!important}}@media (max-width:767px){.visible-xs-inline-block{display:inline-block!important}}@media (min-width:768px) and (max-width:991px){.visible-sm{display:block!important}table.visible-sm{display:table}tr.visible-sm{display:table-row!important}th.visible-sm,td.visible-sm{display:table-cell!important}}@media (min-width:768px) and (max-width:991px){.visible-sm-block{display:block!important}}@media (min-width:768px) and (max-width:991px){.visible-sm-inline{display:inline!important}}@media (min-width:768px) and (max-width:991px){.visible-sm-inline-block{display:inline-block!important}}@media (min-width:992px) and (max-width:1199px){.visible-md{display:block!important}table.visible-md{display:table}tr.visible-md{display:table-row!important}th.visible-md,td.visible-md{display:table-cell!important}}@media (min-width:992px) and (max-width:1199px){.visible-md-block{display:block!important}}@media (min-width:992px) and (max-width:1199px){.visible-md-inline{display:inline!important}}@media (min-width:992px) and (max-width:1199px){.visible-md-inline-block{display:inline-block!important}}@media (min-width:1200px){.visible-lg{display:block!important}table.visible-lg{display:table}tr.visible-lg{display:table-row!important}th.visible-lg,td.visible-lg{display:table-cell!important}}@media (min-width:1200px){.visible-lg-block{display:block!important}}@media (min-width:1200px){.visible-lg-inline{display:inline!important}}@media (min-width:1200px){.visible-lg-inline-block{display:inline-block!important}}@media (max-width:767px){.hidden-xs{display:none!important}}@media (min-width:768px) and (max-width:991px){.hidden-sm{display:none!important}}@media (min-width:992px) and (max-width:1199px){.hidden-md{display:none!important}}@media (min-width:1200px){.hidden-lg{display:none!important}}.visible-print{display:none!important}@media print{.visible-print{display:block!important}table.visible-print{display:table}tr.visible-print{display:table-row!important}th.visible-print,td.visible-print{display:table-cell!important}}.visible-print-block{display:none!important}@media print{.visible-print-block{display:block!important}}.visible-print-inline{display:none!important}@media print{.visible-print-inline{display:inline!important}}.visible-print-inline-block{display:none!important}@media print{.visible-print-inline-block{display:inline-block!important}}@media print{.hidden-print{display:none!important}} \ No newline at end of file diff --git a/_templates/openstackdocs/static/css/combined.css b/_templates/openstackdocs/static/css/combined.css deleted file mode 100644 index 36de8d3c6..000000000 --- a/_templates/openstackdocs/static/css/combined.css +++ /dev/null @@ -1,4682 +0,0 @@ -html { - overflow-y: scroll; } - -/* pad after a table. - * bug 1439918 */ -table { - margin-bottom: 10px; } - -table.docutils th { - padding: 2px; } - -table.docutils td { - padding: 2px; } - -table.docutils caption { - font-weight: bold; } - -hr { - height: 1px !important; } - -h3 { - margin-top: 10px; - margin-bottom: 10px; } - -a, a:visited { - color: #bc1518; - text-decoration: none; } - -a:hover { - text-decoration: underline; } - -ol.arabic ol { - list-style-type: lower-alpha; } - -ol.arabic ol ol { - list-style-type: upper-alpha; } - -/* @group Navigation */ -#navigation { - display: block; - background: url('../images/header-line.gif') repeat-x 0 bottom; - padding-bottom: 1px; } - -#navigation * { - padding: 0; - margin: 0; } - -#navigation ul { - display: block; - margin: 0 auto; } - -#navigation li { - display: block; - float: left; - margin-right: 20px; } - -#navigation li a { - display: block; - font-weight: normal; - text-decoration: none; - background-position: 50% 0; - padding: 20px 0 5px; - color: #353535; - font-size: 14px; } - -#navigation li a.current, #navigation li a.section { - border-bottom: 3px solid #cf2f19; - color: #cf2f19; } - -/* @group Auto-clearing */ -#navigation:after, #navigation ul:after, #header:after { - content: "."; - display: block; - height: 0; - clear: both; - visibility: hidden; } - -#navigation, #navigation ul, #header:after { - display: inline-block; } - -/* Hides from IE-mac \*/ -* html #navigation, * html #navigation ul { - height: 1%; } - -#navigation, #navigation ul, #header:after { - display: block; } - -/* End hide from IE-mac */ -/* @end */ -#logo a { - display: block; - margin-top: 8px; - text-indent: -1000em; - background: url('../images/open-stack-cloud-computing-logo-2.png') no-repeat left center; - height: 54px; - width: 177px; - margin-left: -10px; } - -#header { - margin-bottom: 0px; - margin-top: 20px; } - -/* @end */ -/* @group Tabs */ -.tabContentHidden { - display: none; } - -.tabTops { - border: 1px solid black; - border-bottom: none; } - -#subnav li { - list-style-type: none; - margin-bottom: 5px; - padding: 0; } - -#subnav ul { - padding-left: 0px; - margin-right: 0px; } - -#subnav ul.overviewNav li a { - display: block; - padding: 10px 20px 10px 42px; - text-decoration: none; - color: black; - background-color: #e9e9e9; - background-image: none; - text-align: right; - margin-right: 40px; } - -#subnav ul.overviewNav li a:hover { - background-color: #d6d6d6; - -webkit-transition: background-color 1s ease-out; } - -ul.subsectionNav li.current a { - background-color: #c4e0e9; - -webkit-transition: background-color 1s ease-out; } - -.subsectionNav a[href*="/essex/"] { - background-color: #E9E9E9 !important; } - -.subsectionNav a[href*="/start/"] { - background-color: #D5EFD4 !important; - margin-top: 30px; } - -.subsectionNav a[href*="/marketplace/training/"] { - margin-top: 30px; } - -.overviewNav li.active, .subsectionNav li.active { - background: url('../images/pointer-arrow.gif') no-repeat right center; } - -#subnav ul li { - text-align: right; } - -ul.subsectionNav li a { - display: block; - padding: 10px 20px 10px 42px; - text-decoration: none; - color: black; - background: #e2ecef none no-repeat 5px center; - margin-right: 40px; } - -ul.subsectionNav li a:hover { - background-color: #c4e0e9; - -webkit-transition: background-color 1s ease-out; } - -ul.tabs { - padding: 0 2px 0 0; - white-space: nowrap; - list-style-type: none; - display: block; - zoom: 1; - margin-right: 0px; - clear: both; - border-bottom: 1px solid #d8d8d8; - background-color: #ececec; } - -.tabSet { - margin: auto; - background-color: #f5f5f5; - -webkit-border-radius: 3px; - border: 1px solid #d8d8d8; - border-top: 1px solid #bcbcbc; } - -#home .tabSet { - margin-top: 45px; } - -.featureHeader { - margin-left: 20px; - margin-top: 20px; } - -.tabs li { - cursor: pointer; - display: inline; - margin-right: -3px; - padding: 0px; } - -.tabs li a { - margin: 0px; - display: inline-block; - text-align: left; - color: #41728d; - font-size: 13px; - font-family: 'PT Sans', serif; - padding: 6px 14px; - text-shadow: #fff 0px 1px 1px; - border-right: 1px solid #d8d8d8; - width: 160px; - text-align: center; } - -.tabs li a:hover { - background-color: #eee; - text-decoration: none; } - -.tabs li.active a { - cursor: default; - text-decoration: none; - position: relative; - color: black; - background-color: #f5f5f5; - border-bottom: 1px solid #f5f5f5; - margin-bottom: -1px; - border-top: 1px white solid; - font-weight: bold; } - -.tabs li#showcode a { - background: #6b90da; - padding-bottom: 6px; - font-weight: bold; - color: #fff; } - -/* @end */ -/* @group Buttons */ -a.button { - font-family: 'PT Sans', serif; - border: 1px solid #ccc; - padding: 3px 30px; - color: #525252; - text-decoration: none; - font-size: 14px; - line-height: 3em; - background: #ddd; - box-shadow: 1px 1px 2px rgba(0, 0, 0, 0.5); - -webkit-box-shadow: 1px 1px 2px rgba(0, 0, 0, 0.5); - -moz-box-shadow: 1px 1px 2px rgba(0, 0, 0, 0.5); - text-shadow: #fff 0px 1px 1px; - background: -webkit-gradient(linear, left top, left bottom, from(#eeeeee), to(#bebebe)); - filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#eeeeee', endColorstr='#bebebe'); } - -a.button:hover { - color: black; - -webkit-transition: color 1s ease-out; } - -a.button:active { - background: #ababab; - box-shadow: none; - -webkit-box-shadow: none; - -moz-box-shadow: none; - border-color: #ababab; - border-top-color: #636363; - background: -webkit-gradient(linear, left top, left bottom, from(#bebebe), to(#dddddd)); - -webkit-transition: none; - padding: 4px 29px 2px 31px !important; } - -/* @end */ -/* @group Rounded Buttons */ -.roundedButton, input.action { - font-family: 'PT Sans', serif; - border: 1px solid #e2e2e2; - padding: 4px 15px; - color: black !important; - text-decoration: none !important; - font-size: 12.5px; - line-height: 3em; - background: #FFFFFF; - /* old browsers */ - /* firefox */ - background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #FFFFFF), color-stop(50%, #F3F3F3), color-stop(100%, #EBEBEB)); - /* webkit */ - filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#FFFFFF', endColorstr='#EBEBEB',GradientType=0 ); - /* ie */ - box-shadow: 0px 1px 1px rgba(0, 0, 0, 0.5); - -webkit-box-shadow: 0px 1px 2px rgba(0, 0, 0, 0.2); - -moz-box-shadow: 0px 1px 2px rgba(0, 0, 0, 0.2); - text-shadow: #fff 0px 1px 1px; - border-radius: 3px; - -moz-border-radius: 3px; - -webkit-border-radius: 3px; - border-bottom-color: #a0a0a0; - border-right-color: #bababa; - border-left-color: #bababa; } - -.roundedButton:hover, input.action:hover { - color: black; - -webkit-transition: color 1s ease-out; - cursor: pointer; } - -a.roundedButton:active, input.action:active { - background: #ababab; - box-shadow: none; - -webkit-box-shadow: none; - -moz-box-shadow: none; - border-color: #ababab; - border-top-color: #636363; - background: -webkit-gradient(linear, left top, left bottom, from(#bebebe), to(#dddddd)); - -webkit-transition: none; - padding: 4px 15px; } - -input.action { - line-height: 1.2em !important; } - -/* @end */ -.subhead { - color: #cf2f19; - font-size: 16px; - border-bottom: 1px dotted; - padding-bottom: 5px; - border-color: #c5e2ea; - margin-bottom: 20px; } - -/* @group projects page */ -.projectsPage h1, .communityPage h1, #blog h1 { - color: #264d69; - font-size: 24px; } - -.projectsPage h2 { - color: #264d69; - font-size: 17px; } - -#subnav { - padding-top: 38px; } - -.note { - color: #33730a; - background: #e2f4dc url('../images/side-note-pointer.gif') no-repeat left center; } - -.note a { - color: #33730a; - text-decoration: underline; } - -/* BB: Removed because it looks ugly -.note p { - margin-left: 8px; - padding: 10px; - margin-bottom: 0px; - border-bottom: 1px solid #b5c8a8; } -*/ - -a#CitrixVideo { - display: block; - padding-top: 93px; - background: url('../images/citrix-video-thumbnail.jpg') no-repeat; - color: #aeaeae; - text-decoration: none; - margin-top: 3px; } - -h3.videoHeader { - color: #939393; - font-size: 14px; } - -a.downloadLink { - text-decoration: none; - color: white; - font-family: helvetica, arial; - font-weight: bold; - display: block; - width: 250px; - text-align: center; - position: relative; - padding: 3px; - margin-bottom: 5px; - margin-top: 5px; - /* BORDER RADIUS */ - border-radius: 5px; - background-color: #989996; - border: 2px solid white; } - -/* @end */ -#footer { - margin-top: 30px; } - -/* @group compute */ -.projectVitals { - border-top: 1px solid #c5e2ea; - padding-top: 10px; } - -.projectVitals h3 { - font-size: 16px; - color: #264d69; } - -#status { - padding: 12px; - color: #1d6006; - background-color: #e2f4dc; - border: 1px solid #b5c8a8; - margin-bottom: 10px; - height: 9em; } - -#status strong { - font-size: 120%; } - -#availability { - line-height: 1.4em; - padding: 12px; - color: #747474; - background-color: #f6f8f8; - border: 1px solid #d4d5d5; - margin-bottom: 10px; - height: 9em; } - -.projectVitals h4 { - font-size: 14px; - color: #797979; - margin-bottom: 4px; } - -#status p, #availability p { - margin: 0px; } - -#parallax { - background: #2f3134; - position: relative; - overflow: hidden; - width: 60em; - height: 300px; - margin: 1.5em 0; } - -/* @group FAQ */ -.faqs .span-5 { - font-size: 14px; - color: #707070; - font-weight: bold; } - -.faqs hr { - padding: 0px; } - -.faqs div { - margin-bottom: 20px; } - -/* @end */ -/* @end */ -/* @group community page */ -.communityBox { - height: 213px; - background: #f8f8f8 url('../images/community-box-headers.png') no-repeat 0 0; } - -#userResources { - background-position: -200px 0; } - -#devCenter { - background-position: -400px 0; } - -.communityBox p, .communityBox h2 { - margin: 15px; } - -.communityBox, .communityBox a, .communityBox a.visited { - color: #6b6b6b; } - -.communityBox a { - text-decoration: underline; } - -.communityBox h2 { - color: black; - font-size: 17px; - margin-top: 60px; } - -.participants h2, .communityResources h2 { - font-size: 16px; - color: #264d69; - margin-top: 30px; - padding-top: 10px; - border-top: 1px dotted #c5e2ea; } - -#designSummit h2 { - text-indent: -1000px; - height: 222px; - margin-top: -9px; - margin-bottom: 10px; - background: url('../images/openstack-design-summit-community.jpg') no-repeat 0 0; } - -#designSummit { - color: #6b6b6b; } - -#designSummit strong { - color: black; - font-weight: normal; } - -/* @end */ -/* @group blog */ -#blog h2 { - color: #5189a0; - font-size: 15px; - margin-bottom: 0px; } - -#blog h2 a { - background-color: #eaeaea; - text-align: center; - padding: 1px; - padding-left: 7px; - padding-right: 7px; - -moz-border-radius: 3px; - -webkit-border-radius: 3px; - color: #757575; - font-size: 0.7em; - text-decoration: none; } - -div.byline { - border-bottom: 1px dotted #c5e2ea; - border-top: 1px dotted #c5e2ea; - margin-bottom: 10px; - padding: 2px 0; } - -div.byline p { - margin: 0px; } - -div.byline .postDate { - text-align: right; } - -div.byline p.name a, div.byline p.name a:visited { - color: #cf2f19; - text-decoration: none; } - -div.socialMedia { - background-color: #eef3f5; - margin-bottom: 20px; } - -div.socialMedia div { - padding: 10px; } - -div.socialMedia h4 { - margin-bottom: 2px; } - -div.socialMedia p { - margin-bottom: 0px; } - -div.socialMedia div.twitter { - border-bottom: 1px dotted #c5e2ea; } - -#blog h3 { - margin-bottom: 5px; - font-size: 12px; } - -/* @end */ -/* @group Brand */ -div.termsBox { - border: 1px solid #c6e2ea; - padding: 10px; - height: 300px; - overflow: scroll; - margin-bottom: 10px; } - -.termsBox h3, #openstack-trademark-policy h3 { - font-size: 100%; - font-weight: bold; } - -.termsBox a { - color: inherit; - text-decoration: underline; } - -/* @end */ -/* @group quotes */ -ul#quotes { - margin-left: 0px; - padding-left: 0px; - margin-top: 10px; } - -ul#quotes li { - list-style-type: none; } - -ul#quotes li p { - line-height: 1.4em; } - -ul#quotes p { - font-size: 16px; - font-family: 'PT Sans', serif; - margin-bottom: 0px; - color: black; - line-height: 1.2em; - padding: 10px; - padding-bottom: 0px; } - -ul#quotes p.name { - margin-top: 10px; - font-size: 14px; - text-transform: uppercase; - color: #9b9b9b; - text-indent: 0px; } - -ul#quotes p.name strong { - font-weight: normal; - color: #494949; } - -/* @end */ -.tooltip { - background: black; - background: rgba(0, 0, 0, 0.8); - padding: 1px 8px; - color: white; - border-radius: 4px; - -moz-border-radius: 4px; - -webkit-border-radius: 4px; } - -a.Datasheet { - padding-top: 110px; - display: block; - background: url('../images/openstack-product-pdf.jpg') no-repeat center top; - margin-left: 20px; - margin-top: 30px; } - -a.Datasheet:hover { - text-decoration: none; - color: #bc1518; } - -a#DemoVideo { - display: block; - padding-top: 103px; - margin-left: 18px; - background: url('../images/demo-video-thumbnail.jpg') no-repeat; - text-decoration: none; - margin-top: 50px; } - -/* @group Tables */ -.tabContent table { - margin: 20px; - width: 670px; } - -.tabContent table td { - border-bottom: 1px solid #d8d8d8; - vertical-align: top; - padding: 10px 10px 20px 0; } - -.tabContent table td p { - margin: 0px; } - -.tabContent table tr:last-child td { - border-bottom: none; } - -.tabContent table th { - font-family: 'PT Sans', serif; - font-style: normal; - font-weight: normal; - font-size: 18px; - letter-spacing: -0.076em; - line-height: 1em; - color: #264d69; - padding-left: 0px; } - -.tabContent table a:active, .tabContent table a:visited, .tabContent table a { - color: inherit; - text-decoration: underline; } - -p.fnote { - margin-left: 20px; } - -/* @end */ -h2.user-story-quote { - line-height: 1.5em; - color: grey !important; } - -.user-story-quote-author { - text-transform: uppercase; } - -ul.user-project-list { - margin: 0px; - padding: 0px; - overflow: hidden; - margin-bottom: 20px; } - -ul.user-project-list li { - display: block; - margin-right: 5px; - background-color: #e2f1f5; - border: 1px solid #89c6d6; - -webkit-border-radius: 3px; - padding: 2px 8px; - margin-bottom: 5px; - color: #1a4b6b; - font-size: 95%; - width: 170px; - float: left; } - -#footer ul { - margin: 10px 0px 20px; - padding: 0px; - list-style: none; } - -#footer a, #footer a:visited, #footer a:active { - color: black; } - -#footer h3 { - color: #de0000; - font: 130% 'PT Sans', serif; } - -#footer textarea { - width: 260px; - height: 60px; - background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #EBEBEB), color-stop(5%, #FFFFFF)); - /* webkit */ } - -#footer form { - margin-top: 8px; - margin-bottom: 20px; } - -.user-links li { - padding-left: 20px; - background: url('../images/link.png') no-repeat left center; - margin-left: -20px; - list-style: none; } - -.user-objectives { - background-color: #ecedec; - padding: 20px; - margin-bottom: 15px; } - -.user-objectives p { - margin-bottom: 0px; } - -.user-name { - padding-top: 10px; } - -.user-photo img { - border: 5px solid white; - -webkit-box-shadow: 3px 2px 2px rgba(0, 0, 0, 0.3); } - -.siteMessage { - -webkit-border-radius: 4px; - border: 1px solid; - margin-bottom: 10px; - margin-top: 20px; } - -.siteMessage p { - margin: 8px; } - -#InfoMessage { - color: black; - background-color: #DBEAEE; - border-color: #B5D8E2; - font-size: 120%; - padding: 10px; } - -#SuccessMessage { - color: #3E933A; - background-color: #E2F7D8; - border-color: #9FDE9C; } - -#ErrorMessage { - color: #DA1D1D; - background-color: #FFDFDF; - border-color: #FFBBBB; } - -p.message.bad { - color: #DA1D1D; - background-color: #FFDFDF; - border-color: #FFBBBB; - padding: 15px; - border: 1px solid #DA1D1D; } - -.topMessage { - background: #E4EEF1; - border-bottom: 1px solid white; - padding: 5px; - font-size: 1.3em; - color: #255E6E; - font-family: 'PT Sans', serif; - text-shadow: #fff 0px 1px 1px; - box-shadow: 1px 1px 1px 1px #ccc; } - -.topMessage p { - margin-bottom: 0px; } - -#header { - margin-top: 40px; } - -span.message { - font-weight: bold; - color: #CE332C; } - -.gsc-control-cse { - padding: 0px !important; } - -#gcse { - width: 80%; - height: 60px; } - -input.gsc-search-button, input.gsc-search-button:hover, input.gsc-search-button:focus { - background: #C43422 !important; - border: none !important; } - -table.gsc-search-box td { - padding: 0px !important; } - -.gsc-input-box { - border-color: #D3E9EF !important; } - -.gs-visibleUrl, .gs-visibleUrl-long { - color: #A5A5A5 !important; } - -.roundedButton-margin { - margin-left: 5px; } - -/*! - * Start Bootstrap - Landing Page Bootstrap Theme (http://startbootstrap.com) - * Code licensed under the Apache License v2.0. - * For details, see http://www.apache.org/licenses/LICENSE-2.0. - */ -body, html { - width: 100%; - height: 100%; } - -body, h1, h2, h3, h4, h5, h6 { - font-family: "Open Sans", Helvetica, Arial, sans-serif; - font-weight: 400; } - -h1 { - color: #2A4E68; - font-size: 34px; - font-weight: 300; - margin-bottom: 25px; - text-align: left; } - -h2 { - color: #2A4E68; - font-weight: 300; - margin-bottom: 25px; - text-align: left; } - -h3 { - color: #2A4E68; } - -h5 { - color: #DA422F; - margin-bottom: 0; } - -a, a:visited { - color: #30739C; } - -.lead { - font-size: 18px; - font-weight: 400; } - -/*Header Navigation*/ -.brand-wrapper { - margin: 10px 0; - padding-right: 20px; - float: left; - border-right: 1px solid #eee; - min-width: 135px; } - -a.navbar-brand { - background: url('../images/openstack-logo-full.svg') left no-repeat; - height: 35px; - width: 135px; } - -@media (min-width: 768px) and (max-width: 1025px) { - .brand-wrapper { - width: 75px; - min-width: 75px; - margin-top: 0; } - a.navbar-brand { - background: url('../images/openstack-logo-vert.svg') left no-repeat; - margin-left: 0px !important; - height: 54px; - width: 59px; } } - -@media (max-width: 767px) { - a.navbar-brand { - margin-left: 15px; } } - -.navbar-default { - border: none; - border-radius: 0px; - background: #fff; - margin-bottom: 0; - padding: 20px 0; } - -.navbar-default .container { - background-color: white; } - -@media (min-width: 768px) and (max-width: 1200px) { - .navbar-default .container { - width: 100%; } } - -ul.navbar-main { - display: none; - float: right; } - -@media (min-width: 768px) and (max-width: 1097px) { - ul.navbar-main { - display: block; } } - -@media (max-width: 767px) { - ul.navbar-main { - display: block; - margin-right: 30px; - width: 90%; } } - -.navbar-default ul.navbar-main > li > a { - color: #8a959e; - font-size: 12px; - font-weight: 400; - text-transform: uppercase; } - -@media (min-width: 768px) and (max-width: 1025px) { - ul.navbar-main { - margin-top: 1px; } - .navbar-default ul.navbar-main > li > a { - font-size: 11px; - padding: 15px 8px; } } - -.navbar-default .navbar-nav > .open > a, .navbar-default .navbar-nav > .open > a:hover, .navbar-default .navbar-nav > .open > a:focus { - background: #fff; } - -.navbar-nav > li > .dropdown-menu { - margin-top: 10px; - padding: 10px 0; - min-width: 230px; - border-top-left-radius: 4px; - border-top-right-radius: 4px; } - -.navbar-nav > li > .dropdown-menu:after, .navbar-nav > li > .dropdown-menu:before { - bottom: 100%; - left: 25%; - border: solid transparent; - content: " "; - height: 0; - width: 0; - position: absolute; - pointer-events: none; } - -.navbar-nav > li > .dropdown-menu:after { - border-color: rgba(255, 255, 255, 0); - border-bottom-color: #ffffff; - border-width: 15px; - margin-left: -15px; } - -.navbar-nav > li > .dropdown-menu:before { - border-color: rgba(170, 170, 170, 0); - border-bottom-color: #aaaaaa; - border-width: 16px; - margin-left: -16px; } - -@media (max-width: 767px) { - .navbar-nav > li > .dropdown-menu:after, .navbar-nav > li > .dropdown-menu:before { - display: none; } - .navbar-nav > li > .dropdown-menu:after { - display: none; } - .navbar-nav > li > .dropdown-menu:before { - display: none; } } - -i.fa-caret-right { - margin-left: 8px; } - -.navbar-nav > li > .dropdown-menu li a { - text-transform: uppercase; - padding: 13px 20px; - font-size: 12px; - color: #8a959e; } - -.navbar-nav > li > .dropdown-menu li a:hover { - color: #333; } - -.navbar-nav > li > .dropdown-menu li a:focus { - outline: none; } - -@media (max-width: 767px) { - .navbar-default ul.navbar-main > li > a i.fa-caret-down { - display: none; } } - -.navbar-default .navbar-toggle { - border: none; } - -.navbar-default .navbar-toggle:hover, .navbar-default .navbar-toggle:focus { - background: transparent; } - -.navbar-default .navbar-toggle .icon-bar { - background-color: #5A5A5A; - height: 3px; - border-radius: 3px; } - -.search-container { - position: relative; - display: none; - float: left; - width: 84%; } - -@media (min-width: 768px) and (max-width: 1200px) { - .search-container { - width: 80%; } } - -@media (max-width: 767px) { - .search-container, #gsc-iw-id1 { - display: none; } } - -.search-icon { - display: none; - padding: 17px 20px 16px; - float: left; - text-transform: uppercase; - color: #8a959e; - font-size: 12px; - font-weight: 400; } - -.search-icon:hover { - cursor: pointer; - color: #8a959e; } - -.search-icon i { - margin-right: 5px; - color: #8a959e; } - -@media (max-width: 767px) { - .search-icon { - display: none !important; } } - -.header-search-form, .gsc-search-box { - position: absolute; - z-index: 1000; - /*left: 10px;*/ - width: 100%; - -webkit-transition-property: width; - -webkit-transition-duration: 1s; - -webkit-transition-timing-function: linear; - /* Standard syntax */ - -webkit-transition-property: width; - transition-property: width; - -webkit-transition-duration: 1s; - transition-duration: 1s; - -webkit-transition-timing-function: linear; - transition-timing-function: linear; } - -@media (max-width: 767px) { - .header-search-form { - display: none; } - .gsc-search-box { - position: relative; - left: 0px; } } - -.gsc-input { - color: #30739C; - font-size: 12px; - text-transform: lowercase; - font-weight: 400; } - -.mobile-search-form, #gsc-iw-id2 { - display: none; - position: relative; - width: 100%; } - -@media (max-width: 767px) { - .mobile-search-form, #gsc-iw-id2 { - display: block; } } - -input#gsc-i-id2.gsc-input { - height: 30px !important; } - -table.gsc-search-box { - margin-bottom: 0; } - -.header-search, .gsc-input-box { - border: 2px solid #dae5ee !important; - border-radius: 4px; - height: 37px !important; - margin: 7px 0 0 0; - padding: 0 20px 0 10px; - background: #fff !important; - width: 100%; - -webkit-transition: width 4s; - transition: width 4s; - -webkit-border-horizontal-spacing: 0 !important; - -webkit-border-vertical-spacing: 0 !important; } - -.header-search contenteditable .gsc-input-box:hover, .gsc-input-box:focus, .gsc-search-box .gsc-input > input:focus, .gsc-input-box-focus { - box-shadow: none !important; } - -.header-search::-webkit-input-placeholder, .gsc-input-box::-webkit-input-placeholder, gcse:search::-webkit-input-placeholder { - color: #C0CDDB; - font-size: 12px; - text-transform: lowercase; - font-weight: 400; } - -.header-search:-moz-placeholder, .gsc-input-box:-moz-placeholder, gcse:search:-moz-placeholder { - /* Firefox 18- */ - color: #C0CDDB; - font-size: 12px; - text-transform: lowercase; - font-weight: 400; } - -.header-search::-moz-placeholder, .gsc-input-box::-moz-placeholder, gcse:search::-moz-placeholder { - /* Firefox 19+ */ - color: #C0CDDB; - font-size: 12px; - text-transform: lowercase; - font-weight: 400; } - -.header-search:-ms-input-placeholder, .gsc-input-box:-ms-input-placeholder, gcse:search:-ms-input-placeholder { - color: #C0CDDB; - font-size: 12px; - text-transform: lowercase; - font-weight: 400; } - -.header-search:focus, .gsc-input-box-focus { - border-radius: 4px; - outline: none; - border: 2px solid #30739C !important; - box-shadow: none; } - -.gsc-input-box table { - border-top: none; } - -td.gsc-search-button { - display: none; } - -.cse .gsc-control-cse, .gsc-control-cse { - border: 0 !important; } - -form.gsc-search-box { - margin-bottom: 0 !important; } - -td.gsib_b { - display: none; } - -#gcse { - height: auto; } - -@media (max-width: 767px) { - #gcse { - margin-left: 0; } } - -table#gs_id50.gstl_50 { - width: 100%; - padding: 0px; - height: 100%; } - -.close-search { - position: absolute; - top: 20px; - right: 5px; - color: #dae5ee; - z-index: 1001; - font-size: 16px; } - -.close-search:hover { - color: #30739C; - cursor: pointer; } - -@media (max-width: 767px) { - .close-search { - display: none !important; } } - -/*Google Search Modal*/ -.gsc-modal-background-image { - background-color: #333 !important; } - -.gsc-results-wrapper-overlay { - border-radius: 4px !important; } - -@media (max-width: 767px) { - .gsc-results-wrapper-overlay { - width: 90%; - left: 5%; } } - -a.gs-title { - color: #30739C !important; } - -.gsc-tabsArea { - border: 0 !important; } - -.gsc-tabHeader.gsc-tabhInactive { - border-color: #BFCCDA !important; - background-color: #BFCCDA !important; - color: white !important; - border-left: 0; - border-right: 1px solid white !important; - border-top: 0; - border-bottom: 0 !important; - padding: 0 30px; } - -.gsc-tabHeader.gsc-tabhInactive:hover { - color: #30739C !important; } - -.gsc-tabHeader.gsc-tabhActive { - border-color: #30739C !important; - border-bottom: 0 !important; - color: #30739C !important; - padding: 0 30px; } - -@media (max-width: 767px) { - .gsc-tabHeader.gsc-tabhInactive { - padding: 0 10px; } - .gsc-tabHeader.gsc-tabhActive { - padding: 0 10px; } } - -.gsc-tabHeader.gsc-tabhActive:focus, .gsc-tabHeader.gsc-tabhActive:active { - outline: none !important; } - -a.gs-title, a.gs-title b { - color: #30739C !important; } - -.gsc-table-result, .gsc-thumbnail-inside, .gsc-url-top { - padding: 0 !important; } - -.gsc-results .gsc-cursor-box .gsc-cursor-page { - color: #30739C !important; } - -.show { - display: block; } - -@media (max-width: 767px) { - .show { - display: none; } } - -/*End Header Navigation*/ -/*Hero*/ -.intro-header { - padding-top: 0px; - padding-bottom: 0; - text-align: center; - color: #f8f8f8; - background: url('../images/hero-bkgd1.jpg') no-repeat center center; - background-size: cover; - position: relative; } - -.intro-header h1 { - color: #f8f8f8; } - -.intro-message { - position: relative; - padding-top: 110px; - padding-bottom: 110px; } - -@media (max-width: 1199px) { - .intro-message { - padding-bottom: 50px; } } - -.intro-message > h1 { - margin: 0; - font-size: 3em; - font-weight: 300; - text-align: center; - font-family: "Open Sans", Helvetica, Arial, sans-serif; - width: 100%; } - -@media (max-width: 767px) { - .intro-message > h1 { - font-size: 3em; } } - -.intro-divider { - width: 400px; - border-top: 1px solid #f8f8f8; - border-bottom: 1px solid rgba(0, 0, 0, 0.2); } - -.intro-message > h3 { - text-shadow: none; - text-align: left; - font-weight: 300; - font-size: 24px; - margin-top: 10px; } - -.hero-credit { - position: absolute; - bottom: 30px; - right: 30px; - color: #fff; - opacity: 0.5; } - -.hero-credit:hover { - opacity: 1; } - -/*Hero Promo, add .featured to .intro-header*/ -.intro-header.featured { - text-align: center; - background: url('../images/summit-promo-bkgd1.jpg') no-repeat center center; - min-height: 420px; - background-size: cover; - position: relative; } - -.intro-header.featured .intro-message { - padding-bottom: 50px; } - -a.promo-btn { - color: #fff; - font-size: 24px; - font-weight: 300; - background: transparent; - border: 2px solid #fff; - border-radius: 4px; - padding: 20px 35px; - margin: 0 auto; - text-align: center; - min-width: 370px; - display: inline-block; } - -a.promo-btn:hover { - text-decoration: none; - background: rgba(255, 255, 255, 0.2); } - -a.promo-btn i.fa-chevron-right { - background: transparent; - border: 2px solid #fff; - border-radius: 100px; - padding: 0; - font-size: 14px; - margin-left: 10px; - width: 30px; - height: 30px; - line-height: 2.1; } - -p.promo-dates { - display: inline-block; - margin-top: 10px; - font-weight: 400; } - -/*End Hero*/ -/*Overview Section*/ -.overview-section { - padding: 80px 0; } - -@media (max-width: 767px) { - .overview-section { - padding-top: 40px; } } - -.overview-section h2 { - color: #2A4E68; - font-size: 34px; - font-weight: 300; - margin-bottom: 25px; } - -.overview-section p { - color: #888; - font-size: 16px; - font-weight: 300px; - line-height: 1.4; } - -.overview-section a { - color: #30739C; - text-decoration: underline; } - -.btn-wrapper { - float: left; - width: 100%; - text-align: center; } - -@media (max-width: 980px) { - .overview-left { - margin-bottom: 50px; } } - -a.overview-btn { - float: left; - background: #30739C; - color: #fff; - text-transform: uppercase; - border-radius: 4px; - padding: 15px 25px; - text-decoration: none; - margin-top: 5px; - margin-bottom: 5px; } - -a.overview-btn:hover { - background: #2A4E68; } - -a.overview-btn.left-btn { - border-top-right-radius: 0; - border-bottom-right-radius: 0; - border-right: 1px solid #3387C9; - margin-right: 0; } - -a.overview-btn.left-btn:hover { - border-right-color: #1B486B; } - -a.overview-btn.right-btn { - border-top-left-radius: 0; - border-bottom-left-radius: 0; - border-left: 1px solid #1B486B; - margin-left: 0; } - -.release-text { - display: block; - text-align: left; - color: #636568; - font-size: 13px; } - -.overview-section .img-responsive { - max-width: 550px; } - -.overview-right { - text-align: center; } - -.control-cloud-graphic { - max-width: 600px; - margin: 0 auto 15px; } - -a.demo-link { - font-size: 13px; - font-weight: 400; - text-decoration: none; - color: #34789A; - background: #F0F9FE; - padding: 10px 25px; - border-radius: 4px; } - -a.demo-link:hover { - color: #34789A; - background: #CDD9E2; } - -a.demo-link i { - margin-left: 5px; - font-size: 14px; } - -/*When Featured, Add Class .featured to .overview-section*/ -.overview-section.featured .overview-right { - background: #E8EEF5; - border-radius: 4px; - text-align: center; - padding: 20px; - margin-top: 50px; } - -@media (max-width: 1200px) { - .overview-section.featured .overview-right { - margin-top: 50px; } } - -.overview-section.featured .overview-right h3 { - color: #30739C; - text-align: center; } - -.overview-section.featured .overview-right p { - color: #333; - font-size: 13px; } - -.overview-section.featured .overview-right img.promo-graphic { - max-width: 350px; - margin: 20px auto; } - -/*End Overview Section*/ -/*Customers Section*/ -.customers-row { - padding: 80px 0; - text-align: center; - background: #edf2f7; } - -.customers-row h2 { - text-transform: capitalize; - margin-bottom: 0; - text-align: center; } - -.customer-logos-wrapper { - margin: 35px 0 25px; } - -.customer-logos-wrapper ul { - padding: 0; } - -li.customer-logos { - position: relative; - padding: 20px 1%; - width: 16%; - list-style: none; - display: inline-block; } - -@media (max-width: 767px) { - li.customer-logos { - position: relative; - padding: 20px 0; - width: 80%; - margin: 0 auto; - display: block; } } - -li.customer-logos img { - max-width: 100%; } - -.logo-hover { - background: #dee2e8; - border-radius: 3px; } - -.logo-hover:after { - content: ' '; - height: 0; - position: absolute; - width: 0; - border: 10px solid transparent; - border-top-color: #dee2e8; - top: 100%; - left: 50%; - margin-left: -10px; } - -.customers-description { - margin: 40px 0; - color: #2A4E68; - text-align: center; } - -.customers-description p { - padding: 20px 50px; - border-top: 1px solid #dee2e8; - border-bottom: 1px solid #dee2e8; - display: inline; } - -@media (max-width: 767px) { - .customers-description p { - display: block; } } - -.customers-action { - margin-top: 40px; - text-align: center; } - -a.customer-btn { - background: #2A4E68; - color: #fff; - text-transform: uppercase; - border-radius: 4px; - padding: 15px 25px; - text-decoration: none; - border-style: none; } - -a.customer-btn:hover { - background: #173D5B; - color: #fff; } - -/*When Featured, Add Class .featured to .customers-row*/ -.customers-row.featured .customer-logos-wrapper { - width: 50%; - max-width: 1000px; - margin: 40px 25% 0; - border-top: 1px solid #DDE3E8; - padding-top: 20px; } - -.customers-row.featured .customer-logos-wrapper hr { - color: #333; } - -.customers-row.featured .customer-logos img { - width: 90%; - max-width: 100px; } - -.customers-row.featured .customer-logos:hover { - background: none; } - -.customers-row.featured .customer-logos:hover:after { - display: none; } - -.customers-row.featured .customers-action { - margin-top: 0; } - -.customers-row.featured button.customer-btn { - background: none; - border-radius: 0; - padding: 0; - text-decoration: underline; - color: #2A4E68; - text-transform: capitalize; } - -.featured-description { - width: 85%; - margin: 40px auto; } - -@media (max-width: 767px) { - iframe { - width: 90%; } } - -/*End Customers Section*/ -/*Community Section*/ -.community-section { - padding: 75px 0; - background: url('../images/community-bkgd.jpg') no-repeat center center; - background-size: cover; - min-height: 350px; } - -.community-section.featured { - background: url('../images/community-bkgd2.jpg') no-repeat center center; - background-size: cover; } - -.community-graphic { - max-width: 650px; - margin: 0 auto; } - -@media (max-width: 1200px) { - .community-graphic { - margin-bottom: 20px; } } - -.community-section h2 { - color: #fff; } - -.community-section p { - color: #fff; } - -@media (max-width: 1200px) { - .community-section h2 { - text-align: center; } - .community-section p { - text-align: center; } } - -a.community-btn { - font-size: 16px; - font-weight: 400; - background: transparent; - border: 1px solid #fff; - border-radius: 3px; - margin-top: 10px; - padding: 8px 30px 8px 40px; - color: white; - float: left; } - -a.community-btn i { - margin-left: 10px; } - -a.community-btn:hover { - text-decoration: none; - background: rgba(255, 255, 255, 0.2); } - -/*When Featured, add .featured to .community-section*/ -.community-section.featured h3 { - color: #fff; } - -@media (max-width: 1200px) { - .community-section.featured h3 { - text-align: center; } } - -.designate-logo { - max-width: 302px; - margin: 50px 0 20px; } - -@media (max-width: 1200px) { - .designate-logo { - margin: 50px auto 20px; } } - -.default-community { - background-color: rgba(5, 54, 86, 0.7); - border-radius: 4px; - padding: 30px; - text-align: center; } - -@media (max-width: 1200px) { - .default-community { - margin-top: 50px; } } - -.default-community h2 { - margin-top: 0; } - -.community-graphic.small { - max-width: 450px; - margin: 20px auto; } - -a.featured-link { - display: block; - background: #DA422F; - padding: 10px 20px; - border-radius: 2px; - width: 80%; - text-decoration: none; - margin: 10px auto 0; - color: #fff; - font-weight: 600; } - -a.featured-link:hover { - text-decoration: none; - background: #831917; } - -/*End Community Section*/ -/*News and Events Section*/ -.news-section { - padding: 70px 0; } - -.news-section h2 a { - font-size: 14px; - color: #30739C; - font-weight: 400; - margin-left: 30px; } - -.news-section h2 a:hover { - color: #28709a; - text-decoration: none; } - -.event-ad, .news-ad { - width: 100%; - max-width: 560px; - margin-bottom: 20px; } - -.event-ad-lrg { - width: 100%; - height: 113px; - max-height: 113px; - max-width: 1140px; - margin-bottom: 20px; - background-image: url('../images/paris-summit-lrg.jpg'); - background-repeat: no-repeat; - background-size: 100% auto; - background-position: center center; } - -@media (max-width: 767px) { - .event-ad-lrg { - max-width: 766px; - background-image: url('../images/paris-summit-sm.jpg'); - background-repeat: no-repeat; - background-size: 100% auto; - background-position: center center; } } - -.news-section .news-wrapper ul { - margin: 30px 0; - padding-start: 0; - -webkit-padding-start: 0; } - -.news-section .news-wrapper ul li { - list-style: none; } - -.single-event { - float: left; - width: 100%; - padding: 15px 10px; - border-bottom: 1px solid #ebeff4; } - -.single-event:hover { - background: #edf2f7; } - -.single-event.last { - border-bottom: none; } - -.left-event { - float: left; - width: 25%; } - -@media (min-width: 768px) and (max-width: 981px) { - .left-event { - width: 25%; } } - -@media (max-width: 767px) { - .left-event { - width: 25%; } } - -.event-details { - float: left; - margin-left: 3%; - width: 62%; } - -@media (min-width: 768px) and (max-width: 981px) { - .event-details { - width: 72%; } } - -.right-event { - float: right; - width: 10%; } - -@media (min-width: 768px) and (max-width: 981px) { - .right-event { - display: none; } } - -.date, .news-type, .planet-type { - background: #fff; - border: 2px solid #DA422F; - border-radius: 4px; - padding: 5px 15px; - color: #DA422F; - font-size: 10px; - width: 100%; - text-align: center; - float: left; - margin-top: 5px; } - -.event-name, .news-title { - display: block; - font-size: 14px; - font-weight: 600; - color: #333; - width: 100%; - white-space: nowrap; - overflow: hidden; - text-overflow: ellipsis; } - -.location, .news-date { - display: block; - float: left; - font-style: italic; - color: #333; - font-weight: 300; } - -.right-arrow { - float: right; - background: #d9dfe5; - border-radius: 100px; - width: 30px; - height: 30px; - padding: 6px 10px; - color: #fff; - margin-right: 10px; - margin-top: 5px; - display: none; } - -.single-event:hover .right-arrow { - display: block; } - -.news-type { - border: 2px solid #2A4E68; - color: #2A4E68; } - -.planet-type { - border: 2px solid #68C8C3; - color: #68C8C3; } - -.see-more-bottom { - width: 100%; - float: left; - text-align: center; - margin-top: 40px; } - -.see-more-bottom a { - color: #2A4E68; - text-decoration: none; - padding: 5px 15px; - border-radius: 4px; - font-size: 12px; - font-weight: 400; - border: 2px solid #2A4E68; } - -.see-more-bottom a i { - margin-left: 10px; - font-size: 11px; } - -/*End News and Events Section*/ -/*Photo Row*/ -.photo-row-wrapper { - width: 100%; - color: #eee; - max-height: 240px; - margin-bottom: 10px; - overflow: hidden; - margin-top: 60px; } - -@media (max-width: 765px) { - .photo-row-wrapper { - display: none; } } - -.photo-container { - width: 4000px; - max-height: 240px; - margin-left: -30px; } - -.photo-container img { - margin: 0 10px 0 0; - max-width: 22%; - max-height: 240px; } - -/*End Photo Row*/ -/*Footer*/ -footer { - background: #333333; - padding: 70px 0; } - -.footer-links h3 { - color: #fff; - font-size: 14px; - font-weight: 400; } - -.footer-links ul { - margin-left: 0; - padding-start: 0; - padding: 0; - -webkit-padding-start: 0; } - -.footer-links ul li a { - color: #aaa; - font-size: 12px; - font-weight: 400; - list-style: none; - margin-left: 0; } - -.social-icons { - width: 40px; - min-height: 40px; - display: inline-block; - margin-right: 10px; } - -.footer-twitter { - background: url('../images/footer-twitter.png') no-repeat; } - -.footer-twitter:hover { - background: url('../images/footer-twitter-hover.png') no-repeat; } - -.footer-facebook { - background: url('../images/footer-facebook.png') no-repeat; } - -.footer-facebook:hover { - background: url('../images/footer-facebook-hover.png') no-repeat; } - -.footer-linkedin { - background: url('../images/footer-linkedin.png') no-repeat; } - -.footer-linkedin:hover { - background: url('../images/footer-linkedin-hover.png') no-repeat; } - -.footer-youtube { - background: url('../images/footer-youtube.png') no-repeat; } - -.footer-youtube:hover { - background: url('../images/footer-youtube-hover.png') no-repeat; } - -.newsletter-form { - margin: 10px 0 30px; - width: 100%; } - -.newsletter-form label { - color: #aaa; - font-size: 12px; - font-weight: 300; - display: block; } - -.newsletter-input { - display: inline-block; - background: transparent; - border: 2px solid #888; - border-radius: 4px; - color: #888; - font-size: 12px; - font-weight: 400; - padding: 10px 15px; - width: 70%; } - -@media (max-width: 767px) { - .newsletter-input { - width: 70%; } } - -.newsletter-input::-webkit-input-placeholder { - color: #888; - font-size: 12px; - font-weight: 400; - text-transform: uppercase; } - -.newsletter-input:-moz-placeholder { - /* Firefox 18- */ - color: #888; - font-size: 12px; - font-weight: 400; - text-transform: uppercase; } - -.newsletter-input::-moz-placeholder { - /* Firefox 19+ */ - color: #888; - font-size: 12px; - font-weight: 400; - text-transform: uppercase; } - -.newsletter-input:-ms-input-placeholder { - color: #888; - font-size: 12px; - font-weight: 400; - text-transform: uppercase; } - -.newsletter-input:focus { - outline: none; - border: 2px solid #666; } - -.newsletter-btn { - margin-left: 1%; - display: inline-block; - background: transparent; - border: 2px solid #30739C; - border-radius: 4px; - color: #30739C; - font-size: 12px; - font-weight: 400; - padding: 10px 15px; - text-transform: uppercase; - width: 27%; } - -@media (max-width: 767px) { - .newsletter-btn { - width: 18%; - margin-left: 2%; - padding: 10px; } } - -.newsletter-btn:hover { - border: 2px solid #888; - color: #999; } - -.fine-print { - margin-top: 20px; - color: #aaa; - font-size: 12px; } - -.fine-print a { - color: #aaa; - text-decoration: underline; } - -.fine-print a:hover { - color: #fff; } - -.footer-bottom { - background: #222; - padding: 15px 0; - text-align: center; - width: 100%; } - -.feedback-input { - display: inline-block; - background: #222; - border: 2px solid #444; - border-radius: 4px; - color: #777; - font-size: 12px; - font-weight: 400; - padding: 10px 20px; - width: 310px; } - -@media (max-width: 767px) { - .feedback-input { - width: 70%; } } - -.feedback-input::-webkit-input-placeholder { - color: #555; - font-size: 12px; - font-weight: 400; } - -.feedback-input:-moz-placeholder { - /* Firefox 18- */ - color: #555; - font-size: 12px; - font-weight: 400; } - -.feedback-input::-moz-placeholder { - /* Firefox 19+ */ - color: #555; - font-size: 12px; - font-weight: 400; } - -.feedback-input:-ms-input-placeholder { - color: #555; - font-size: 12px; - font-weight: 400; } - -.feedback-input:focus { - outline: none; - border: 2px solid #666; } - -.feedback-btn { - margin-left: 11px; - display: inline-block; - background: #222; - border: 2px solid #666; - border-radius: 4px; - color: #777; - font-size: 12px; - font-weight: 400; - padding: 10px 30px; } - -@media (max-width: 767px) { - .feedback-btn { - width: 18%; - margin-left: 2%; - padding: 10px; } } - -.feedback-btn:hover { - border: 2px solid #888; - color: #999; } - -/*End Footer*/ -/* Line below navigation */ -.navbar-default { - border-bottom: 1px solid #ddd; } - -#home.navbar-default { - border-bottom: none; } - -/*End General Inner Page Styles*/ -/*Events Page*/ -.eventsBanner { - height: 150px; - padding: 20px; } - -.eventsPhotoCaption { - background: rgba(0, 0, 0, 0.3); - border-radius: 4px; - padding: 10px; - color: white; } - -.news-section.full { - padding: 20px 0; } - -.eventTitleArea { - text-align: center; - margin: 40px 0; } - -.eventTitleArea h1 { - font-weight: 300; } - -.postEvent { - float: left; - width: 100%; - height: 130px; - padding: 30px 5%; - background: #F4F5F8; - margin: 20px 0 10px; - text-align: center; } - -.postEvent p { - margin-bottom: 20px; } - -.postEvent a { - background: #2A4E68; - padding: 10px 25px; - border-radius: 4px; - color: #fff; } - -.eventBlock { - float: left; - width: 100%; } - -.eventBlock.summit .date { - border-color: #2A4E68; - color: #2A4E68; } - -.eventBlock.past h2 { - margin-top: 50px; } - -.eventBlock.past .date { - border-color: #68C8C3; - color: #68C8C3; } - -/*End Events Page*/ -/*Community Page*/ -.communityBoxes { - margin: 30px 0 10px; - font-size: 13px; } - -.communityBoxes h2 { - font-size: 20px; - font-weight: 400; - margin-bottom: 15px; } - -.communityBoxes h2 a { - color: #DA422F; } - -.developersRow { - border-top: 1px solid #eee; - border-bottom: 1px solid #eee; - padding: 20px 30px; - margin-bottom: 30px; } - -.devLabel { - float: left; - margin-right: 30px; - font-weight: 700; } - -ul#developerActivity { - float: left; - padding-left: 0; - margin: 0; } - -ul#developerActivity li { - list-style: none; - display: inline-block; } - -ul#developerActivity li a { - font-weight: 700; - color: #222; } - -ul#developerActivity li span { - background: #E8EEF5; - padding: 5px 10px; - border-radius: 4px; - margin-right: 5px; - color: #2A4E68; - font-size: 11px; - font-weight: 400; } - -/*End Community Page*/ -/*Software Page*/ -.software { - margin-top: 30px; } - -.software-top { - text-align: center; } - -.software-top h1 { - margin: 5px 0 10px; } - -p.icon { - text-align: center; - margin: 40px 0 0; } - -p.software-description { - text-transform: uppercase; - font-size: 13px; - color: #777; } - -.openstack-diagram { - margin-bottom: 3em; } - -div.screenshots { - padding: 30px 0 20px; - margin: 30px 0; - border-top: 1px solid #edf2f7; - border-bottom: 1px solid #edf2f7; - width: 100%; } - -.screenshots ul { - padding: 0; - margin: 0; - text-align: center; } - -.screenshots ul li { - list-style: none; - display: inline-block; } - -@media (max-width: 767px) { - .screenshots ul li { - margin-bottom: 30px; } } - -.screenshots ul li a img { - width: 100%; - border: 4px solid #edf2f7; } - -.screenshots ul li a img:hover { - border-color: #30739C; } - -.screenshots ul li p { - margin: 10px 0 0; - font-size: 12px; - color: #30739C; - text-align: center; } - -.newSubNav li#start a.current, .newSubNav li#start a.current:hover { - color: #488613; - background-color: #DDFFE2; } - -ul.slides h3 { - text-align: center; - margin: 0 0 30px; } - -.tabSet { - background: #edf2f7; - border: 1px solid #30739C; - margin: 30px 0; - padding-top: 20px; - padding-bottom: 20px; } - -.tabContent table { - width: 100%; - margin: 0; - table-layout: fixed; - word-wrap: break-word; } - -.get-started-wrapper h3 { - text-align: center; - margin: 40px 0; } - -a.start-btn { - background: #30739C; - color: #fff; - text-transform: capitalize; - font-size: 12px; - border-radius: 2px; - padding: 10px 15px; - text-decoration: none; - border-style: none; - display: inline-block; } - -img.deploy-powered { - margin-top: 40px; } - -@media (max-width: 767px) { - img.deploy-powered { - margin: 10px 0 30px; } } - -img.deploy-compatible { - margin-top: 30px; } - -@media (max-width: 767px) { - img.deploy-compatible { - margin: 10px 0 30px; } } - -img.icehouse-video { - max-width: 100%; } - -.documentation { - margin-top: 50px; - text-align: center; - background: #edf2f7; - border-radius: 4px; - padding: 30px 0; } - -.documentation a { - padding: 7px 20px; - background: #30739C; - color: #edf2f7; - margin: 0 8px; - border-radius: 4px; } - -.documentation a:hover { - text-decoration: none; - background: #2A4E68; } - -@media (max-width: 767px) { - .documentation a { - padding: 5px 10px; - margin: 0 5px; - font-size: 12px; } } - -/*End Sofware Page*/ -/*Marketplace Page*/ -h2.marketplace-header { - border-left: 3px solid #DA422F; - line-height: 1.2em; - margin: 30px 20px; - padding-left: 15px; - font-size: 1.5em; } - -.build-use-box { - background: #edf2f7; - border-radius: 4px; - margin-bottom: 30px; - min-height: 25em; - padding: 20px; } - -.build-use-box h3 { - margin-bottom: 20px; } - -.build-use-box ul { - padding-left: 20px; } - -.marketplace-description { - margin-top: 50px; } - -.video { - width: 100%; } - -.video iframe { - width: 100%; - height: 225px; } - -.program-logos { - border-top: 1px solid #eee; - margin-top: 60px; - padding-top: 60px; } - -.ecosystem-wrapper { - padding-left: 30px; - border-left: 1px solid #eee; } - -.marketplace-top-wrapper { - padding: 20px 0 0; } - -.marketplace-brand { - margin-top: 20px; - padding-left: 30px; } - -h2.marketplace { - margin-bottom: -7px; - margin-top: 0; - font-size: 18px; - font-family: 'PT Sans', serif; - font-style: normal; - letter-spacing: -0.076em; - line-height: 1em; } - -h2.marketplace a, h2.marketplace a:hover { - color: #5B83A0; - text-decoration: none; } - -h1.marketplace { - font-size: 24pt; - margin-top: 5px; - text-align: left; } - -h1.marketplace:hover { - text-decoration: none; } - -h1.marketplace a, h1.marketplace a.visited { - color: #264D69; - font-family: 'PT Sans', serif; - font-style: normal; - letter-spacing: -0.076em; - line-height: 1em; } - -.grey-bar { - background-color: #edf2f7; - margin-bottom: 40px; - margin-top: 0; - padding-bottom: 10px; - padding-top: 10px; } - -ul.marketplace-nav { - padding: 0; - margin: 0; } - -ul.marketplace-nav li { - border-right: 1px solid #e8e8e8; - display: inline-block; - padding-left: 0.5em; - padding-right: 0.5em; - text-transform: uppercase; - width: 130px; - height: 96px; - vertical-align: top; - text-align: center; } - -ul.marketplace-nav li:last-child { - border-right: none; } - -@media (min-width: 680px) and (max-width: 1000px) { - ul.marketplace-nav li { - width: 100px; - height: 110px; } - ul.marketplace-nav li a { - font-size: 10px; } } - -@media (max-width: 680px) { - ul.marketplace-nav li { - display: block; - float: left; - border-right: none; - text-align: left; - border-bottom: 1px solid #e8e8e8; - width: 100%; - height: auto; - padding: 5px 10px; - vertical-align: middle; } } - -ul.marketplace-nav li a { - color: #848575; - text-decoration: none; - font-size: 12px; - vertical-align: middle; - width: 115px; - text-align: center; } - -@media (max-width: 680px) { - ul.marketplace-nav li a { - padding: 0; - vertical-align: middle; - float: left; - width: 100%; - text-align: left; } } - -ul.marketplace-nav a:hover { - color: #DA422F; } - -ul.marketplace-nav a span { - background: url("http://openstack.org/marketplace/code/ui/frontend/images/marketplace-icons.png") no-repeat scroll 0 0 rgba(0, 0, 0, 0); - display: block; - height: 50px; - margin: auto; - width: 40px; - text-align: center; } - -@media (max-width: 680px) { - ul.marketplace-nav a span { - display: table-cell; - vertical-align: middle; - float: left; } } - -ul.marketplace-nav #training a span { - background-position: 0 0; } - -ul.marketplace-nav #distros a span { - background-position: -50px 0; } - -ul.marketplace-nav #public-clouds a span { - background-position: -150px 0; } - -ul.marketplace-nav #private-clouds a span { - background-position: -250px 0; } - -ul.marketplace-nav #consulting a span { - background-position: -100px 0; } - -ul.marketplace-nav #drivers a span { - background-position: -200px 0; } - -ul.marketplace-nav .current a { - color: #DA422F; } - -/*End Marketplace Page*/ -/*Marketplace Listing Page*/ -.product-box { - border: 1px solid #E8E8E8; - margin-bottom: 30px; - padding: 30px 20px; - border-radius: 4px; - min-height: 200px; - border-left: 3px solid #DA422F; } - -.logo-area { - padding-top: 20%; - padding-left: 10px; } - -@media (max-width: 767px) { - .logo-area { - padding-top: 0; - padding-left: 0; } } - -.company-details-area h4 { - text-transform: uppercase; - font-weight: 300; } - -.details-button { - background: url("http://openstack.org/marketplace/code/ui/frontend/images/register-arrow.png") no-repeat scroll 85% center #000000; - color: #FFFFFF !important; - display: inline-block; - margin-right: -10px; - padding: 10px 2%; - text-align: left; - text-transform: uppercase; - width: 100px; - font-size: 12px; - border-radius: 4px; } - -.filter-label { - background: url("/images/images/marketplace-search-icon.png") no-repeat scroll left 7px rgba(0, 0, 0, 0); - color: #30739C; - float: left; - margin-bottom: 0; - margin-top: 5px; - padding-left: 25px; - padding-right: 20px; - padding-top: 8px; - text-transform: uppercase; - font-size: 12px; } - -input#name-term { - height: 40px; - width: 250px; - font-size: 12px; - padding: 5px 10px; - border: 1px solid #e8e8e8; - color: #30739C; - border-radius: 4px; } - -input#name-term::-webkit-input-placeholder { - color: #30739C; - font-size: 12px; } - -select#service-term { - height: 40px; - width: 200px; - padding: 5px 10px; - position: relative; - border-radius: 4px; - color: #30739C; - background: #fff; - border: 1px solid #e8e8e8; - -moz-box-sizing: border-box; - box-sizing: border-box; - -webkit-appearance: none; - -moz-appearance: none; - appearance: none; - display: inline-block; - cursor: pointer; - font-size: 12px; - font-weight: 400; } - -label#service-label { - position: relative; } - -label#service-label:after { - content: '>'; - color: #30739C; - -webkit-transform: rotate(90deg); - -ms-transform: rotate(90deg); - transform: rotate(90deg); - right: 14px; - top: 6px; - padding: 0 0 6px; - border-bottom: 1px solid #e8e8e8; - position: absolute; - pointer-events: none; - font-size: 14px; - font-weight: 400; } - -label#service-label:before { - content: ''; - right: 6px; - top: 0px; - width: 20px; - height: 20px; - background: #f8f8f8; - position: absolute; - pointer-events: none; - display: block; } - -@media (max-width: 767px) { - .filter-label { - width: 100%; - margin-bottom: 10px; } - input#name-term { - display: block; - width: 100%; - margin-bottom: 10px; } - select#service-term { - min-width: 400px; } } - -ul.resource-links { - padding: 0; - margin: 0 0 30px; } - -ul.resource-links li { - list-style: none; - display: block; } - -ul.resource-links li a { - background-image: url('../images/resource-link-icon.png'); - background-repeat: no-repeat; - background-position: 93% 50%; - background-color: #edf2f7; - padding: 15px 15px; - margin: 0 0 5px; - display: block; - border-radius: 4px; } - -ul.resource-links li a:hover { - text-decoration: none; - background-color: #DAE1EB; } - -.add-your-course { - border-radius: 4px; - border: 1px solid #30739C; - background: #fff; - padding: 20px; - font-size: 13px; } - -/*404 Page*/ -.four-o-four-wrapper { - text-align: center; - margin: 50px auto; } - -.four-o-four-wrapper img { - width: 100%; - max-width: 650px; - margin: 50px 0 70px; } - -.four-o-four-wrapper p { - color: #8a959e; } - -.four-o-four-wrapper a { - color: #30739C; - text-decoration: none; } - -.four-o-four-links { - margin-top: 50px; } - -.four-o-four-links a { - color: #30739C; - padding: 0 10px; - text-decoration: none; } - -@media (max-width: 767px) { - .four-o-four-links a { - padding: 0 5px; } } - -/*End 404 Page*/ -/*Blog Page*/ -.blog-title { - width: 100%; - background: url(/images/images/summit-promo-bkgd1.jpg) no-repeat center center; - background-size: cover; - padding: 50px 0; - text-align: center; } - -.blog-o { - max-width: 80px; - opacity: 0.9; } - -.blog-title h1 { - color: white; - font-weight: 400; - font-size: 45px; - margin: 10px 0; } - -.blog-title h1 span { - font-size: 16px; - display: block; - padding-top: 10px; - color: white; - font-weight: 300; } - -.container.blog { - margin-top: 30px; } - -.post { - margin-bottom: 60px; } - -.post-byline { - border-bottom: 1px dotted #c5e2ea; - border-top: 1px dotted #c5e2ea; - margin-bottom: 15px; - padding: 12px 0; - font-size: 12px; } - -.post-byline p { - margin-bottom: 0; } - -.post-byline .name a { - color: #DA422F; } - -.post-byline .postDate { - text-align: right; - color: #2A4E68; } - -.entry h1, .entry h2, .entry h3, .entry h3 a { - color: #2A4E68; - font-weight: 300; } - -.entry h1 { - font-size: 24px; } - -.entry h2 { - font-size: 20px; } - -.entry h3 { - font-size: 18px; } - -.entry h3 a { - text-decoration: underline; } - -#sidebar { - background: #edf2f7; - padding: 15px; - border-radius: 4px; - margin-top: 0; } - -#sidebar ul { - margin: 0; } - -#sidebar ul li { - font-size: 12px; } - -.creative-commons { - text-align: center; - margin-top: 40px; - font-size: 12px; } - -.creative-commons img { - margin-bottom: 10px; } - -.navigation a { - background: #30739C; - padding: 5px 10px; - border-radius: 4px; - color: white; } - -/*End Blog Page*/ -/*Vancouver Summit Landing Page*/ -.summit-landing-wrapper { - position: relative; - width: 100%; - height: 100%; - text-align: center; - padding: 70px 0; - background: url('../images/summit-vancouver-bkgd.jpg') no-repeat 0 0; - background-size: cover; } - -img.summit-landing-logo { - max-width: 200px; - margin-bottom: 40px; } - -.save-the-date { - color: white; - margin-bottom: 0px; - font-size: 16px; - font-weight: 400; - text-transform: capitalize; } - -.summit-landing-wrapper h1 { - color: white; - font-weight: 300; - font-size: 20px; - margin: 8px 0 10px; - text-transform: uppercase; } - -.summit-landing-wrapper p { - color: white; } - -.summit-landing-wrapper .summit-location { - display: block; - font-weight: 400; - font-size: 60px; - color: white; - text-align: center; - text-transform: uppercase; - position: relative; - display: inline-block; - -webkit-margin-before: 0; - -webkit-margin-after: 0; } - -.summit-landing-wrapper .summit-location::before { - content: ""; - border-top: 1px solid #edf2f7; - width: 150px; - height: 5px; - position: absolute; - margin-right: 15px; - top: 50%; - right: 100%; } - -.summit-landing-wrapper .summit-location::after { - content: ""; - border-top: 1px solid #edf2f7; - width: 150px; - height: 5px; - position: absolute; - margin-left: 15px; - top: 50%; - left: 100%; } - -@media (max-width: 767px) { - .summit-landing-wrapper h1 { - font-size: 15px; } - .summit-landing-wrapper .summit-location { - font-size: 40px; } - .summit-landing-wrapper .summit-location::before { - width: 75px; } - .summit-landing-wrapper .summit-location::after { - width: 75px; } } - -.summit-date { - background: none; - font-size: 25px; - margin-top: 30px; - color: white; } - -.summit-date span { - display: block; - margin-top: 20px; - font-size: 12px; - font-weight: 300; - text-transform: uppercase; } - -.landing-social { - margin-top: 40px; } - -.landing-social .social-icons { - width: 25px; - min-height: 25px; - display: inline-block; - margin: 0 10px; } - -.landing-twitter { - background: url('../images/landing-twitter.png') no-repeat; - opacity: 0.8; } - -.landing-twitter:hover { - opacity: 1; } - -.landing-facebook { - background: url('../images/landing-facebook.png') no-repeat; - opacity: 0.8; } - -.landing-facebook:hover { - opacity: 1; } - -.landing-linkedin { - background: url('../images/landing-linkedin.png') no-repeat; - opacity: 0.8; } - -.landing-linkedin:hover { - opacity: 1; } - -.summit-landing-bottom { - position: absolute; - bottom: 0; - left: 50%; } - -.summit-landing-bottom p { - color: white; } - -.landing-footer { - position: relative; - left: -50%; } - -.landing-footer a { - width: 150px; - padding: 5px 0 0; - display: inline-block; - background: #DA422F; - text-align: center; - color: white; - border-top-left-radius: 2px; - border-top-right-radius: 2px; } - -.landing-footer a:hover { - background: #BD2723; } - -.landing-footer a img { - position: relative; - margin: 0; - padding: 0; - max-width: 100px; } - -.summit-landing-wrapper a i { - color: #edf2f7; } - -.summit-landing-wrapper a i:hover { - color: white; } - -/*End Vancouver Summit Landing Page*/ -/* site banner */ -.top-site-banner { - background-color: #F0F9FE; - color: #4D96C7; - padding-top: 10px; } - -.top-site-banner-button { - border-radius: 5px; - border: 1px solid #C6E5FC; - font-size: 90%; - padding: 0px 10px; - background-color: white; - display: inline-block; - color: #4D96C7; - text-transform: uppercase; } - -.top-site-banner-button:hover { - text-decoration: none; - background-color: #F0F9FE; } - -/* end of site banner */ - -/*News page*/ -.grey-bar.news { - margin-bottom: 0; - padding: 20px; - text-align: right; } - -.grey-bar.news a { - font-size: 12px; - text-transform: uppercase; - color: #30739C; } - -.grey-bar.news a:hover { - color: #2A4E68; - text-decoration: none; } - -.grey-bar.news a i { - margin-right: 5px; } - -.grey-bar.news a.manage-news-link { - color: #889E2F; - margin-right: 20px; } - -.grey-bar.news a.manage-news-link:hover { - color: #5A6E1D; } - -.carousel { - height: 350px; } - -.carousel-inner { - height: 350px; } - -.carousel-inner img { - min-height: 350px; - height: 100%; - min-width: 100%; - max-width: none; - width: auto; - opacity: 0.6; } - -.carousel-inner > .item > img, .carousel-inner > .item > a > img { - min-width: 100%; - max-width: none; - width: 100%; } - -@media (max-width: 767px) { - .carousel-inner > .item > img, .carousel-inner > .item > a > img { - width: auto; } } - -.carousel-inner .item { - height: 350px; - background: #2A4E68; } - -.carousel-control { - text-shadow: none; } - -.carousel-control i { - position: absolute; - top: 50%; - z-index: 5; - display: inline-block; } - -.carousel-control.right i { - right: 50%; - margin-top: -15px; - margin-right: -15px; } - -.carousel-control.left i { - left: 50%; - margin-top: -15px; - margin-left: -15px; } - -.carousel-caption { - text-shadow: none; - bottom: 60px; } - -.carousel-caption h3 { - color: white; } - -.carousel-caption a.more-btn { - display: block; - color: white; - background: #DA422F; - border-radius: 4px; - padding: 5px 10px; - margin: 0 auto 20px; - max-width: 150px; - text-transform: uppercase; - font-size: 12px; } - -.carousel-caption a.more-btn:hover { - text-decoration: none; - background: #B92623; } - -.newsFeatured { - margin: 40px 0 60px; - float: left; - text-align: left; - padding-bottom: 10px; - border-bottom: 1px solid #edf2f7; } - -.featuredImage { - position: relative; - width: 100%; - height: 180px; - overflow: hidden; - margin-bottom: 10px; - background: #30739C; } - -.featuredImage img { - width: 100%; - /* width: auto;*/ } - -.featuredHeadline { - position: absolute; - bottom: 0; - right: 0; - left: 0; - background: rgba(0, 0, 0, 0.6); - padding: 15px 10px; - font-weight: 400; - color: white; } - -.featuredHeadline .more { - display: none; - text-align: center; - margin: 30px auto 20px; - text-transform: uppercase; - font-weight: 600; - background: white; - border-radius: 2px; - padding: 10px; - width: 150px; - color: #333; } - -.featuredHeadline .more i { - margin-left: 8px; } - -.featuredHeadline .more:hover { - background: #eee; } - -.featuredImage:hover .featuredHeadline, .open .featuredHeadline { - top: 0; } - -.featuredImage:hover .more, .open .more { - display: block; } - -.featuredImage:hover .featuredDate { - display: none; } - -.featuredDate { - font-size: 12px; - position: absolute; - top: 5px; - left: 10px; - color: white; } - -.featuredSummary { - font-size: 12px; - color: #555; } - -ul.featured { - padding: 0; - margin: 0; } - -ul.featured li { - list-style: none; - margin-bottom: 30px; - border-radius: 4px; } - -@media (max-width: 767px) { - ul.featured li { - margin-bottom: 20px; } } - -.recentBox { - margin-bottom: 30px; } - -.itemTimeStamp { - font-size: 12px; - color: #999; - margin-left: 10px; - padding-left: 10px; - border-left: 1px solid #aaa; } - -.news-sidebar { - background: #edf2f7; - padding: 15px; - border-radius: 4px; - margin-top: 0; } - -.see-all-events { - float: right; } - -.see-all-events a { - font-size: 12px; } - -.eventBlock { - padding-left: 15px; - font-size: 12px; } - -.eventBlock h3 { - margin-bottom: 15px; } - -.eventBlock .event { - margin-bottom: 20px; } - -.eventBlock .event.top { - margin-top: 20px; } - -/*End News page*/ -/*Single News Page*/ -.newsHome { - margin: 20px 0 30px; } - -.newsHome a { - text-transform: uppercase; - font-size: 12px; } - -.newsHome i { - margin-right: 10px; } - -.news-single h1 { - margin-bottom: 60px; } - -.news-summary { - background: #edf2f7; - color: #30739C; - padding: 30px; - text-align: center; - width: 80%; - margin: -10px 10% 60px; - border-radius: 4px; } - -.news-byline { - border-bottom: 1px dotted #c5e2ea; - border-top: 1px dotted #c5e2ea; - margin: 40px 0 15px; - padding: 18px 0 10px; - font-size: 12px; } - -.news-byline a.link { - color: #DA422F; } - -.news-byline p.postDate { - color: #2A4E68; - text-align: right; } - -/*End Single News Page*/ -/*Videos Home Page*/ -.main-video-wrapper { - width: 100%; - background: #222; - height: auto; - margin: 0 0 30px; - text-align: center; - -moz-box-sizing: border-box; - box-sizing: border-box; } - -a.main-video { - position: relative; - display: block; - max-width: 617px; - margin: 0 auto; - border-left: 1px solid #eee; - border-right: 1px solid #eee; } - -a.main-video .video-description-wrapper { - position: absolute; - display: block; - background: rgba(0, 0, 0, 0.7); - bottom: 0; - left: 0; - right: 0; - top: 230px; - text-align: left; - z-index: 1000; - padding: 20px; } - -@media (max-width: 767px) { - a.main-video .video-description-wrapper { - top: 60%; } } - -@media (max-width: 480px) { - a.main-video .video-description-wrapper { - top: 50%; } } - -a.main-video .video-description-wrapper .video-description { - width: 80%; - float: left; } - -a.main-video .video-description-wrapper .video-description h3 { - color: white; - font-size: 22px; - font-weight: 600; - width: 100%; - height: 25px; - overflow: hidden; - white-space: nowrap; - text-overflow: ellipsis; } - -a.main-video .video-description-wrapper .video-description p { - color: white; - font-size: 13px; - line-height: 1.2; - font-weight: 400; - padding: 0; - display: block; - width: 100%; - height: 15px; - margin: 0 auto; - white-space: nowrap; - overflow: hidden; - text-overflow: ellipsis; } - -a.main-video:hover .video-description-wrapper { - top: 0; } - -a.main-video:hover .video-description-wrapper .video-description h3 { - height: 10%; - white-space: normal; } - -a.main-video:hover .video-description-wrapper .video-description p { - height: 90%; - white-space: normal; } - -@media (max-width: 480px) { - a.main-video:hover .video-description-wrapper { - top: 50%; } - a.main-video:hover .video-description-wrapper .video-description h3 { - height: 25px; - white-space: nowrap; } - a.main-video:hover .video-description-wrapper .video-description p { - height: 15px; - white-space: nowrap; } } - -.main-video img { - margin: 0 auto; - width: 100%; - max-width: 615px; - max-height: 100%; - display: block; - position: relative; - z-index: 1; } - -.play-btn { - float: right; - color: white; - font-size: 40px; - width: 20%; - margin-top: 5px; - text-align: center; } - -.play-btn img#play { - max-width: 70px; - max-height: 70px; } - -.featured-row { - width: 100%; - background: #2A4E68; - padding: 0; - position: relative; - display: block; - margin-bottom: 50px; } - -.featured-row h2 { - color: white; - font-weight: 400; - font-size: 24px; } - -.featured-row h2 span { - font-weight: 400; - font-size: 12px; - color: #edf2f7; - margin-left: 20px; } - -.featured-row:after { - top: 100%; - left: 10%; - border: solid transparent; - content: " "; - height: 0; - width: 0; - position: absolute; - pointer-events: none; - border-color: rgba(42, 78, 104, 0); - border-top-color: #2A4E68; - border-width: 15px; - margin-left: -15px; } - -.daily-recap-wrapper .video-thumb-title { - text-align: center; } - -.video-thumb { - /*background: $lightblue;*/ - text-align: center; - width: 100%; - height: 0; - position: relative; - display: table; - overflow: hidden; - margin-bottom: 20px; - -moz-box-sizing: border-box; - box-sizing: border-box; } - -.thumb-play { - display: none; - background-image: url("//www.openstack.org/themes/openstack/images/landing-pages/auto/play-button.png"); - background-repeat: no-repeat; - background-position: center center; - background-color: rgba(0, 0, 0, 0.3); - position: absolute; - top: 0; - left: 0; - right: 0; - bottom: 0; } - -.video-thumb:hover .thumb-play { - display: block; } - -@media (max-width: 767px) { - .video-thumb .thumb-play { - display: block; - background-color: transparent; } } - -.video-thumb img.video-thumb-img { - max-width: 100%; - width: 100%; } - -.video-thumb p { - color: #C6CDD6; - font-size: 14px; - font-weight: 700; - display: table-cell; - vertical-align: middle; } - -.sort-row { - background: #edf2f7; - width: 100%; - min-height: 50px; - padding: 25px 0; - position: relative; - display: block; - margin: 50px 0; - color: #2A4E68; } - -.sort-left { - float: left; } - -.sort-left i { - color: #b4c5d6; - line-height: 1; - margin-right: 10px; } - -.sort-left i:hover { - color: #2A4E68; - cursor: pointer; } - -.sort-left i.active { - color: #2A4E68; } - -.sort-right { - float: right; - font-size: 12px; - text-transform: uppercase; - font-weight: 600; } - -.sort-right i { - margin-left: 10px; - font-weight: 700; - font-size: 14px; } - -.video-thumb-title { - margin: -10px 0 0; - color: #2A4E68; - font-size: 12px; - font-weight: 400; - width: 100%; - white-space: nowrap; - overflow: hidden; - text-overflow: ellipsis; } - -.video-thumb-speaker { - color: #2A4E68; - font-size: 12px; - font-weight: 600; - margin-bottom: 40px; - width: 100%; - white-space: nowrap; - overflow: hidden; - text-overflow: ellipsis; } - -@media (max-width: 767px) { - .daily-recap-wrapper .video-thumb-title { - margin-bottom: 40px; } - .video-thumb-title, .video-thumb-speaker { - text-align: center; } } - -.video-thumb-description { - display: none; } - -.video-dropdown > .dropdown-menu { - margin: 20px -20px 0; - padding: 10px 0; - min-width: 230px; - border-top-left-radius: 4px; - border-top-right-radius: 4px; - left: -99%; - right: 100%; - background-color: #edf2f7; - background-clip: padding-box; - border: 1px solid rgba(0, 0, 0, 0); - box-shadow: none; } - -/*.video-dropdown>.dropdown-menu:after, .video-dropdown>.dropdown-menu:before { - bottom: 100%; - right: 25%; - border: solid transparent; - content: " "; - height: 0; - width: 0; - position: absolute; - pointer-events: none; -} -.video-dropdown>.dropdown-menu:after { - border-color: rgba(255, 255, 255, 0); - border-bottom-color: #fff; - border-width: 15px; - margin-left: -15px; -} -.video-dropdown>.dropdown-menu:before { - border-color: rgba(170, 170, 170, 0); - border-bottom-color: #aaaaaa; - border-width: 15px; - margin-left: -16px; -}*/ -.video-dropdown > .dropdown-menu li a { - text-transform: uppercase; - padding: 13px 20px; - font-size: 12px; - color: #2A4E68; } - -.video-dropdown > .dropdown-menu li a:hover { - color: white; - background: #2A4E68; } - -.video-dropdown > .dropdown-menu li a:focus { - outline: none; } - -/*End Videos Home Page*/ -/* Change Video Gallery View */ -@media (min-width: 768px) { - .video-list .col-lg-3, .video-list .col-md-3, .video-list .col-sm-3 { - width: 100%; } - .video-list .video-thumb { - max-width: 270px; - width: 24%; - float: left; - margin-right: 1%; } - .video-list .video-details { - margin: 10px 0 0 1%; - float: left; - width: 74%; } } - -.video-list .video-thumb-speaker { - margin-bottom: 20px; } - -.video-list .video-details, .video-list .video-thumb-title, .video-list .video-thumb-speaker { - text-align: left; } - -.video-list .video-thumb-title { - font-size: 14px; - font-weight: 600; } - -.video-list .video-thumb-description { - color: #2A4E68; - font-size: 12px; - display: block; - overflow: hidden; } - -@media (min-width: 1180px) { - .video-list .video-thumb-description { - max-height: 130px; } } - -@media (min-width: 991px) and (max-width: 1179px) { - .video-list .video-thumb-description { - max-height: 100px; } } - -@media (min-width: 768px) and (max-width: 990px) { - .video-list .video-thumb-description { - max-height: 70px; } } - -/* End Change Video Gallery View */ -/*Video Inner Page*/ -.single-video-details { - margin: 60px auto; } - -.single-video-details h3 { - text-align: left; } - -.single-video-details strong { - color: #2A4E68; } - -.video-share { - text-align: right; - float: right; } - -.video-share a i { - font-size: 22px; - margin-left: 20px; - vertical-align: middle; - color: #759bb7; } - -.video-share a i:hover { - color: #2A4E68; } - -@media (max-width: 767px) { - .video-share { - float: none; - text-align: center; - margin: -20px 0 20px; - padding-top: 20px; - padding-bottom: 20px; - border-top: 1px solid #eee; - border-bottom: 1px solid #eee; } - .video-share a i { - margin: 0 10px; } } - -.video-share a i.fa-twitter { - font-size: 24px; - margin-bottom: -1px; } - -p.single-video-description { - margin: 10px 0 40px; } - -.video-categories a { - margin-left: 10px; - text-decoration: underline; } - -.video-tags { - margin-top: 15px; } - -.video-tags a { - background: #edf2f7; - font-size: 10px; - font-weight: 600; - border-radius: 3px; - margin-left: 10px; - padding: 5px 10px; } - -.video-speakers { - margin-top: 15px; - display: block; } - -.video-speakers p a { - margin-left: 0; - text-decoration: underline; } - -.video-speakers .twitter-follow-button { - margin-left: 10px; } - -.video-media-title { - margin: 0 0 10px; - display: block; } - -@media (max-width: 767px) { - .video-media-wrapper { - margin-top: 30px; } } - -.media-btn-wrapper { - float: left; - margin-top: 10px; } - -a.media-btn { - background: #2A4E68; - color: white; - padding: 10px 20px; - border-radius: 4px; - border: 0; } - -a.media-btn:hover { - text-decoration: none; - background: #16283A; } - -a.media-btn i { - margin-right: 10px; } - -a.media-btn.right { - border-top-left-radius: 0px; - border-bottom-left-radius: 0px; - margin-left: -2px; - border-left: 1px solid #3E71A4; } - -a.media-btn.left { - border-top-right-radius: 0px; - border-bottom-right-radius: 0px; - margin-right: -2px; - border-right: 1px solid #122231; } - -/*End Video Inner Page*/ -/*Docs Main*/ -.top-docs-wrapper { - width: 100%; - background: #edf2f7; - padding: 60px 0; } - -.top-docs-wrapper h1 { - text-align: left; } - -.top-docs-wrapper p { - color: #2A4E68; } - -.top-docs-wrapper hr { - border-color: #b1c9da; - margin: 40px 0; } - -.top-docs-wrapper h3 { - text-align: left; - text-transform: capitalize; - font-weight: 300; - font-size: 24px; } - -a.overview-btn.docs-btn { - border-radius: 2px; - text-transform: capitalize; - margin-right: 2%; - width: 31.33333%; - text-align: center; - line-height: 50px; - height: 50px; - padding: 0 10px; } - -a.overview-btn.docs-btn i { - font-size: 25px; - display: inline-block; - color: white; - margin-left: 5px; - height: 50px; - line-height: 50px; - vertical-align: middle; } - -.docs-main-search-form { - width: 98%; - margin-top: -20px; - float: left; - position: relative; } - -i.docs-search-icon { - position: absolute; - top: 17px; - left: 15px; - color: #C0CDDB; } - -.docs-main-search { - border: 2px solid #D5DDE7 !important; - border-radius: 2px; - height: 37px !important; - margin: 7px 0 0 0; - padding-left: 35px; - background: #fff !important; - width: 100%; - -webkit-transition: width 4s; - transition: width 4s; - -webkit-border-horizontal-spacing: 0 !important; - -webkit-border-vertical-spacing: 0 !important; } - -.docs-main-search:focus { - outline: none; } - -input.docs-main-search::-webkit-input-placeholder { - color: #C0CDDB; - font-size: 12px; - font-weight: 400; } - -input.docs-main-search:-moz-placeholder { - /* Firefox 18- */ - color: #C0CDDB; - font-size: 12px; - font-weight: 400; } - -input.docs-main-search::-moz-placeholder { - /* Firefox 19+ */ - color: #C0CDDB; - font-size: 12px; - font-weight: 400; } - -input.docs-main-search:-ms-input-placeholder { - color: #C0CDDB; - font-size: 12px; - text-transform: lowercase; - font-weight: 400; } - -.superuser-wrapper { - text-align: center; } - -@media (max-width: 767px) { - .superuser-wrapper { - display: none; } } - -.superuser-wrapper p { - margin-top: 10px; - font-size: 14px; - font-weight: 300; } - -.superuser-wrapper p strong { - display: block; - font-size: 12px; - font-weight: 600; } - -.mid-docs-wrapper { - background: white; - padding: 30px 0 25px; - border-top: 1px solid #edf2f7; - border-bottom: 1px solid #edf2f7; } - -.mid-docs-wrapper h2 { - color: #2A4E68; - margin: 0 0 5px; } - -.mid-docs-wrapper p { - color: #30739C; - font-weight: 300; } - -.docs-dropdown > a { - background: #2A4E68; - padding: 20px 5px; - text-align: center; - font-size: 13px; - color: white; } - -.docs-dropdown a { - width: 100%; - display: block; - border-radius: 4px; } - -@media (max-width: 767px) { - .docs-dropdown { - margin: 30px 0 10px; } } - -.docs-dropdown > a:hover, .docs-dropdown > a:focus { - text-decoration: none; - color: white; - background: #30739C; } - -.docs-dropdown i { - margin-left: 10px; - font-size: 18px; } - -.docs-dropdown .dropdown-menu { - width: 100%; - margin-top: 10px; } - -.docs-dropdown > .dropdown-menu:after, .docs-dropdown > .dropdown-menu:before, .docs-sidebar-dropdown:before, .docs-sidebar-dropdown:after { - bottom: 100%; - left: 50%; - border: solid transparent; - content: " "; - height: 0; - width: 0; - position: absolute; - pointer-events: none; } - -.docs-dropdown > .dropdown-menu:after, .docs-sidebar-dropdown:after { - border-color: rgba(255, 255, 255, 0); - border-bottom-color: #ffffff; - border-width: 15px; - margin-left: -15px; } - -.docs-dropdown > .dropdown-menu:before, .docs-sidebar-dropdown:before { - border-color: rgba(170, 170, 170, 0); - border-bottom-color: #aaaaaa; - border-width: 16px; - margin-left: -16px; } - -.docs-dropdown > .dropdown-menu > li.dropdown-header, .docs-sidebar-dropdown > li.dropdown-header { - text-align: left; - padding: 10px 20px; - margin: 10px 0; - border-bottom: 1px solid #edf2f7; - text-transform: uppercase; - color: #333; - font-weight: 400; } - -.docs-dropdown > .dropdown-menu > li.dropdown-header:first-child { - margin-top: 0; } - -.docs-dropdown > .dropdown-menu > li > a, .docs-sidebar-dropdown > li > a { - padding: 10px 25px; - text-align: left; - font-size: 13px; - color: #2A4E68; } - -.docs-toc { - background: white; - padding-top: 80px; - padding-bottom: 20px; } - -.docs-toc h3 { - margin-bottom: 30px; - font-size: 18px; - font-weight: 600; - padding-left: 10px; } - -.docs-toc h3 i { - font-size: 25px; - margin-right: 10px; } - -.docs-toc a { - font-size: 1.1em; - line-height: 1.3; - font-weight: 400; - color: #4c97c3; - display: block; - padding: 10px; } - -.docs-toc a:hover { - background: #edf2f7; - text-decoration: none; } - -.docs-link-sections { - margin: 0 0 10px; } - -.docs-contribute-wrapper { - padding-bottom: 10px; - text-align: center; } - -a.overview-btn.contribute-btn { - background: #DA422F; - color: white; - padding: 10px 0; - display: block; - float: none; - text-transform: capitalize; - width: 250px; - margin: 20px auto; } - -a.overview-btn.contribute-btn:hover { - background: #B52522; } - -a.overview-btn.contribute-btn i { - margin-left: 10px; } - -/*End Docs Main*/ -/*Docs Book View*/ -.docs-book-wrapper, .docs-search-wrapper { - margin-top: 40px; - margin-bottom: 40px; } - -@media (max-width: 767px) { - .docs-sidebar { - margin-top: 20px; - padding-top: 20px; - border-top: 1px solid #edf2f7; } } - -.docs-sidebar-search { - display: block; } - -.btn-group .btn + .btn, .btn-group .btn + .btn-group, .btn-group .btn-group + .btn, .btn-group .btn-group + .btn-group { - margin-left: 0; } - -.docs-sidebar-releases { - float: left; - margin: 20px 0 0; - width: 100%; } - -.docs-sidebar-releases button, .docs-sidebar-releases div.docs-sidebar-release-select { - background: #2A4E68; - color: #edf2f7; - display: inline-block; - text-align: center; - padding: 20px 0; - height: 60px; - border-radius: 0; } - -.docs-sidebar-releases button:hover, .docs-sidebar-releases button:focus { - color: white; - background: #1D354D; } - -.docs-sidebar-releases button.docs-sidebar-home { - width: 25%; - border-right: 1px solid #1c3b53; } - -.docs-sidebar-releases button.docs-sidebar-home i { - font-size: 20px; - line-height: 1; } - -.docs-sidebar-releases div.docs-sidebar-release-select { - font-size: 11px; - width: 75%; - vertical-align: middle; - border-left: 1px solid #496e8a; } - -.docs-sidebar-releases button.docs-sidebar-release-select i { - margin-left: 10px; } - -.docs-sidebar-dropdown { - right: 0; } - -.docs-sidebar-toc { - background: #edf2f7; - float: left; - padding: 0; - color: #2A4E68; - width: 100%; - border-top: 1px solid #edf2f7; } - -.docs-sidebar-section { - border-bottom: 1px solid #c8d8e5; - cursor: pointer; } - -.docs-sidebar-section:hover { - background: #BCCFDE; } - -#table-of-contents.docs-sidebar-section { - background-color: transparent; -} - -.docs-sidebar-section.active { - background: #D8E0EA; - padding: 0; - cursor: default; } - -.docs-sidebar-section h4 { - font-size: 14px; - width: 100%; - height: 100%; - font-weight: 700; } - -a.docs-sidebar-section-title { - display: block; - width: 100%; - padding: 10px 20px; - color: #2A4E68; } - -a.docs-sidebar-section-title:hover { - text-decoration: #BCCFDE; } - -.docs-sidebar-section.active a.docs-sidebar-section-title:hover { - cursor: default; } - -.docs-sidebar-section.active h4 { - margin-bottom: 20px; } - -.docs-sidebar-section.active ol { - list-style: none; - max-height: 2000px; - -webkit-transition: max-height 2s ease; - transition: max-height 2s ease; } - -.docs-sidebar-section ol { - counter-reset: section; - display: block; - max-height: 0; - margin: 0; - padding: 0 20px; - width: 100%; - list-style-position: inside; - white-space: nowrap; - overflow: hidden; - text-overflow: ellipsis; - -webkit-transition: max-height 0s ease; - transition: max-height 0s ease; } - -.docs-sidebar-section.active > ol:last-child { - margin-bottom: 30px; } - -.docs-sidebar-section ol a { - color: #2A4E68; } - -.docs-sidebar-section ol lh { - font-weight: 700; - font-size: 12px; - padding-bottom: 10px; - width: 100%; } - -.docs-sidebar-section ol > li { - max-height: 0; - margin-left: 0; - font-size: 12px; - line-height: 2; - width: 97%; - list-style-position: inside; - white-space: nowrap; - overflow: hidden; - text-overflow: ellipsis; - -webkit-transition: max-height 0s ease; - transition: max-height 0s ease; } - -.docs-sidebar-section ol.active > li:last-child { - margin-bottom: 20px; - max-height: 2000px; - -webkit-transition: max-height 2s ease; - transition: max-height 2s ease; } - -.docs-sidebar-section ol.active li > ul { - max-height: 0; } - -.docs-sidebar-section ol.active li, .docs-sidebar-section ol.active li.active > ul, .docs-sidebar-section ol.active li.active, .docs-sidebar-section ol.active li.active ul, .docs-sidebar-section ol.active li.active ul li { - display: list-item; - max-height: 2000px; - -webkit-transition: max-height 2s ease; - transition: max-height 2s ease; } - -.docs-sidebar-section ol li ul { - padding: 0; - margin: 0; - list-style: none; - counter-increment: none; } - -.docs-sidebar-section ol li ul li:before { - content: " "; } - -.docs-sidebar-section ol li > ul > li { - list-style: none; - margin-left: 20px; - counter-increment: none; } - -li.docs-has-sub > a { - font-weight: 700; } - -li.docs-has-sub:before { - content: "+"; - padding: 0 5px; - margin-right: 5px; - background: #C2CAD8; - border-radius: 4px; } - -li.docs-has-sub.open:before { - content: "-"; - padding: 0 6px; } - -.docs-header { - position: relative; } - -.docs-actions { - text-align: right; - margin-top: 35px; } - -.docs-actions i { - margin-left: 0; - padding: 0 5px; - font-size: 20px; - color: #999999; } - -.docs-actions i:hover { - color: #333; } - -.docs-actions i.fa-rss { - color: #FA600A; } - -.docs-actions i.fa-cloud-download { - color: #30739C; } - -.docs-actions .fa-info-circle { - border-left: 1px solid #dae5ee; - color: #5bb449; - padding: 0 10px; } - -.docs-actions .fa-info-circle:hover { - color: #36782A; } - -.docs-actions .fa-info-circle.docs-info-off { - color: #999; } - -.docs-actions .fa-bug { - border-left: 1px solid #dae5ee; - color: #DA422F; - padding: 0 10px; } - -.docs-actions .fa-bug:hover { - color: #9A201D; } - -.docs-actions .fa-angle-double-left { - border-left: 1px solid #dae5ee; - color: #DA422F; - padding: 0 10px; } - -.docs-actions .fa-angle-double-left:hover { - color: #9A201D; } - -.docs-actions .fa-angle-double-right { - border-left: 1px solid #dae5ee; - color: #DA422F; - padding: 0 10px; } - -.docs-actions .fa-angle-double-right:hover { - color: #9A201D; } - -.tooltip { - background: none; - white-space: nowrap; } - -.docs-byline { - border-top: 1px solid #edf2f7; - border-bottom: 1px solid #edf2f7; - padding: 10px; - font-size: 10px; - color: #9eb5c3; - text-transform: uppercase; } - -.docs-browse { - float: right; - font-size: 14px; - color: #6f91a6; - text-transform: uppercase; } - -.docs-updated { - float: left; } - -a.docs-edit { - float: right; - color: #9eb5c3; } - -a.docs-edit:hover { - color: #2A4E68; - text-decoration: none; } - -a.docs-edit i { - margin-right: 5px; } - -.docs-book-wrapper h5 { - font-size: 14px; - font-weight: 700; - color: #2A4E68; - margin: 20px 0; } - -.docs-top-contents ul { - list-style: none; - padding: 3px; - margin: 0 0 5px 0; } - -.docs-top-contents ul li a { - text-decoration: underline; } - -.docs-body a { - text-decoration: underline; - color: #30739C; } - -a.headerlink { - color: #fff; } - -a.headerlink:hover { - color: #30739C; } - -a.gloss { - background: #edf2f7; - color: #2A4E68; - padding: 2px 5px; - text-decoration: none; } - -a.gloss:hover { - background: #D4DCE6; } - -a.gloss:focus { - outline: none; } - -a.gloss.off { - background: transparent; - padding: 0; - color: #333; - cursor: default; } - -pre { - background-color: #333; - color: #fff; - overflow: auto; - margin: 0 0 10px; - padding: 20px 30px; } - -pre code, pre .line-number { - font-family: "Courier New", Courier, Monospace; - font-weight: normal; - font-size: 14px; - color: white; - display: block; } - -pre .line-number { - float: left; - margin: 0 1em 0 -1em; - border-right: 3px solid #5bb449; - text-align: right; } - -pre .line-number span { - display: block; - padding: 0 0.5em 0 1em; } - -pre .cl { - display: block; - clear: both; } - -.popover { - color: #2A4E68; } - -.admonition { - background: #eee; - border-left: 4px solid; - border-radius: 4px; - padding: 20px; - margin: 30px 0; } - -.admonition h3 { - font-size: 18px; - font-weight: 600; } - -.admonition h3 i { - margin-right: 5px; - font-size: 22px; } - -.admonition.note { - background: #edf2f7; - border-color: #2A4E68; - color: #2A4E68; } - -.admonition.note a { - color: #2A4E68; } - -/* BB: The following eight rules, four "important" and four "warning", - originally had names "docs-important" and "docs-warning" */ - -.admonition.important { - background: #FEFFBE; - border-color: #D7AA16; - color: #D7AA16; } - -.admonition.important a { - color: #e8be15; } - -.admonition.important h3 { - color: #e8be15; } - -.admonition.important h3 i { - color: #e8be15; } - -.admonition.warning { - background: #FED3D9; - border-color: #DA422F; - color: #DA422F; } - -.admonition.warning h3 { - color: #DA422F; } - -.admonition.warning h3 i { - color: #DA422F; } - -.admonition.warning a { - color: #DA422F; } - -/* BB: added the adminition-title rule to bolden the adminition title */ -.admonition-title { - font-weight: 600; -} - -.docs-tags { - width: 100%; - margin-bottom: 30px; } - -a.docs-tag { - background: #edf2f7; - padding: 3px 6px; - border-radius: 4px; - display: inline-block; - margin: 0 5px 0 0; - font-size: 12px; - color: #30739C; } - -.docs-byline.bottom { - margin-bottom: 30px; } - -.docs-license { - /* margin-top: 30px; */ - color: #555; - font-size: 12px; - border-right: 1px solid #edf2f7; } - -@media (max-width: 767px) { - .docs-license { - border-right: 0; - border-bottom: 1px solid #edf2f7; - padding-bottom: 20px; - margin-bottom: 20px; } } - -.docs-license a { - color: #555; - font-size: 12px; - text-decoration: underline; } - -.docs-license a:hover { - color: #222; } - -.docs-license img { - float: left; - margin: 5px 15px 20px 0; } - -.docs-actions-wrapper { - margin-top: 10px; } - -a.docs-footer-actions { - display: block; - color: #555; - text-transform: uppercase; - font-size: 11px; - margin-bottom: 15px; } - -a.docs-footer-actions i { - font-size: 18px; - margin-right: 10px; } - -a.docs-footer-actions:hover { - color: #222; } - -/*End Docs Book View*/ -/*Docs Search View*/ -.docs-search-wrapper h2 { - text-align: center; } - -.docs-search-count { - text-align: right; - font-size: 11px; - font-weight: 600; - color: #2A4E68; - border-bottom: 1px solid #edf2f7; - margin: 20px 0; - padding-bottom: 15px; } - -.docs-result { - margin: 20px 0; - padding: 20px 0; - border-bottom: 1px solid #edf2f7; } - -.docs-result h3 a { - font-size: 16px; - font-weight: 600; - text-decoration: underline; - color: #30739C; } - -.docs-result h3 a:hover { - color: #2A4E68; } - -.docs-result p { - font-size: 14px; } - -.docs-result p span { - font-style: italic; } - -.docs-result p span:after { - content: "..."; - margin-left: 5px; - margin-right: 5px; } - -.docs-result .docs-search-link { - font-size: 12px; - color: #666; - text-decoration: none; } - -.docs-result .docs-search-link:hover { - color: #333; } - -.docs-pagination { - text-align: center; } - -ul.pagination li a { - margin: 0 3px; - border-radius: 4px; - border: 3px solid #edf2f7; - color: #30739C; - font-weight: 400; - font-size: 14px; } - -ul.pagination li.active a, ul.pagination li.active a:hover { - border-color: #30739C; - color: #2A4E68; - background: white; } - -ul.pagination li a:hover { - border-color: #C2CAD8; - background: white; } - -/*End Docs Search View*/ -/*webui Popover styles*/ -.webui-popover { - position: absolute; - top: 0; - left: 0; - z-index: 1060; - display: none; - width: 276px; - min-height: 50px; - padding: 1px; - text-align: left; - white-space: normal; - background-color: #ffffff; - background-clip: padding-box; - border: 1px solid #cccccc; - border: 1px solid rgba(0, 0, 0, 0.2); - border-radius: 6px; - box-shadow: 0 5px 10px rgba(0, 0, 0, 0.2); } - -.webui-popover.top, .webui-popover.top-left, .webui-popover.top-right { - margin-top: -10px; } - -.webui-popover.right, .webui-popover.right-top, .webui-popover.right-bottom { - margin-left: 10px; } - -.webui-popover.bottom, .webui-popover.bottom-left, .webui-popover.bottom-right { - margin-top: 10px; } - -.webui-popover.left, .webui-popover.left-top, .webui-popover.left-bottom { - margin-left: -10px; } - -.webui-popover-inner .close { - font-family: arial; - margin: 5px 10px 0 0; - float: right; - font-size: 20px; - font-weight: bold; - line-height: 20px; - color: #000000; - text-shadow: 0 1px 0 #fff; - opacity: 0.2; - filter: alpha(opacity=20); - text-decoration: none; } - -.webui-popover-inner .close:hover, .webui-popover-inner .close:focus { - opacity: 0.5; - filter: alpha(opacity=50); } - -.webui-popover-title { - padding: 8px 14px; - margin: 0; - font-size: 14px; - font-weight: normal; - line-height: 18px; - background-color: #f7f7f7; - border-bottom: 1px solid #ebebeb; - border-radius: 5px 5px 0 0; } - -.webui-popover-content { - padding: 9px 14px; - overflow: auto; } - -.webui-popover-inverse { - background-color: #333333; - color: #eeeeee; } - -.webui-popover-inverse .webui-popover-title { - background: #3b3b3b; - border-bottom: none; - color: #eeeeee; } - -.webui-no-padding .webui-popover-content { - padding: 0; } - -.webui-no-padding .list-group-item { - border-right: none; - border-left: none; } - -.webui-no-padding .list-group-item:first-child { - border-top: 0; } - -.webui-no-padding .list-group-item:last-child { - border-bottom: 0; } - -.webui-popover > .arrow, .webui-popover > .arrow:after { - position: absolute; - display: block; - width: 0; - height: 0; - border-color: transparent; - border-style: solid; } - -.webui-popover > .arrow { - border-width: 11px; } - -.webui-popover > .arrow:after { - border-width: 10px; - content: ""; } - -.webui-popover.top > .arrow, .webui-popover.top-right > .arrow, .webui-popover.top-left > .arrow { - bottom: -11px; - left: 50%; - margin-left: -11px; - border-top-color: #999999; - border-top-color: rgba(0, 0, 0, 0.25); - border-bottom-width: 0; } - -.webui-popover.top > .arrow:after, .webui-popover.top-right > .arrow:after, .webui-popover.top-left > .arrow:after { - content: " "; - bottom: 1px; - margin-left: -10px; - border-top-color: #ffffff; - border-bottom-width: 0; } - -.webui-popover.right > .arrow, .webui-popover.right-top > .arrow, .webui-popover.right-bottom > .arrow { - top: 50%; - left: -11px; - margin-top: -11px; - border-left-width: 0; - border-right-color: #999999; - border-right-color: rgba(0, 0, 0, 0.25); } - -.webui-popover.right > .arrow:after, .webui-popover.right-top > .arrow:after, .webui-popover.right-bottom > .arrow:after { - content: " "; - left: 1px; - bottom: -10px; - border-left-width: 0; - border-right-color: #ffffff; } - -.webui-popover.bottom > .arrow, .webui-popover.bottom-right > .arrow, .webui-popover.bottom-left > .arrow { - top: -11px; - left: 50%; - margin-left: -11px; - border-bottom-color: #999999; - border-bottom-color: rgba(0, 0, 0, 0.25); - border-top-width: 0; } - -.webui-popover.bottom > .arrow:after, .webui-popover.bottom-right > .arrow:after, .webui-popover.bottom-left > .arrow:after { - content: " "; - top: 1px; - margin-left: -10px; - border-bottom-color: #ffffff; - border-top-width: 0; } - -.webui-popover.left > .arrow, .webui-popover.left-top > .arrow, .webui-popover.left-bottom > .arrow { - top: 50%; - right: -11px; - margin-top: -11px; - border-right-width: 0; - border-left-color: #999999; - border-left-color: rgba(0, 0, 0, 0.25); } - -.webui-popover.left > .arrow:after, .webui-popover.left-top > .arrow:after, .webui-popover.left-bottom > .arrow:after { - content: " "; - right: 1px; - border-right-width: 0; - border-left-color: #ffffff; - bottom: -10px; } - -.webui-popover-inverse.top > .arrow, .webui-popover-inverse.top-left > .arrow, .webui-popover-inverse.top-right > .arrow, .webui-popover-inverse.top > .arrow:after, .webui-popover-inverse.top-left > .arrow:after, .webui-popover-inverse.top-right > .arrow:after { - border-top-color: #333333; } - -.webui-popover-inverse.right > .arrow, .webui-popover-inverse.right-top > .arrow, .webui-popover-inverse.right-bottom > .arrow, .webui-popover-inverse.right > .arrow:after, .webui-popover-inverse.right-top > .arrow:after, .webui-popover-inverse.right-bottom > .arrow:after { - border-right-color: #333333; } - -.webui-popover-inverse.bottom > .arrow, .webui-popover-inverse.bottom-left > .arrow, .webui-popover-inverse.bottom-right > .arrow, .webui-popover-inverse.bottom > .arrow:after, .webui-popover-inverse.bottom-left > .arrow:after, .webui-popover-inverse.bottom-right > .arrow:after { - border-bottom-color: #333333; } - -.webui-popover-inverse.left > .arrow, .webui-popover-inverse.left-top > .arrow, .webui-popover-inverse.left-bottom > .arrow, .webui-popover-inverse.left > .arrow:after, .webui-popover-inverse.left-top > .arrow:after, .webui-popover-inverse.left-bottom > .arrow:after { - border-left-color: #333333; } - -.webui-popover i.icon-refresh { - display: block; - width: 30px; - height: 30px; - font-size: 20px; - top: 50%; - left: 50%; - position: absolute; - background: url(../img/loading.gif) no-repeat; } - -@-webkit-keyframes rotate { - 100% { - -webkit-transform: rotate(360deg); } } - -@keyframes rotate { - 100% { - -webkit-transform: rotate(360deg); - transform: rotate(360deg); } } - -.newSubNav { - width: 85%; } - -.newSubNav ul { - padding: 0px; - margin-top: 30px; - margin-left: -10px; } - -.newSubNav ul:nth-child(2) { - border-top: 1px solid #E8E8E8; - padding-top: 30px; } - -.newSubNav li { - list-style: none; } - -.newSubNav a { - color: #8A959E; - text-transform: uppercase; - font-size: 12px; - padding: 15px 20px; - display: block; } - -.newSubNav a.current, .newSubNav a.current:hover { - background-color: #EDF2F7; - font-weight: bold; - color: #2D709B; } - -.newSubNav a:hover { - text-decoration: none; - color: black; } - -.newSubNav .fa-chevron-right { - float: right; - margin-top: 2px; - color: #C6D8E4; } - -li#start a { - color: #75C320; } - -li#openstack-shared-services { - padding-bottom: 20px; - border-bottom: 1px solid #E8E8E8; } - -li#start { - margin-top: 20px; } - -fieldset { - border: 1px solid #CCCCCC; - padding: 20px 17px 20px 17px; - margin-bottom: 20px; } - -fieldset ul { - list-style: none; } - -input[type="radio"] { - margin-left: 0px; } - -input[type="checkbox"] { - margin-left: 0px !important; } - -input[type="checkbox"], input[type="radio"] { - display: inline-block; } - -div.tooltip-inner { - max-width: 350px; -} - -table.highlighttable { - width: 100%; -} - -.docs-sidebar-section ul ul { - padding-left: 0px; - margin-left: 10px; -} - -.docs-sidebar-section > ul:not(.current) li > ul { - display: none; -} - -.docs-sidebar-section > ul li:not(.current) > ul { - display: none; -} - -li.toctree-l2:not(.current) > ul { - display: none; -} - -.docs-sidebar-section li.current > a { - font-weight: bold; -} - -.docs-body .section h1 { - display: none; -} - -.docs-top-contents a[href="#"] { - display: none; -} - -.docs-top-contents h5 { - margin-bottom: 10px; -} - -.docs-top-contents { - padding: 10px; -} diff --git a/_templates/openstackdocs/static/css/native.css b/_templates/openstackdocs/static/css/native.css deleted file mode 100644 index bffc5c9be..000000000 --- a/_templates/openstackdocs/static/css/native.css +++ /dev/null @@ -1,69 +0,0 @@ -.hll { background-color: #404040 } -.c { color: #999999; font-style: italic } /* Comment */ -.err { color: #a61717; background-color: #e3d2d2 } /* Error */ -.g { color: #d0d0d0 } /* Generic */ -.k { color: #6ab825; font-weight: bold } /* Keyword */ -.l { color: #d0d0d0 } /* Literal */ -.n { color: #d0d0d0 } /* Name */ -.o { color: #d0d0d0 } /* Operator */ -.x { color: #d0d0d0 } /* Other */ -.p { color: #d0d0d0 } /* Punctuation */ -.cm { color: #999999; font-style: italic } /* Comment.Multiline */ -.cp { color: #cd2828; font-weight: bold } /* Comment.Preproc */ -.c1 { color: #999999; font-style: italic } /* Comment.Single */ -.cs { color: #e50808; font-weight: bold; background-color: #520000 } /* Comment.Special */ -.gd { color: #d22323 } /* Generic.Deleted */ -.ge { color: #d0d0d0; font-style: italic } /* Generic.Emph */ -.gr { color: #d22323 } /* Generic.Error */ -.gh { color: #ffffff; font-weight: bold } /* Generic.Heading */ -.gi { color: #589819 } /* Generic.Inserted */ -.go { color: #cccccc } /* Generic.Output */ -.gp { color: #aaaaaa } /* Generic.Prompt */ -.gs { color: #d0d0d0; font-weight: bold } /* Generic.Strong */ -.gu { color: #ffffff; text-decoration: underline } /* Generic.Subheading */ -.gt { color: #d22323 } /* Generic.Traceback */ -.kc { color: #6ab825; font-weight: bold } /* Keyword.Constant */ -.kd { color: #6ab825; font-weight: bold } /* Keyword.Declaration */ -.kn { color: #6ab825; font-weight: bold } /* Keyword.Namespace */ -.kp { color: #6ab825 } /* Keyword.Pseudo */ -.kr { color: #6ab825; font-weight: bold } /* Keyword.Reserved */ -.kt { color: #6ab825; font-weight: bold } /* Keyword.Type */ -.ld { color: #d0d0d0 } /* Literal.Date */ -.m { color: #3677a9 } /* Literal.Number */ -.s { color: #ed9d13 } /* Literal.String */ -.na { color: #bbbbbb } /* Name.Attribute */ -.nb { color: #24909d } /* Name.Builtin */ -.nc { color: #447fcf; text-decoration: underline } /* Name.Class */ -.no { color: #40ffff } /* Name.Constant */ -.nd { color: #ffa500 } /* Name.Decorator */ -.ni { color: #d0d0d0 } /* Name.Entity */ -.ne { color: #bbbbbb } /* Name.Exception */ -.nf { color: #447fcf } /* Name.Function */ -.nl { color: #d0d0d0 } /* Name.Label */ -.nn { color: #447fcf; text-decoration: underline } /* Name.Namespace */ -.nx { color: #d0d0d0 } /* Name.Other */ -.py { color: #d0d0d0 } /* Name.Property */ -.nt { color: #6ab825; font-weight: bold } /* Name.Tag */ -.nv { color: #40ffff } /* Name.Variable */ -.ow { color: #6ab825; font-weight: bold } /* Operator.Word */ -.w { color: #666666 } /* Text.Whitespace */ -.mf { color: #3677a9 } /* Literal.Number.Float */ -.mh { color: #3677a9 } /* Literal.Number.Hex */ -.mi { color: #3677a9 } /* Literal.Number.Integer */ -.mo { color: #3677a9 } /* Literal.Number.Oct */ -.sb { color: #ed9d13 } /* Literal.String.Backtick */ -.sc { color: #ed9d13 } /* Literal.String.Char */ -.sd { color: #ed9d13 } /* Literal.String.Doc */ -.s2 { color: #ed9d13 } /* Literal.String.Double */ -.se { color: #ed9d13 } /* Literal.String.Escape */ -.sh { color: #ed9d13 } /* Literal.String.Heredoc */ -.si { color: #ed9d13 } /* Literal.String.Interpol */ -.sx { color: #ffa500 } /* Literal.String.Other */ -.sr { color: #ed9d13 } /* Literal.String.Regex */ -.s1 { color: #ed9d13 } /* Literal.String.Single */ -.ss { color: #ed9d13 } /* Literal.String.Symbol */ -.bp { color: #24909d } /* Name.Builtin.Pseudo */ -.vc { color: #40ffff } /* Name.Variable.Class */ -.vg { color: #40ffff } /* Name.Variable.Global */ -.vi { color: #40ffff } /* Name.Variable.Instance */ -.il { color: #3677a9 } /* Literal.Number.Integer.Long */ diff --git a/_templates/openstackdocs/static/css/styles.css b/_templates/openstackdocs/static/css/styles.css deleted file mode 100644 index a3b47da55..000000000 --- a/_templates/openstackdocs/static/css/styles.css +++ /dev/null @@ -1,1308 +0,0 @@ -/*! - * Start Bootstrap - Landing Page Bootstrap Theme (http://startbootstrap.com) - * Code licensed under the Apache License v2.0. - * For details, see http://www.apache.org/licenses/LICENSE-2.0. - */ - -body, -html { - width: 100%; - height: 100%; -} - -body, -h1, -h2, -h3, -h4, -h5, -h6 { - font-family: "Open Sans", Helvetica, Arial, sans-serif; - font-weight: 400; -} -h2 { - color: #284d68; - font-size: 34; - font-weight: 300; - margin-bottom: 25px; -} -h5 { - color: #da3d27; - margin-bottom: 0; -} - -dd { - margin-left: 20px -} - -ol.loweralpha { - list-style-type: lower-alpha; -} - -.lead { - font-size: 18px; - font-weight: 400; -} - -/*Header Navigation*/ -.brand-wrapper { - margin: 10px 0; - padding-right: 20px; - float: left; - border-right: 1px solid #eee; - min-width: 135px; -} -@media (max-width: 767px) { - .brand-wrapper { - border-right: none; - } -} -a.navbar-brand { - background: url('../images/openstack-logo-full.png') left no-repeat; - height: 35px; - width: 135px; -} -@media (min-width: 768px) and (max-width: 1025px) { - .brand-wrapper { - width: 75px; - min-width: 75px; - margin-top: 0; - } - a.navbar-brand { - background: url('../images/openstack-logo-vert.png') left no-repeat; - margin-left: 0px !important; - height: 54px; - width: 59px; - } -} -@media (max-width: 767px) { - a.navbar-brand { - margin-left: 15px; - } -} -.navbar-default { - border: none; - border-radius: 0px; - background: #fff; - margin-bottom: 0; - padding: 20px 0; -} -.navbar-default .container { - background-color: white; -} -@media (min-width: 768px) and (max-width: 1200px) { - .navbar-default .container { - width: 100%; - } -} -ul.navbar-main { - display: none; - float: right; -} -@media (min-width: 768px) and (max-width: 1097px) { - ul.navbar-main { - display: block; - } -} -@media (max-width:767px) { - ul.navbar-main { - display: block; - margin-right: 30px; - width: 90%; - } -} -.navbar-default ul.navbar-main>li>a { - color: #8a959e; - font-size: 12px; - font-weight: 400; - text-transform: uppercase; -} -@media (min-width: 768px) and (max-width: 1025px) { - ul.navbar-main { - margin-top: 1px; - } - .navbar-default ul.navbar-main>li>a { - font-size: 11px; - padding: 15px 8px; - } -} -.navbar-default .navbar-nav>.open>a, .navbar-default .navbar-nav>.open>a:hover, .navbar-default .navbar-nav>.open>a:focus { - background: #fff; -} -.navbar-nav>li>.dropdown-menu { - margin-top: 10px; - padding: 10px 0; - min-width: 230px; - border-top-left-radius: 4px; - border-top-right-radius: 4px; -} -.navbar-nav>li>.dropdown-menu:after, .navbar-nav>li>.dropdown-menu:before { - bottom: 100%; - left: 25%; - border: solid transparent; - content: " "; - height: 0; - width: 0; - position: absolute; - pointer-events: none; -} - -.navbar-nav>li>.dropdown-menu:after { - border-color: rgba(255, 255, 255, 0); - border-bottom-color: #ffffff; - border-width: 15px; - margin-left: -15px; -} -.navbar-nav>li>.dropdown-menu:before { - border-color: rgba(170, 170, 170, 0); - border-bottom-color: #aaaaaa; - border-width: 16px; - margin-left: -16px; -} -@media (max-width: 767px) { - .navbar-nav>li>.dropdown-menu:after, .navbar-nav>li>.dropdown-menu:before { - display: none; - } - - .navbar-nav>li>.dropdown-menu:after { - display: none; - } - .navbar-nav>li>.dropdown-menu:before { - display: none; - } -} -i.fa-caret-right { - margin-left: 8px; -} -.navbar-nav>li>.dropdown-menu li a{ - text-transform: uppercase; - padding: 13px 20px; - font-size: 12px; - color: #8a959e; -} -.navbar-nav>li>.dropdown-menu li a:hover { - color: #333; -} -.navbar-nav>li>.dropdown-menu li a:focus { - outline: none; -} -@media (max-width: 767px) { - .navbar-default ul.navbar-main>li>a i.fa-caret-down { - display: none; - } -} -.navbar-default .navbar-toggle { - border: none; -} -.navbar-default .navbar-toggle:hover, .navbar-default .navbar-toggle:focus { - background: transparent; -} -.navbar-default .navbar-toggle .icon-bar { - background-color: #5A5A5A; - height: 3px; - border-radius: 3px; -} -.search-container { - position: relative; - display: none; - float: left; - width: 84%; -} -@media (min-width: 768px) and (max-width: 1200px) { - .search-container { - width: 80%; - } -} -@media (max-width:767px) { - .search-container { - display: none; - } -} -.search-icon { - display: none; - padding: 17px 20px 16px; - float: left; - text-transform: uppercase; - color: #8a959e; - font-size: 12px; - font-weight: 400; -} -.search-icon:hover { - cursor: pointer; - color: #8a959e; -} -.search-icon i { - margin-right: 5px; - color: #8a959e; -} -@media (max-width: 767px) { - .search-icon { - display: none !important; - } -} -.header-search-form { - position: absolute; - z-index: 1000; - left: 20px; - width: 100%; - -webkit-transition-property: width; - -webkit-transition-duration: 1s; - -webkit-transition-timing-function: linear; - /* Standard syntax */ - transition-property: width; - transition-duration: 1s; - transition-timing-function: linear; -} -@media (max-width:767px) { - .header-search-form { - display: none; - } -} -.mobile-search-form { - display: none; - position: relative; - width: 100%; -} -@media (max-width: 767px) { - .mobile-search-form { - display: block; - } -} -.header-search { - border: 2px solid #dae5ee; - border-radius: 4px; - height: 35px; - margin: 7px 0 0 0; - background: #fff; - width: 100%; - -webkit-transition: width 4s; - -moz-transition: width 4s; - -ms-transition: width 4s; - -o-transition: width 4s; - transition: width 4s; -} -.header-search::-webkit-input-placeholder { - color: #8a959e; - font-size: 12px; - text-transform: lowercase; - font-weight: 400; -} - -.header-search:-moz-placeholder { /* Firefox 18- */ - color: #8a959e; - font-size: 12px; - text-transform: lowercase; - font-weight: 400; -} - -.header-search::-moz-placeholder { /* Firefox 19+ */ - color: #8a959e; - font-size: 12px; - text-transform: lowercase; - font-weight: 400; -} - -.header-search:-ms-input-placeholder { - color: #8a959e; - font-size: 12px; - text-transform: lowercase; - font-weight: 400; -} -.header-search:focus { - border-radius: 4px; - outline: none; - border: 2px solid #3D84B6; -} -.close-search { - position: absolute; - top: 17px; - right: 6px; - color: #dae5ee; - z-index: 1001; - font-size: 16px -} -.close-search:hover { - color: #3D84B6; - cursor: pointer; -} -@media (max-width:767px) { - .close-search { - display: none !important; - } -} -.show { - display: block; -} -@media (max-width:767px) { - .show { - display: none; - } -} - -/*End Header Navigation*/ - -/*Hero*/ - -.intro-header { - padding-top: 0px; - padding-bottom: 0; - text-align: center; - color: #f8f8f8; - background: url(/images/hero-bkgd1.jpg) no-repeat center center; - background-size: cover; - position: relative; -} - -.intro-message { - position: relative; - padding-top: 110px; - padding-bottom: 110px; -} -@media(max-width:1199px) { - .intro-message { - padding-bottom: 50px; - } -} - -.intro-message > h1 { - margin: 0; - font-size: 3em; - font-weight: 300; - text-align: center; - font-family: "Open Sans", Helvetica, Arial, sans-serif; - width: 100%; -} - -@media(max-width:767px) { - .intro-message > h1 { - font-size: 3em; - } -} -.intro-divider { - width: 400px; - border-top: 1px solid #f8f8f8; - border-bottom: 1px solid rgba(0,0,0,0.2); -} - -.intro-message > h3 { - text-shadow: none; - text-align: left; - font-weight: 300; - font-size: 24px; - margin-top: 10px; -} -.hero-credit { - position: absolute; - bottom: 30px; - right: 30px; - color: #fff; - opacity: 0.5; -} -.hero-credit:hover { - opacity: 1; -} - -/*Hero Promo, add .featured to .intro-header*/ -.intro-header.featured { - text-align: center; - background: url(/images/summit-promo-bkgd1.jpg) no-repeat center center; - min-height: 420px; - background-size: cover; - position: relative; -} -.intro-header.featured .intro-message { - padding-bottom: 50px; -} -.promo-btn-wrapper { - -} -a.promo-btn { - color: #fff; - font-size: 24px; - font-weight: 300; - background: transparent; - border: 2px solid #fff; - border-radius: 4px; - padding: 20px 35px; - margin: 0 auto; - text-align: center; - min-width: 370px; - display: inline-block; -} -a.promo-btn:hover { - text-decoration: none; - background: rgba(255, 255, 255, 0.2); -} -a.promo-btn i.fa-chevron-right { - background: transparent; - border: 2px solid #fff; - border-radius: 100px; - padding: 0; - font-size: 14px; - margin-left: 10px; - width: 30px; - height: 30px; - line-height: 2.1; -} -p.promo-dates { - display: inline-block; - margin-top: 10px; - font-weight: 400; -} - -/*End Hero*/ - -/*Overview Section*/ -.overview-section { - padding: 80px 0; -} -@media (max-width: 767px) { - .overview-section { - padding-top: 40px; - } -} -.overview-section h2 { - color: #284d68; - font-size: 34px; - font-weight: 300; - margin-bottom: 25px; -} -.overview-section p { - color: #888; - font-size: 16px; - font-weight: 300px; - line-height: 1.4; -} -.overview-section a { - color: #4c97c3; - text-decoration: underline; -} -.btn-wrapper { - float: left; - width: 100%; - text-align: center; -} -@media (max-width: 980px) { - .overview-left { - margin-bottom: 50px; - } -} -a.overview-btn { - float: left; - background: #4c97c3; - color: #fff; - text-transform: uppercase; - border-radius: 4px; - padding: 15px 25px; - text-decoration: none; - margin-top: 5px; - margin-bottom: 5px; -} -a.overview-btn:hover { - background: #2e729a; -} -a.overview-btn.left-btn { - border-top-right-radius: 0; - border-bottom-right-radius: 0; - border-right: 1px solid #3f81a7; - margin-right: 0; -} -a.overview-btn.right-btn { - border-top-left-radius: 0; - border-bottom-left-radius: 0; - border-left: 1px solid #73b8e1; - margin-left: 0; -} -.release-text { - display: block; - text-align: left; - color: #636568; - font-size: 13px; -} -.overview-section .img-responsive { - max-width: 550px; -} -.overview-right { - text-align: center; -} -.control-cloud-graphic { - max-width: 600px; - margin: 0 auto 15px; -} -a.demo-link { - font-size: 13px; - font-weight: 400; - text-decoration: none; - color: #34789A; - background: #F0F9FE; - padding: 10px 25px; - border-radius: 4px; -} -a.demo-link:hover { - color: #34789A; - background: #CDD9E2; -} -a.demo-link i { - margin-left: 5px; - font-size: 14px; -} - -/*When Featured, Add Class .featured to .overview-section*/ -.overview-section.featured .overview-right { - background: #E8EEF5; - border-radius: 4px; - text-align: center; - padding: 20px; - margin-top: 50px; -} -@media (max-width: 1200px) { - .overview-section.featured .overview-right { - margin-top: 50px; - } -} -.overview-section.featured .overview-right h3 { - color: #3D84B6; - text-align: center; -} -.overview-section.featured .overview-right p { - color: #333; - font-size: 13px; -} -.overview-section.featured .overview-right img.promo-graphic { - max-width: 350px; - margin: 20px auto; -} - -/*End Overview Section*/ - -/*Customers Section*/ -.customers-row { - padding: 80px 0; - text-align: center; - background: #edf2f7; -} -.customers-row h2 { - text-transform: capitalize; - margin-bottom: 0; -} -.customer-logos-wrapper { - margin: 15px 0; -} -.customer-logos { - position: relative; - padding: 20px 0; -} -@media (max-width: 767px) { - .customer-logos { - position: relative; - padding: 20px 0; - width: 80%; - margin: 0 auto; - } -} -.logo-hover { - background: #dee2e8; - border-radius: 3px; -} -.logo-hover:after { - content: ' '; - height: 0; - position: absolute; - width: 0; - border: 10px solid transparent; - border-top-color: #dee2e8; - top: 100%; - left: 50%; - margin-left: -10px; -} -.customers-description { - margin: 40px 0; - color: #284d68; - text-align: center; -} -.customers-description p { - padding: 20px 50px; - border-top: 1px solid #dee2e8; - border-bottom: 1px solid #dee2e8; - display: inline; -} -@media (max-width: 767px) { - .customers-description p { - display: block; - } -} -.customers-action { - margin-top: 40px; - text-align: center; -} -a.customer-btn { - background: #2e729a; - color: #fff; - text-transform: uppercase; - border-radius: 4px; - padding: 15px 25px; - text-decoration: none; - border-style: none; -} -a.customer-btn:hover { - background: #173D5B; - color: #fff; -} - -/*When Featured, Add Class .featured to .customers-row*/ -.customers-row.featured .customer-logos-wrapper { - width: 50%; - max-width: 1000px; - margin: 40px 25% 0; - border-top: 1px solid #DDE3E8; - padding-top: 20px; -} -.customers-row.featured .customer-logos-wrapper hr { - color: #333; -} -.customers-row.featured .customer-logos img { - width: 90%; - max-width: 100px; -} -.customers-row.featured .customer-logos:hover { - background: none; -} -.customers-row.featured .customer-logos:hover:after { - display: none; -} -.customers-row.featured .customers-action { - margin-top: 0; -} -.customers-row.featured button.customer-btn { - background: none; - border-radius: 0; - padding: 0; - text-decoration: underline; - color: #2e729a; - text-transform: capitalize; -} -.featured-description { - width: 85%; - margin: 40px auto; -} -@media (max-width: 767px) { - iframe { - width: 90%; - } -} -/*End Customers Section*/ - -/*Community Section*/ -.community-section { - padding: 75px 0; - background: url('../images/community-bkgd.jpg') no-repeat center center; - background-size: cover; - min-height: 350px; -} -.community-section.featured { - background: url('../images/community-bkgd2.jpg') no-repeat center center; - background-size: cover; -} -.community-graphic { - max-width: 650px; - margin: 0 auto; -} -@media (max-width: 1200px) { - .community-graphic { - margin-bottom: 20px; - } -} -.community-section h2 { - color: #fff; -} -.community-section p { - color: #fff; -} -@media (max-width: 1200px) { - .community-section h2 { - text-align: center; - } - .community-section p { - text-align: center; - } -} -a.community-btn { - font-size: 16px; - font-weight: 400; - background: transparent; - border: 1px solid #fff; - border-radius: 3px; - margin-top: 10px; - padding: 8px 30px 8px 40px; - color: white; - float: left; -} -a.community-btn i { - margin-left: 10px; -} -a.community-btn:hover { - text-decoration: none; - background: rgba(255, 255, 255, 0.2); -} - -/*When Featured, add .featured to .community-section*/ -.community-section.featured h3 { - color: #fff; -} -@media (max-width: 1200px) { - .community-section.featured h3 { - text-align: center; - } -} -.designate-logo { - max-width: 302px; - margin: 50px 0 20px; -} -@media (max-width: 1200px) { - .designate-logo { - margin: 50px auto 20px; - } -} -.default-community { - background-color: rgba(5, 54, 86, 0.7); - border-radius: 4px; - padding: 30px; - text-align: center; -} -@media (max-width: 1200px) { - .default-community { - margin-top: 50px; - } -} -.default-community h2 { - margin-top: 0; -} -.community-graphic.small { - max-width: 450px; - margin: 20px auto; -} -a.featured-link { - display: block; - background: #b9301d; - padding: 10px 20px; - border-radius: 2px; - width: 80%; - text-decoration: none; - margin: 10px auto 0; - color: #fff; - font-weight: 600; -} -a.featured-link:hover { - text-decoration: none; - background: #831917; -} - -/*End Community Section*/ - -/*News and Events Section*/ -.news-section { - padding: 70px 0; -} -.news-section h2 a { - font-size: 14px; - color: #559bc4; - font-weight: 400; - margin-left: 30px; -} -.news-section h2 a:hover { - color: #28709a; - text-decoration: none; -} -.event-ad, .news-ad { - width: 100%; - max-width: 560px; - margin-bottom: 20px; -} -.news-wrapper { - /*float: left;*/ -} -.news-section .news-wrapper ul { - margin: 30px 0; - padding-start: 0; - -webkit-padding-start: 0; -} -.news-section .news-wrapper ul li { - list-style: none; -} -.single-event, .eventBlock .event { - float: left; - width: 100%; - padding: 15px 10px; - border-bottom: 1px solid #ebeff4; -} -.single-event:hover, .eventBlock .event:hover { - background: #f9f9f9; -} -.single-event.last, .eventBlock .event.last { - border-bottom: none; -} -.left-event { - float: left; - width: 20%; -} -@media (min-width: 768px) and (max-width: 981px) { - .left-event { - width: 25%; - } -} -@media (max-width: 767px) { - .left-event { - width: 15%; - } -} -.event-details { - float: left; - margin-left: 3%; - width: 62%; -} -@media (min-width: 768px) and (max-width: 981px) { - .event-details { - width: 72%; - } -} -.right-event { - float: right; - width: 13%; -} -@media (min-width: 768px) and (max-width: 981px) { - .right-event { - display: none; - } -} -.date, .news-type, .planet-type { - background: #fff; - border: 2px solid #b9301d; - border-radius: 4px; - padding: 5px 15px; - color: #b9301d; - font-size: 10px; - width: 100%; - text-align: center; - float: left; - margin-top: 5px; -} -.event-name, .news-title { - display: block; - font-size: 14px; - font-weight: 600; - color: #333; - width: 100%; - white-space: nowrap; - overflow: hidden; - text-overflow: ellipsis; -} -.location, .news-date { - display: block; - float: left; - font-style: italic; - color: #333; - font-weight: 300; -} -.right-arrow { - float: right; - background: #d9dfe5; - border-radius: 100px; - width: 30px; - height: 30px; - padding: 6px 10px; - color: #fff; - margin-right: 10px; - margin-top: 5px; - display: none; -} -.single-event:hover .right-arrow { - display: block; -} -.news-type { - border: 2px solid #2a4d67; - color: #2a4d67; -} -.planet-type { - border: 2px solid #74c99f; - color: #74c99f; -} -.see-more-bottom { - width: 100%; - float: left; - text-align: center; - margin-top: 40px; -} -.see-more-bottom a { - color: #2e729a; - text-decoration: none; - padding: 5px 15px; - border-radius: 4px; - background: ; - font-size: 12px; - font-weight: 400; - border: 2px solid #2e729a; -} -.see-more-bottom a i { - margin-left: 10px; - font-size: 11px; -} -/*End News and Events Section*/ - -/*Photo Row*/ -.photo-row-wrapper { - width: 100%; - color: #eee; - max-height: 240px; - margin: 80px 0 10px; - overflow: hidden; -} -@media (max-width: 765px) { - .photo-row-wrapper { - display: none; - } -} -.photo-container { - width: 4000px; - max-height: 240px; - margin-left: -30px; -} -.photo-container img { - margin: 0 10px 0 0; - max-width: 22%; - max-height: 240px; -} - -/*End Photo Row*/ - -/*Footer*/ -footer { - background: #333333; - padding: 70px 0; -} -.footer-links h3 { - color: #fff; - font-size: 14px; - font-weight: 400; -} -.footer-links ul { - margin-left: 0; - padding-start: 0; - -webkit-padding-start: 0; -} -.footer-links ul li a { - color: #aaa; - font-size: 12px; - font-weight: 400; - list-style: none; - margin-left: 0; -} -.social-icons { - width: 40px; - min-height: 40px; - display: inline-block; - margin-right: 10px; -} -.footer-twitter { - background: url('../images/footer-twitter.png') no-repeat; -} -.footer-twitter:hover { - background: url('../images/footer-twitter-hover.png') no-repeat; -} -.footer-facebook { - background: url('../images/footer-facebook.png') no-repeat; -} -.footer-facebook:hover { - background: url('../images/footer-facebook-hover.png') no-repeat; -} -.footer-linkedin { - background: url('../images/footer-linkedin.png') no-repeat; -} -.footer-linkedin:hover { - background: url('../images/footer-linkedin-hover.png') no-repeat; -} -.footer-youtube { - background: url('../images/footer-youtube.png') no-repeat; -} -.footer-youtube:hover { - background: url('../images/footer-youtube-hover.png') no-repeat; -} -.newsletter-form { - margin: 10px 0 30px; - width: 100%; -} -.newsletter-form label { - color: #aaa; - font-size: 12px; - font-weight: 300; - display: block; -} -.newsletter-input { - display: inline-block; - background: transparent; - border: 2px solid #888; - border-radius: 4px; - color: #888; - font-size: 12px; - font-weight: 400; - padding: 10px 15px; - width: 70%; -} -@media (max-width: 767px) { - .newsletter-input { - width: 70%; - } -} -.newsletter-input::-webkit-input-placeholder { - color: #888; - font-size: 12px; - font-weight: 400; - text-transform: uppercase; -} - -.newsletter-input:-moz-placeholder { /* Firefox 18- */ - color: #888; - font-size: 12px; - font-weight: 400; - text-transform: uppercase; -} - -.newsletter-input::-moz-placeholder { /* Firefox 19+ */ - color: #888; - font-size: 12px; - font-weight: 400; - text-transform: uppercase; -} - -.newsletter-input:-ms-input-placeholder { - color: #888; - font-size: 12px; - font-weight: 400; - text-transform: uppercase; -} -.newsletter-input:focus { - outline: none; - border: 2px solid #666; -} -.newsletter-btn { - margin-left: 1%; - display: inline-block; - background: transparent; - border: 2px solid #4c97c3; - border-radius: 4px; - color: #4c97c3; - font-size: 12px; - font-weight: 400; - padding: 10px 15px; - text-transform: uppercase; - width: 27%; -} -@media (max-width: 767px) { - .newsletter-btn { - width: 18%; - margin-left: 2%; - padding: 10px; - } -} -.newsletter-btn:hover { - border: 2px solid #888; - color: #999; -} -.fine-print { - margin-top: 20px; - color: #aaa; - font-size: 12px; -} -.fine-print a { - color: #aaa; - text-decoration: underline; -} -.fine-print a:hover { - color: #fff; -} -.footer-bottom { - background: #222; - padding: 15px 0; - text-align: center; - width: 100%; -} -.feedback-input { - display: inline-block; - background: #222; - border: 2px solid #444; - border-radius: 4px; - color: #777; - font-size: 12px; - font-weight: 400; - padding: 10px 20px; - width: 310px; -} -@media (max-width: 767px) { - .feedback-input { - width: 70%; - } -} -.feedback-input::-webkit-input-placeholder { - color: #555; - font-size: 12px; - font-weight: 400; -} - -.feedback-input:-moz-placeholder { /* Firefox 18- */ - color: #555; - font-size: 12px; - font-weight: 400; -} - -.feedback-input::-moz-placeholder { /* Firefox 19+ */ - color: #555; - font-size: 12px; - font-weight: 400; -} - -.feedback-input:-ms-input-placeholder { - color: #555; - font-size: 12px; - font-weight: 400; -} -.feedback-input:focus { - outline: none; - border: 2px solid #666; -} -.feedback-btn { - margin-left: 11px; - display: inline-block; - background: #222; - border: 2px solid #666; - border-radius: 4px; - color: #777; - font-size: 12px; - font-weight: 400; - padding: 10px 30px; -} -@media (max-width: 767px) { - .feedback-btn { - width: 18%; - margin-left: 2%; - padding: 10px; - } -} -.feedback-btn:hover { - border: 2px solid #888; - color: #999; -} -/*End Footer*/ - -/*General Inner Page Styles*/ -.navbar-default.inner { - border-bottom: 1px solid #ddd; -} - -/*End General Inner Page Styles*/ - -/*Events Page*/ -.eventsBanner { - height: 150px; - padding: 20px -} -.eventsPhotoCaption { - background: rgba(0,0,0,0.3); - border-radius: 4px; - padding: 10px; - color: white; -} -.news-section.full { - padding: 20px 0; -} -.eventTitleArea { - text-align: center; - margin: 40px 0; -} -.eventTitleArea h1 { - color: #333; - font-weight: 300; -} -.postEvent { - float: left; - width: 100%; - height: 130px; - padding: 30px 5%; - background: #F4F5F8; - margin: 20px 0 10px; - text-align: center; -} -.postEvent p { - margin-bottom: 20px; -} -.postEvent a { - background: #2e729a; - padding: 10px 25px; - border-radius: 4px; - color: #fff; -} -.eventBlock { - float: left; - width: 100%; -} -.eventBlock.summit .date { - border-color: #255E88; - color: #255E88 ; -} -.eventBlock.past h2 { - margin-top: 50px; -} -.eventBlock.past .date { - border-color: #555; - color: #555; -} -.eventButton a { - -} -/*End Events Page*/ - -/*Community Page*/ -.communityBoxes { - margin: 30px 0 10px; - font-size: 13px; -} -.communityBoxes h2 { - font-size: 20px; - font-weight: 400; - margin-bottom: 15px; -} -.communityBoxes h2 a { - color: #CD281E; -} -.developersRow { - border-top: 1px solid #eee; - border-bottom: 1px solid #eee; - padding: 20px 30px; - margin-bottom: 30px; -} -.devLabel { - float: left; - margin-right: 30px; - font-weight: 700; -} -ul#developerActivity { - float: left; - padding-left: 0; - margin: 0; -} -ul#developerActivity li { - list-style: none; - display: inline-block; -} -ul#developerActivity li a { - font-weight: 700; - color: #222; -} -ul#developerActivity li span { - background: #E8EEF5; - padding: 5px 10px; - border-radius: 4px; - margin-right: 5px; - color: #255E88; - font-size: 11px; - font-weight: 400; -} -/*End Community Page*/ diff --git a/_templates/openstackdocs/static/favicon.ico b/_templates/openstackdocs/static/favicon.ico deleted file mode 100644 index f3b9bf9c4..000000000 Binary files a/_templates/openstackdocs/static/favicon.ico and /dev/null differ diff --git a/_templates/openstackdocs/static/images/docs/license.png b/_templates/openstackdocs/static/images/docs/license.png deleted file mode 100644 index 822491edb..000000000 Binary files a/_templates/openstackdocs/static/images/docs/license.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/docs/superuser1.png b/_templates/openstackdocs/static/images/docs/superuser1.png deleted file mode 100644 index 5c8fa0116..000000000 Binary files a/_templates/openstackdocs/static/images/docs/superuser1.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/docs/superuser2.png b/_templates/openstackdocs/static/images/docs/superuser2.png deleted file mode 100644 index a4d669140..000000000 Binary files a/_templates/openstackdocs/static/images/docs/superuser2.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/docs/superuser3.png b/_templates/openstackdocs/static/images/docs/superuser3.png deleted file mode 100644 index b07e9fe0d..000000000 Binary files a/_templates/openstackdocs/static/images/docs/superuser3.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/docs/superuser4.png b/_templates/openstackdocs/static/images/docs/superuser4.png deleted file mode 100644 index 1563fef23..000000000 Binary files a/_templates/openstackdocs/static/images/docs/superuser4.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/footer-facebook-hover.png b/_templates/openstackdocs/static/images/footer-facebook-hover.png deleted file mode 100644 index 89bb5d15e..000000000 Binary files a/_templates/openstackdocs/static/images/footer-facebook-hover.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/footer-facebook.png b/_templates/openstackdocs/static/images/footer-facebook.png deleted file mode 100644 index 531d98878..000000000 Binary files a/_templates/openstackdocs/static/images/footer-facebook.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/footer-linkedin-hover.png b/_templates/openstackdocs/static/images/footer-linkedin-hover.png deleted file mode 100644 index b403e446f..000000000 Binary files a/_templates/openstackdocs/static/images/footer-linkedin-hover.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/footer-linkedin.png b/_templates/openstackdocs/static/images/footer-linkedin.png deleted file mode 100644 index 5394b72da..000000000 Binary files a/_templates/openstackdocs/static/images/footer-linkedin.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/footer-twitter-hover.png b/_templates/openstackdocs/static/images/footer-twitter-hover.png deleted file mode 100644 index 44f1e75d1..000000000 Binary files a/_templates/openstackdocs/static/images/footer-twitter-hover.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/footer-twitter.png b/_templates/openstackdocs/static/images/footer-twitter.png deleted file mode 100644 index b0aa366d4..000000000 Binary files a/_templates/openstackdocs/static/images/footer-twitter.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/footer-youtube-hover.png b/_templates/openstackdocs/static/images/footer-youtube-hover.png deleted file mode 100644 index 615339fd2..000000000 Binary files a/_templates/openstackdocs/static/images/footer-youtube-hover.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/footer-youtube.png b/_templates/openstackdocs/static/images/footer-youtube.png deleted file mode 100644 index de9bc49cb..000000000 Binary files a/_templates/openstackdocs/static/images/footer-youtube.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/loading.gif b/_templates/openstackdocs/static/images/loading.gif deleted file mode 100644 index 6a56815b2..000000000 Binary files a/_templates/openstackdocs/static/images/loading.gif and /dev/null differ diff --git a/_templates/openstackdocs/static/images/openstack-logo-full.png b/_templates/openstackdocs/static/images/openstack-logo-full.png deleted file mode 100644 index 60ab0e1eb..000000000 Binary files a/_templates/openstackdocs/static/images/openstack-logo-full.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/openstack-logo-full.svg b/_templates/openstackdocs/static/images/openstack-logo-full.svg deleted file mode 100644 index a2ca0b554..000000000 --- a/_templates/openstackdocs/static/images/openstack-logo-full.svg +++ /dev/null @@ -1,285 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/_templates/openstackdocs/static/images/openstack-logo-vert.png b/_templates/openstackdocs/static/images/openstack-logo-vert.png deleted file mode 100644 index a705b59bc..000000000 Binary files a/_templates/openstackdocs/static/images/openstack-logo-vert.png and /dev/null differ diff --git a/_templates/openstackdocs/static/images/openstack-logo-vert.svg b/_templates/openstackdocs/static/images/openstack-logo-vert.svg deleted file mode 100644 index dcade04c3..000000000 --- a/_templates/openstackdocs/static/images/openstack-logo-vert.svg +++ /dev/null @@ -1,286 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/_templates/openstackdocs/static/images/search-icon.png b/_templates/openstackdocs/static/images/search-icon.png deleted file mode 100644 index dfd5bb9f9..000000000 Binary files a/_templates/openstackdocs/static/images/search-icon.png and /dev/null differ diff --git a/_templates/openstackdocs/static/js/bootstrap.min.js b/_templates/openstackdocs/static/js/bootstrap.min.js deleted file mode 100644 index 7c1561a8b..000000000 --- a/_templates/openstackdocs/static/js/bootstrap.min.js +++ /dev/null @@ -1,6 +0,0 @@ -/*! - * Bootstrap v3.2.0 (http://getbootstrap.com) - * Copyright 2011-2014 Twitter, Inc. - * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE) - */ -if("undefined"==typeof jQuery)throw new Error("Bootstrap's JavaScript requires jQuery");+function(a){"use strict";function b(){var a=document.createElement("bootstrap"),b={WebkitTransition:"webkitTransitionEnd",MozTransition:"transitionend",OTransition:"oTransitionEnd otransitionend",transition:"transitionend"};for(var c in b)if(void 0!==a.style[c])return{end:b[c]};return!1}a.fn.emulateTransitionEnd=function(b){var c=!1,d=this;a(this).one("bsTransitionEnd",function(){c=!0});var e=function(){c||a(d).trigger(a.support.transition.end)};return setTimeout(e,b),this},a(function(){a.support.transition=b(),a.support.transition&&(a.event.special.bsTransitionEnd={bindType:a.support.transition.end,delegateType:a.support.transition.end,handle:function(b){return a(b.target).is(this)?b.handleObj.handler.apply(this,arguments):void 0}})})}(jQuery),+function(a){"use strict";function b(b){return this.each(function(){var c=a(this),e=c.data("bs.alert");e||c.data("bs.alert",e=new d(this)),"string"==typeof b&&e[b].call(c)})}var c='[data-dismiss="alert"]',d=function(b){a(b).on("click",c,this.close)};d.VERSION="3.2.0",d.prototype.close=function(b){function c(){f.detach().trigger("closed.bs.alert").remove()}var d=a(this),e=d.attr("data-target");e||(e=d.attr("href"),e=e&&e.replace(/.*(?=#[^\s]*$)/,""));var f=a(e);b&&b.preventDefault(),f.length||(f=d.hasClass("alert")?d:d.parent()),f.trigger(b=a.Event("close.bs.alert")),b.isDefaultPrevented()||(f.removeClass("in"),a.support.transition&&f.hasClass("fade")?f.one("bsTransitionEnd",c).emulateTransitionEnd(150):c())};var e=a.fn.alert;a.fn.alert=b,a.fn.alert.Constructor=d,a.fn.alert.noConflict=function(){return a.fn.alert=e,this},a(document).on("click.bs.alert.data-api",c,d.prototype.close)}(jQuery),+function(a){"use strict";function b(b){return this.each(function(){var d=a(this),e=d.data("bs.button"),f="object"==typeof b&&b;e||d.data("bs.button",e=new c(this,f)),"toggle"==b?e.toggle():b&&e.setState(b)})}var c=function(b,d){this.$element=a(b),this.options=a.extend({},c.DEFAULTS,d),this.isLoading=!1};c.VERSION="3.2.0",c.DEFAULTS={loadingText:"loading..."},c.prototype.setState=function(b){var c="disabled",d=this.$element,e=d.is("input")?"val":"html",f=d.data();b+="Text",null==f.resetText&&d.data("resetText",d[e]()),d[e](null==f[b]?this.options[b]:f[b]),setTimeout(a.proxy(function(){"loadingText"==b?(this.isLoading=!0,d.addClass(c).attr(c,c)):this.isLoading&&(this.isLoading=!1,d.removeClass(c).removeAttr(c))},this),0)},c.prototype.toggle=function(){var a=!0,b=this.$element.closest('[data-toggle="buttons"]');if(b.length){var c=this.$element.find("input");"radio"==c.prop("type")&&(c.prop("checked")&&this.$element.hasClass("active")?a=!1:b.find(".active").removeClass("active")),a&&c.prop("checked",!this.$element.hasClass("active")).trigger("change")}a&&this.$element.toggleClass("active")};var d=a.fn.button;a.fn.button=b,a.fn.button.Constructor=c,a.fn.button.noConflict=function(){return a.fn.button=d,this},a(document).on("click.bs.button.data-api",'[data-toggle^="button"]',function(c){var d=a(c.target);d.hasClass("btn")||(d=d.closest(".btn")),b.call(d,"toggle"),c.preventDefault()})}(jQuery),+function(a){"use strict";function b(b){return this.each(function(){var d=a(this),e=d.data("bs.carousel"),f=a.extend({},c.DEFAULTS,d.data(),"object"==typeof b&&b),g="string"==typeof b?b:f.slide;e||d.data("bs.carousel",e=new c(this,f)),"number"==typeof b?e.to(b):g?e[g]():f.interval&&e.pause().cycle()})}var c=function(b,c){this.$element=a(b).on("keydown.bs.carousel",a.proxy(this.keydown,this)),this.$indicators=this.$element.find(".carousel-indicators"),this.options=c,this.paused=this.sliding=this.interval=this.$active=this.$items=null,"hover"==this.options.pause&&this.$element.on("mouseenter.bs.carousel",a.proxy(this.pause,this)).on("mouseleave.bs.carousel",a.proxy(this.cycle,this))};c.VERSION="3.2.0",c.DEFAULTS={interval:5e3,pause:"hover",wrap:!0},c.prototype.keydown=function(a){switch(a.which){case 37:this.prev();break;case 39:this.next();break;default:return}a.preventDefault()},c.prototype.cycle=function(b){return b||(this.paused=!1),this.interval&&clearInterval(this.interval),this.options.interval&&!this.paused&&(this.interval=setInterval(a.proxy(this.next,this),this.options.interval)),this},c.prototype.getItemIndex=function(a){return this.$items=a.parent().children(".item"),this.$items.index(a||this.$active)},c.prototype.to=function(b){var c=this,d=this.getItemIndex(this.$active=this.$element.find(".item.active"));return b>this.$items.length-1||0>b?void 0:this.sliding?this.$element.one("slid.bs.carousel",function(){c.to(b)}):d==b?this.pause().cycle():this.slide(b>d?"next":"prev",a(this.$items[b]))},c.prototype.pause=function(b){return b||(this.paused=!0),this.$element.find(".next, .prev").length&&a.support.transition&&(this.$element.trigger(a.support.transition.end),this.cycle(!0)),this.interval=clearInterval(this.interval),this},c.prototype.next=function(){return this.sliding?void 0:this.slide("next")},c.prototype.prev=function(){return this.sliding?void 0:this.slide("prev")},c.prototype.slide=function(b,c){var d=this.$element.find(".item.active"),e=c||d[b](),f=this.interval,g="next"==b?"left":"right",h="next"==b?"first":"last",i=this;if(!e.length){if(!this.options.wrap)return;e=this.$element.find(".item")[h]()}if(e.hasClass("active"))return this.sliding=!1;var j=e[0],k=a.Event("slide.bs.carousel",{relatedTarget:j,direction:g});if(this.$element.trigger(k),!k.isDefaultPrevented()){if(this.sliding=!0,f&&this.pause(),this.$indicators.length){this.$indicators.find(".active").removeClass("active");var l=a(this.$indicators.children()[this.getItemIndex(e)]);l&&l.addClass("active")}var m=a.Event("slid.bs.carousel",{relatedTarget:j,direction:g});return a.support.transition&&this.$element.hasClass("slide")?(e.addClass(b),e[0].offsetWidth,d.addClass(g),e.addClass(g),d.one("bsTransitionEnd",function(){e.removeClass([b,g].join(" ")).addClass("active"),d.removeClass(["active",g].join(" ")),i.sliding=!1,setTimeout(function(){i.$element.trigger(m)},0)}).emulateTransitionEnd(1e3*d.css("transition-duration").slice(0,-1))):(d.removeClass("active"),e.addClass("active"),this.sliding=!1,this.$element.trigger(m)),f&&this.cycle(),this}};var d=a.fn.carousel;a.fn.carousel=b,a.fn.carousel.Constructor=c,a.fn.carousel.noConflict=function(){return a.fn.carousel=d,this},a(document).on("click.bs.carousel.data-api","[data-slide], [data-slide-to]",function(c){var d,e=a(this),f=a(e.attr("data-target")||(d=e.attr("href"))&&d.replace(/.*(?=#[^\s]+$)/,""));if(f.hasClass("carousel")){var g=a.extend({},f.data(),e.data()),h=e.attr("data-slide-to");h&&(g.interval=!1),b.call(f,g),h&&f.data("bs.carousel").to(h),c.preventDefault()}}),a(window).on("load",function(){a('[data-ride="carousel"]').each(function(){var c=a(this);b.call(c,c.data())})})}(jQuery),+function(a){"use strict";function b(b){return this.each(function(){var d=a(this),e=d.data("bs.collapse"),f=a.extend({},c.DEFAULTS,d.data(),"object"==typeof b&&b);!e&&f.toggle&&"show"==b&&(b=!b),e||d.data("bs.collapse",e=new c(this,f)),"string"==typeof b&&e[b]()})}var c=function(b,d){this.$element=a(b),this.options=a.extend({},c.DEFAULTS,d),this.transitioning=null,this.options.parent&&(this.$parent=a(this.options.parent)),this.options.toggle&&this.toggle()};c.VERSION="3.2.0",c.DEFAULTS={toggle:!0},c.prototype.dimension=function(){var a=this.$element.hasClass("width");return a?"width":"height"},c.prototype.show=function(){if(!this.transitioning&&!this.$element.hasClass("in")){var c=a.Event("show.bs.collapse");if(this.$element.trigger(c),!c.isDefaultPrevented()){var d=this.$parent&&this.$parent.find("> .panel > .in");if(d&&d.length){var e=d.data("bs.collapse");if(e&&e.transitioning)return;b.call(d,"hide"),e||d.data("bs.collapse",null)}var f=this.dimension();this.$element.removeClass("collapse").addClass("collapsing")[f](0),this.transitioning=1;var g=function(){this.$element.removeClass("collapsing").addClass("collapse in")[f](""),this.transitioning=0,this.$element.trigger("shown.bs.collapse")};if(!a.support.transition)return g.call(this);var h=a.camelCase(["scroll",f].join("-"));this.$element.one("bsTransitionEnd",a.proxy(g,this)).emulateTransitionEnd(350)[f](this.$element[0][h])}}},c.prototype.hide=function(){if(!this.transitioning&&this.$element.hasClass("in")){var b=a.Event("hide.bs.collapse");if(this.$element.trigger(b),!b.isDefaultPrevented()){var c=this.dimension();this.$element[c](this.$element[c]())[0].offsetHeight,this.$element.addClass("collapsing").removeClass("collapse").removeClass("in"),this.transitioning=1;var d=function(){this.transitioning=0,this.$element.trigger("hidden.bs.collapse").removeClass("collapsing").addClass("collapse")};return a.support.transition?void this.$element[c](0).one("bsTransitionEnd",a.proxy(d,this)).emulateTransitionEnd(350):d.call(this)}}},c.prototype.toggle=function(){this[this.$element.hasClass("in")?"hide":"show"]()};var d=a.fn.collapse;a.fn.collapse=b,a.fn.collapse.Constructor=c,a.fn.collapse.noConflict=function(){return a.fn.collapse=d,this},a(document).on("click.bs.collapse.data-api",'[data-toggle="collapse"]',function(c){var d,e=a(this),f=e.attr("data-target")||c.preventDefault()||(d=e.attr("href"))&&d.replace(/.*(?=#[^\s]+$)/,""),g=a(f),h=g.data("bs.collapse"),i=h?"toggle":e.data(),j=e.attr("data-parent"),k=j&&a(j);h&&h.transitioning||(k&&k.find('[data-toggle="collapse"][data-parent="'+j+'"]').not(e).addClass("collapsed"),e[g.hasClass("in")?"addClass":"removeClass"]("collapsed")),b.call(g,i)})}(jQuery),+function(a){"use strict";function b(b){b&&3===b.which||(a(e).remove(),a(f).each(function(){var d=c(a(this)),e={relatedTarget:this};d.hasClass("open")&&(d.trigger(b=a.Event("hide.bs.dropdown",e)),b.isDefaultPrevented()||d.removeClass("open").trigger("hidden.bs.dropdown",e))}))}function c(b){var c=b.attr("data-target");c||(c=b.attr("href"),c=c&&/#[A-Za-z]/.test(c)&&c.replace(/.*(?=#[^\s]*$)/,""));var d=c&&a(c);return d&&d.length?d:b.parent()}function d(b){return this.each(function(){var c=a(this),d=c.data("bs.dropdown");d||c.data("bs.dropdown",d=new g(this)),"string"==typeof b&&d[b].call(c)})}var e=".dropdown-backdrop",f='[data-toggle="dropdown"]',g=function(b){a(b).on("click.bs.dropdown",this.toggle)};g.VERSION="3.2.0",g.prototype.toggle=function(d){var e=a(this);if(!e.is(".disabled, :disabled")){var f=c(e),g=f.hasClass("open");if(b(),!g){"ontouchstart"in document.documentElement&&!f.closest(".navbar-nav").length&&a('
').insertAfter(a(this)).on("click",b);var h={relatedTarget:this};if(f.trigger(d=a.Event("show.bs.dropdown",h)),d.isDefaultPrevented())return;e.trigger("focus"),f.toggleClass("open").trigger("shown.bs.dropdown",h)}return!1}},g.prototype.keydown=function(b){if(/(38|40|27)/.test(b.keyCode)){var d=a(this);if(b.preventDefault(),b.stopPropagation(),!d.is(".disabled, :disabled")){var e=c(d),g=e.hasClass("open");if(!g||g&&27==b.keyCode)return 27==b.which&&e.find(f).trigger("focus"),d.trigger("click");var h=" li:not(.divider):visible a",i=e.find('[role="menu"]'+h+', [role="listbox"]'+h);if(i.length){var j=i.index(i.filter(":focus"));38==b.keyCode&&j>0&&j--,40==b.keyCode&&j').appendTo(this.$body),this.$element.on("click.dismiss.bs.modal",a.proxy(function(a){a.target===a.currentTarget&&("static"==this.options.backdrop?this.$element[0].focus.call(this.$element[0]):this.hide.call(this))},this)),e&&this.$backdrop[0].offsetWidth,this.$backdrop.addClass("in"),!b)return;e?this.$backdrop.one("bsTransitionEnd",b).emulateTransitionEnd(150):b()}else if(!this.isShown&&this.$backdrop){this.$backdrop.removeClass("in");var f=function(){c.removeBackdrop(),b&&b()};a.support.transition&&this.$element.hasClass("fade")?this.$backdrop.one("bsTransitionEnd",f).emulateTransitionEnd(150):f()}else b&&b()},c.prototype.checkScrollbar=function(){document.body.clientWidth>=window.innerWidth||(this.scrollbarWidth=this.scrollbarWidth||this.measureScrollbar())},c.prototype.setScrollbar=function(){var a=parseInt(this.$body.css("padding-right")||0,10);this.scrollbarWidth&&this.$body.css("padding-right",a+this.scrollbarWidth)},c.prototype.resetScrollbar=function(){this.$body.css("padding-right","")},c.prototype.measureScrollbar=function(){var a=document.createElement("div");a.className="modal-scrollbar-measure",this.$body.append(a);var b=a.offsetWidth-a.clientWidth;return this.$body[0].removeChild(a),b};var d=a.fn.modal;a.fn.modal=b,a.fn.modal.Constructor=c,a.fn.modal.noConflict=function(){return a.fn.modal=d,this},a(document).on("click.bs.modal.data-api",'[data-toggle="modal"]',function(c){var d=a(this),e=d.attr("href"),f=a(d.attr("data-target")||e&&e.replace(/.*(?=#[^\s]+$)/,"")),g=f.data("bs.modal")?"toggle":a.extend({remote:!/#/.test(e)&&e},f.data(),d.data());d.is("a")&&c.preventDefault(),f.one("show.bs.modal",function(a){a.isDefaultPrevented()||f.one("hidden.bs.modal",function(){d.is(":visible")&&d.trigger("focus")})}),b.call(f,g,this)})}(jQuery),+function(a){"use strict";function b(b){return this.each(function(){var d=a(this),e=d.data("bs.tooltip"),f="object"==typeof b&&b;(e||"destroy"!=b)&&(e||d.data("bs.tooltip",e=new c(this,f)),"string"==typeof b&&e[b]())})}var c=function(a,b){this.type=this.options=this.enabled=this.timeout=this.hoverState=this.$element=null,this.init("tooltip",a,b)};c.VERSION="3.2.0",c.DEFAULTS={animation:!0,placement:"top",selector:!1,template:'',trigger:"hover focus",title:"",delay:0,html:!1,container:!1,viewport:{selector:"body",padding:0}},c.prototype.init=function(b,c,d){this.enabled=!0,this.type=b,this.$element=a(c),this.options=this.getOptions(d),this.$viewport=this.options.viewport&&a(this.options.viewport.selector||this.options.viewport);for(var e=this.options.trigger.split(" "),f=e.length;f--;){var g=e[f];if("click"==g)this.$element.on("click."+this.type,this.options.selector,a.proxy(this.toggle,this));else if("manual"!=g){var h="hover"==g?"mouseenter":"focusin",i="hover"==g?"mouseleave":"focusout";this.$element.on(h+"."+this.type,this.options.selector,a.proxy(this.enter,this)),this.$element.on(i+"."+this.type,this.options.selector,a.proxy(this.leave,this))}}this.options.selector?this._options=a.extend({},this.options,{trigger:"manual",selector:""}):this.fixTitle()},c.prototype.getDefaults=function(){return c.DEFAULTS},c.prototype.getOptions=function(b){return b=a.extend({},this.getDefaults(),this.$element.data(),b),b.delay&&"number"==typeof b.delay&&(b.delay={show:b.delay,hide:b.delay}),b},c.prototype.getDelegateOptions=function(){var b={},c=this.getDefaults();return this._options&&a.each(this._options,function(a,d){c[a]!=d&&(b[a]=d)}),b},c.prototype.enter=function(b){var c=b instanceof this.constructor?b:a(b.currentTarget).data("bs."+this.type);return c||(c=new this.constructor(b.currentTarget,this.getDelegateOptions()),a(b.currentTarget).data("bs."+this.type,c)),clearTimeout(c.timeout),c.hoverState="in",c.options.delay&&c.options.delay.show?void(c.timeout=setTimeout(function(){"in"==c.hoverState&&c.show()},c.options.delay.show)):c.show()},c.prototype.leave=function(b){var c=b instanceof this.constructor?b:a(b.currentTarget).data("bs."+this.type);return c||(c=new this.constructor(b.currentTarget,this.getDelegateOptions()),a(b.currentTarget).data("bs."+this.type,c)),clearTimeout(c.timeout),c.hoverState="out",c.options.delay&&c.options.delay.hide?void(c.timeout=setTimeout(function(){"out"==c.hoverState&&c.hide()},c.options.delay.hide)):c.hide()},c.prototype.show=function(){var b=a.Event("show.bs."+this.type);if(this.hasContent()&&this.enabled){this.$element.trigger(b);var c=a.contains(document.documentElement,this.$element[0]);if(b.isDefaultPrevented()||!c)return;var d=this,e=this.tip(),f=this.getUID(this.type);this.setContent(),e.attr("id",f),this.$element.attr("aria-describedby",f),this.options.animation&&e.addClass("fade");var g="function"==typeof this.options.placement?this.options.placement.call(this,e[0],this.$element[0]):this.options.placement,h=/\s?auto?\s?/i,i=h.test(g);i&&(g=g.replace(h,"")||"top"),e.detach().css({top:0,left:0,display:"block"}).addClass(g).data("bs."+this.type,this),this.options.container?e.appendTo(this.options.container):e.insertAfter(this.$element);var j=this.getPosition(),k=e[0].offsetWidth,l=e[0].offsetHeight;if(i){var m=g,n=this.$element.parent(),o=this.getPosition(n);g="bottom"==g&&j.top+j.height+l-o.scroll>o.height?"top":"top"==g&&j.top-o.scroll-l<0?"bottom":"right"==g&&j.right+k>o.width?"left":"left"==g&&j.left-kg.top+g.height&&(e.top=g.top+g.height-i)}else{var j=b.left-f,k=b.left+f+c;jg.width&&(e.left=g.left+g.width-k)}return e},c.prototype.getTitle=function(){var a,b=this.$element,c=this.options;return a=b.attr("data-original-title")||("function"==typeof c.title?c.title.call(b[0]):c.title)},c.prototype.getUID=function(a){do a+=~~(1e6*Math.random());while(document.getElementById(a));return a},c.prototype.tip=function(){return this.$tip=this.$tip||a(this.options.template)},c.prototype.arrow=function(){return this.$arrow=this.$arrow||this.tip().find(".tooltip-arrow")},c.prototype.validate=function(){this.$element[0].parentNode||(this.hide(),this.$element=null,this.options=null)},c.prototype.enable=function(){this.enabled=!0},c.prototype.disable=function(){this.enabled=!1},c.prototype.toggleEnabled=function(){this.enabled=!this.enabled},c.prototype.toggle=function(b){var c=this;b&&(c=a(b.currentTarget).data("bs."+this.type),c||(c=new this.constructor(b.currentTarget,this.getDelegateOptions()),a(b.currentTarget).data("bs."+this.type,c))),c.tip().hasClass("in")?c.leave(c):c.enter(c)},c.prototype.destroy=function(){clearTimeout(this.timeout),this.hide().$element.off("."+this.type).removeData("bs."+this.type)};var d=a.fn.tooltip;a.fn.tooltip=b,a.fn.tooltip.Constructor=c,a.fn.tooltip.noConflict=function(){return a.fn.tooltip=d,this}}(jQuery),+function(a){"use strict";function b(b){return this.each(function(){var d=a(this),e=d.data("bs.popover"),f="object"==typeof b&&b;(e||"destroy"!=b)&&(e||d.data("bs.popover",e=new c(this,f)),"string"==typeof b&&e[b]())})}var c=function(a,b){this.init("popover",a,b)};if(!a.fn.tooltip)throw new Error("Popover requires tooltip.js");c.VERSION="3.2.0",c.DEFAULTS=a.extend({},a.fn.tooltip.Constructor.DEFAULTS,{placement:"right",trigger:"click",content:"",template:''}),c.prototype=a.extend({},a.fn.tooltip.Constructor.prototype),c.prototype.constructor=c,c.prototype.getDefaults=function(){return c.DEFAULTS},c.prototype.setContent=function(){var a=this.tip(),b=this.getTitle(),c=this.getContent();a.find(".popover-title")[this.options.html?"html":"text"](b),a.find(".popover-content").empty()[this.options.html?"string"==typeof c?"html":"append":"text"](c),a.removeClass("fade top bottom left right in"),a.find(".popover-title").html()||a.find(".popover-title").hide()},c.prototype.hasContent=function(){return this.getTitle()||this.getContent()},c.prototype.getContent=function(){var a=this.$element,b=this.options;return a.attr("data-content")||("function"==typeof b.content?b.content.call(a[0]):b.content)},c.prototype.arrow=function(){return this.$arrow=this.$arrow||this.tip().find(".arrow")},c.prototype.tip=function(){return this.$tip||(this.$tip=a(this.options.template)),this.$tip};var d=a.fn.popover;a.fn.popover=b,a.fn.popover.Constructor=c,a.fn.popover.noConflict=function(){return a.fn.popover=d,this}}(jQuery),+function(a){"use strict";function b(c,d){var e=a.proxy(this.process,this);this.$body=a("body"),this.$scrollElement=a(a(c).is("body")?window:c),this.options=a.extend({},b.DEFAULTS,d),this.selector=(this.options.target||"")+" .nav li > a",this.offsets=[],this.targets=[],this.activeTarget=null,this.scrollHeight=0,this.$scrollElement.on("scroll.bs.scrollspy",e),this.refresh(),this.process()}function c(c){return this.each(function(){var d=a(this),e=d.data("bs.scrollspy"),f="object"==typeof c&&c;e||d.data("bs.scrollspy",e=new b(this,f)),"string"==typeof c&&e[c]()})}b.VERSION="3.2.0",b.DEFAULTS={offset:10},b.prototype.getScrollHeight=function(){return this.$scrollElement[0].scrollHeight||Math.max(this.$body[0].scrollHeight,document.documentElement.scrollHeight)},b.prototype.refresh=function(){var b="offset",c=0;a.isWindow(this.$scrollElement[0])||(b="position",c=this.$scrollElement.scrollTop()),this.offsets=[],this.targets=[],this.scrollHeight=this.getScrollHeight();var d=this;this.$body.find(this.selector).map(function(){var d=a(this),e=d.data("target")||d.attr("href"),f=/^#./.test(e)&&a(e);return f&&f.length&&f.is(":visible")&&[[f[b]().top+c,e]]||null}).sort(function(a,b){return a[0]-b[0]}).each(function(){d.offsets.push(this[0]),d.targets.push(this[1])})},b.prototype.process=function(){var a,b=this.$scrollElement.scrollTop()+this.options.offset,c=this.getScrollHeight(),d=this.options.offset+c-this.$scrollElement.height(),e=this.offsets,f=this.targets,g=this.activeTarget;if(this.scrollHeight!=c&&this.refresh(),b>=d)return g!=(a=f[f.length-1])&&this.activate(a);if(g&&b<=e[0])return g!=(a=f[0])&&this.activate(a);for(a=e.length;a--;)g!=f[a]&&b>=e[a]&&(!e[a+1]||b<=e[a+1])&&this.activate(f[a])},b.prototype.activate=function(b){this.activeTarget=b,a(this.selector).parentsUntil(this.options.target,".active").removeClass("active");var c=this.selector+'[data-target="'+b+'"],'+this.selector+'[href="'+b+'"]',d=a(c).parents("li").addClass("active");d.parent(".dropdown-menu").length&&(d=d.closest("li.dropdown").addClass("active")),d.trigger("activate.bs.scrollspy")};var d=a.fn.scrollspy;a.fn.scrollspy=c,a.fn.scrollspy.Constructor=b,a.fn.scrollspy.noConflict=function(){return a.fn.scrollspy=d,this},a(window).on("load.bs.scrollspy.data-api",function(){a('[data-spy="scroll"]').each(function(){var b=a(this);c.call(b,b.data())})})}(jQuery),+function(a){"use strict";function b(b){return this.each(function(){var d=a(this),e=d.data("bs.tab");e||d.data("bs.tab",e=new c(this)),"string"==typeof b&&e[b]()})}var c=function(b){this.element=a(b)};c.VERSION="3.2.0",c.prototype.show=function(){var b=this.element,c=b.closest("ul:not(.dropdown-menu)"),d=b.data("target");if(d||(d=b.attr("href"),d=d&&d.replace(/.*(?=#[^\s]*$)/,"")),!b.parent("li").hasClass("active")){var e=c.find(".active:last a")[0],f=a.Event("show.bs.tab",{relatedTarget:e});if(b.trigger(f),!f.isDefaultPrevented()){var g=a(d);this.activate(b.closest("li"),c),this.activate(g,g.parent(),function(){b.trigger({type:"shown.bs.tab",relatedTarget:e})})}}},c.prototype.activate=function(b,c,d){function e(){f.removeClass("active").find("> .dropdown-menu > .active").removeClass("active"),b.addClass("active"),g?(b[0].offsetWidth,b.addClass("in")):b.removeClass("fade"),b.parent(".dropdown-menu")&&b.closest("li.dropdown").addClass("active"),d&&d()}var f=c.find("> .active"),g=d&&a.support.transition&&f.hasClass("fade");g?f.one("bsTransitionEnd",e).emulateTransitionEnd(150):e(),f.removeClass("in")};var d=a.fn.tab;a.fn.tab=b,a.fn.tab.Constructor=c,a.fn.tab.noConflict=function(){return a.fn.tab=d,this},a(document).on("click.bs.tab.data-api",'[data-toggle="tab"], [data-toggle="pill"]',function(c){c.preventDefault(),b.call(a(this),"show")})}(jQuery),+function(a){"use strict";function b(b){return this.each(function(){var d=a(this),e=d.data("bs.affix"),f="object"==typeof b&&b;e||d.data("bs.affix",e=new c(this,f)),"string"==typeof b&&e[b]()})}var c=function(b,d){this.options=a.extend({},c.DEFAULTS,d),this.$target=a(this.options.target).on("scroll.bs.affix.data-api",a.proxy(this.checkPosition,this)).on("click.bs.affix.data-api",a.proxy(this.checkPositionWithEventLoop,this)),this.$element=a(b),this.affixed=this.unpin=this.pinnedOffset=null,this.checkPosition()};c.VERSION="3.2.0",c.RESET="affix affix-top affix-bottom",c.DEFAULTS={offset:0,target:window},c.prototype.getPinnedOffset=function(){if(this.pinnedOffset)return this.pinnedOffset;this.$element.removeClass(c.RESET).addClass("affix");var a=this.$target.scrollTop(),b=this.$element.offset();return this.pinnedOffset=b.top-a},c.prototype.checkPositionWithEventLoop=function(){setTimeout(a.proxy(this.checkPosition,this),1)},c.prototype.checkPosition=function(){if(this.$element.is(":visible")){var b=a(document).height(),d=this.$target.scrollTop(),e=this.$element.offset(),f=this.options.offset,g=f.top,h=f.bottom;"object"!=typeof f&&(h=g=f),"function"==typeof g&&(g=f.top(this.$element)),"function"==typeof h&&(h=f.bottom(this.$element));var i=null!=this.unpin&&d+this.unpin<=e.top?!1:null!=h&&e.top+this.$element.height()>=b-h?"bottom":null!=g&&g>=d?"top":!1;if(this.affixed!==i){null!=this.unpin&&this.$element.css("top","");var j="affix"+(i?"-"+i:""),k=a.Event(j+".bs.affix");this.$element.trigger(k),k.isDefaultPrevented()||(this.affixed=i,this.unpin="bottom"==i?this.getPinnedOffset():null,this.$element.removeClass(c.RESET).addClass(j).trigger(a.Event(j.replace("affix","affixed"))),"bottom"==i&&this.$element.offset({top:b-this.$element.height()-h}))}}};var d=a.fn.affix;a.fn.affix=b,a.fn.affix.Constructor=c,a.fn.affix.noConflict=function(){return a.fn.affix=d,this},a(window).on("load",function(){a('[data-spy="affix"]').each(function(){var c=a(this),d=c.data();d.offset=d.offset||{},d.offsetBottom&&(d.offset.bottom=d.offsetBottom),d.offsetTop&&(d.offset.top=d.offsetTop),b.call(c,d)})})}(jQuery); \ No newline at end of file diff --git a/_templates/openstackdocs/static/js/doc-characters.json b/_templates/openstackdocs/static/js/doc-characters.json deleted file mode 100644 index 9068c6db2..000000000 --- a/_templates/openstackdocs/static/js/doc-characters.json +++ /dev/null @@ -1,20 +0,0 @@ -{ - "images":[ - { - "image":"superuser1.png", - "caption":"Jesse Proudman" - }, - { - "image":"superuser2.png", - "caption":"Narayan Desai" - }, - { - "image":"superuser3.png", - "caption":"Elissa Murphy" - }, - { - "image":"superuser4.png", - "caption":"Tim Bell" - } - ] -} \ No newline at end of file diff --git a/_templates/openstackdocs/static/js/docs.js b/_templates/openstackdocs/static/js/docs.js deleted file mode 100644 index 08b43208e..000000000 --- a/_templates/openstackdocs/static/js/docs.js +++ /dev/null @@ -1,144 +0,0 @@ -// Toggle main sections -$(".docs-sidebar-section-title").click(function () { - $('.docs-sidebar-section').not(this).closest('.docs-sidebar-section').removeClass('active'); - $(this).closest('.docs-sidebar-section').toggleClass('active'); -// Bug #1422454 -// Commenting out next line, the default behavior which was preventing links -// from working. -// event.preventDefault(); -}); - -/* Bug #1422454 - The toggle functions below enable the expand/collapse, but for now - there's no easy way to get deeper links from other guides. So, - commenting both toggle functions out. -// Toggle 1st sub-sections -$(".docs-sidebar-section ol lh").click(function () { - $('.docs-sidebar-section ol').not(this).closest('.docs-sidebar-section ol').removeClass('active'); - $(this).closest('.docs-sidebar-section ol').toggleClass('active'); - if ($('.docs-has-sub').hasClass('active')) { - $(this).closest('.docs-sidebar-section ol li').addClass('open'); - } - event.preventDefault(); -}); - -// Toggle 2nd sub-sections -$(".docs-sidebar-section ol > li > a").click(function () { - $('.docs-sidebar-section ol li').not(this).removeClass('active').removeClass('open'); - $(this).closest('.docs-sidebar-section ol li').toggleClass('active'); - if ($('.docs-has-sub').hasClass('active')) { - $(this).closest('.docs-sidebar-section ol li').addClass('open'); - } - event.preventDefault(); -}); - -/* Bug #1417291 - The rule below creates a shaded plus sign next to - a numbered sublist of a bulleted list. - It's probably there to implement expand/collapse of - list items, but unfortunately it affects also those - lists where expand/collapse is not intended. - - I am commenting it out to fix this bug. If it causes - problems elsewhere, they have to be fixed elsewhere. */ - -// $('ol > li:has(ul)').addClass('docs-has-sub'); - -// webui popover -$(document).ready(function() { - function checkWidth() { - var windowSize = $(window).width(); - - if (windowSize <= 767) { - $('.gloss').webuiPopover({placement:'auto',trigger:'click'}); - } - else if (windowSize >= 768) { - $('.gloss').webuiPopover({placement:'auto',trigger:'hover'}); - } - } - - // Execute on load - checkWidth(); - // Bind event listener - $(window).resize(checkWidth); -}); - -// Bootstrap stuff -$('.docs-actions i').tooltip(); -$('.docs-sidebar-home').tooltip(); - -// Hide/Toggle definitions -$("#toggle-definitions").click(function () { - $(this).toggleClass('docs-info-off'); - if ($('.gloss').hasClass('on')) { - $('.gloss').removeClass('on').addClass('off').webuiPopover('destroy'); - } else if ($('.gloss').hasClass('off')) { - $('.gloss').removeClass('off').addClass('on').webuiPopover(); - } -}); - -// Smooth scroll -$('a').click(function () { - if($.attr(this, 'href').indexOf("#") != -1){ - $('html, body').animate({ - scrollTop: $($.attr(this, 'href')).offset().top - }, 500); - return false; - } -}); - -// Change character image on refresh -// Add file names and captions to doc-characters.json -if($('#superuser-img').length > 0) { //This shouldn't happen unless #superuser-img is available - $.getJSON('/common/js/doc-characters.json', function(data) { - var item = data.images[Math.floor(Math.random()*data.images.length)]; - $('').appendTo('#superuser-img'); - $('

' + item.caption + 'OpenStack Operator

').appendTo('#superuser-img'); - }); -} - -/* BB 150310 - openstackdocstheme provides three types of admonitions, important, note - and warning. We decorate their title paragraphs with Font Awesome icons - by adding the appropriate FA classes. */ - -$('div.important > p.admonition-title').addClass('fa fa-info-circle'); -$('div.note > p.admonition-title').addClass('fa fa-check-circle'); -$('div.warning > p.admonition-title').addClass('fa fa-exclamation-triangle'); - -/* BB 150310 - We also insert a space between the icon and the admonition title - ("Note", "Warning", "Important" or their i18n equivalents). - - This could be done with a single clause $('p.admonition-title')...., - affecting all types of admonitions. I play it safe here and explicitly - work on the three openstackdocstheme admonitions. - - The first parameter of the text() callback is not needed here (it's - the index of the HTML element that we are modifying) */ - -$('div.important > p.admonition-title').text(function(ignored_para,original) { - return " "+original -}); -$('div.note > p.admonition-title').text(function(ignored_para,original) { - return " "+original -}); -$('div.warning > p.admonition-title').text(function(ignored_para,original) { - return " "+original -}); - -// Gives the log a bug icon the information it needs to generate the bug in -// Launchpad with pre-filled information such as git SHA, git.openstack.org -// source URL, published document URL and tag. -function logABug(bugTitle, bugProject, fieldComment, fieldTags) { - var lineFeed = "%0A"; - var urlBase = "https://bugs.launchpad.net/" + bugProject + "/+filebug?field.title=" - var currentURL = "URL: " + window.location.href; - var bugLink = urlBase + encodeURIComponent(bugTitle) + - "&field.comment=" + lineFeed + lineFeed + "-----------------------------------" + lineFeed + fieldComment + - lineFeed + currentURL + - "&field.tags=" + fieldTags; - document.getElementById("logABugLink1").href=bugLink; - document.getElementById("logABugLink2").href=bugLink; - document.getElementById("logABugLink3").href=bugLink; -} diff --git a/_templates/openstackdocs/static/js/jquery-1.11.3.js b/_templates/openstackdocs/static/js/jquery-1.11.3.js deleted file mode 100644 index 0f60b7bd0..000000000 --- a/_templates/openstackdocs/static/js/jquery-1.11.3.js +++ /dev/null @@ -1,5 +0,0 @@ -/*! jQuery v1.11.3 | (c) 2005, 2015 jQuery Foundation, Inc. | jquery.org/license */ -!function(a,b){"object"==typeof module&&"object"==typeof module.exports?module.exports=a.document?b(a,!0):function(a){if(!a.document)throw new Error("jQuery requires a window with a document");return b(a)}:b(a)}("undefined"!=typeof window?window:this,function(a,b){var c=[],d=c.slice,e=c.concat,f=c.push,g=c.indexOf,h={},i=h.toString,j=h.hasOwnProperty,k={},l="1.11.3",m=function(a,b){return new m.fn.init(a,b)},n=/^[\s\uFEFF\xA0]+|[\s\uFEFF\xA0]+$/g,o=/^-ms-/,p=/-([\da-z])/gi,q=function(a,b){return b.toUpperCase()};m.fn=m.prototype={jquery:l,constructor:m,selector:"",length:0,toArray:function(){return d.call(this)},get:function(a){return null!=a?0>a?this[a+this.length]:this[a]:d.call(this)},pushStack:function(a){var b=m.merge(this.constructor(),a);return b.prevObject=this,b.context=this.context,b},each:function(a,b){return m.each(this,a,b)},map:function(a){return this.pushStack(m.map(this,function(b,c){return a.call(b,c,b)}))},slice:function(){return this.pushStack(d.apply(this,arguments))},first:function(){return this.eq(0)},last:function(){return this.eq(-1)},eq:function(a){var b=this.length,c=+a+(0>a?b:0);return this.pushStack(c>=0&&b>c?[this[c]]:[])},end:function(){return this.prevObject||this.constructor(null)},push:f,sort:c.sort,splice:c.splice},m.extend=m.fn.extend=function(){var a,b,c,d,e,f,g=arguments[0]||{},h=1,i=arguments.length,j=!1;for("boolean"==typeof g&&(j=g,g=arguments[h]||{},h++),"object"==typeof g||m.isFunction(g)||(g={}),h===i&&(g=this,h--);i>h;h++)if(null!=(e=arguments[h]))for(d in e)a=g[d],c=e[d],g!==c&&(j&&c&&(m.isPlainObject(c)||(b=m.isArray(c)))?(b?(b=!1,f=a&&m.isArray(a)?a:[]):f=a&&m.isPlainObject(a)?a:{},g[d]=m.extend(j,f,c)):void 0!==c&&(g[d]=c));return g},m.extend({expando:"jQuery"+(l+Math.random()).replace(/\D/g,""),isReady:!0,error:function(a){throw new Error(a)},noop:function(){},isFunction:function(a){return"function"===m.type(a)},isArray:Array.isArray||function(a){return"array"===m.type(a)},isWindow:function(a){return null!=a&&a==a.window},isNumeric:function(a){return!m.isArray(a)&&a-parseFloat(a)+1>=0},isEmptyObject:function(a){var b;for(b in a)return!1;return!0},isPlainObject:function(a){var b;if(!a||"object"!==m.type(a)||a.nodeType||m.isWindow(a))return!1;try{if(a.constructor&&!j.call(a,"constructor")&&!j.call(a.constructor.prototype,"isPrototypeOf"))return!1}catch(c){return!1}if(k.ownLast)for(b in a)return j.call(a,b);for(b in a);return void 0===b||j.call(a,b)},type:function(a){return null==a?a+"":"object"==typeof a||"function"==typeof a?h[i.call(a)]||"object":typeof a},globalEval:function(b){b&&m.trim(b)&&(a.execScript||function(b){a.eval.call(a,b)})(b)},camelCase:function(a){return a.replace(o,"ms-").replace(p,q)},nodeName:function(a,b){return a.nodeName&&a.nodeName.toLowerCase()===b.toLowerCase()},each:function(a,b,c){var d,e=0,f=a.length,g=r(a);if(c){if(g){for(;f>e;e++)if(d=b.apply(a[e],c),d===!1)break}else for(e in a)if(d=b.apply(a[e],c),d===!1)break}else if(g){for(;f>e;e++)if(d=b.call(a[e],e,a[e]),d===!1)break}else for(e in a)if(d=b.call(a[e],e,a[e]),d===!1)break;return a},trim:function(a){return null==a?"":(a+"").replace(n,"")},makeArray:function(a,b){var c=b||[];return null!=a&&(r(Object(a))?m.merge(c,"string"==typeof a?[a]:a):f.call(c,a)),c},inArray:function(a,b,c){var d;if(b){if(g)return g.call(b,a,c);for(d=b.length,c=c?0>c?Math.max(0,d+c):c:0;d>c;c++)if(c in b&&b[c]===a)return c}return-1},merge:function(a,b){var c=+b.length,d=0,e=a.length;while(c>d)a[e++]=b[d++];if(c!==c)while(void 0!==b[d])a[e++]=b[d++];return a.length=e,a},grep:function(a,b,c){for(var d,e=[],f=0,g=a.length,h=!c;g>f;f++)d=!b(a[f],f),d!==h&&e.push(a[f]);return e},map:function(a,b,c){var d,f=0,g=a.length,h=r(a),i=[];if(h)for(;g>f;f++)d=b(a[f],f,c),null!=d&&i.push(d);else for(f in a)d=b(a[f],f,c),null!=d&&i.push(d);return e.apply([],i)},guid:1,proxy:function(a,b){var c,e,f;return"string"==typeof b&&(f=a[b],b=a,a=f),m.isFunction(a)?(c=d.call(arguments,2),e=function(){return a.apply(b||this,c.concat(d.call(arguments)))},e.guid=a.guid=a.guid||m.guid++,e):void 0},now:function(){return+new Date},support:k}),m.each("Boolean Number String Function Array Date RegExp Object Error".split(" "),function(a,b){h["[object "+b+"]"]=b.toLowerCase()});function r(a){var b="length"in a&&a.length,c=m.type(a);return"function"===c||m.isWindow(a)?!1:1===a.nodeType&&b?!0:"array"===c||0===b||"number"==typeof b&&b>0&&b-1 in a}var s=function(a){var b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u="sizzle"+1*new Date,v=a.document,w=0,x=0,y=ha(),z=ha(),A=ha(),B=function(a,b){return a===b&&(l=!0),0},C=1<<31,D={}.hasOwnProperty,E=[],F=E.pop,G=E.push,H=E.push,I=E.slice,J=function(a,b){for(var c=0,d=a.length;d>c;c++)if(a[c]===b)return c;return-1},K="checked|selected|async|autofocus|autoplay|controls|defer|disabled|hidden|ismap|loop|multiple|open|readonly|required|scoped",L="[\\x20\\t\\r\\n\\f]",M="(?:\\\\.|[\\w-]|[^\\x00-\\xa0])+",N=M.replace("w","w#"),O="\\["+L+"*("+M+")(?:"+L+"*([*^$|!~]?=)"+L+"*(?:'((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\"|("+N+"))|)"+L+"*\\]",P=":("+M+")(?:\\((('((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\")|((?:\\\\.|[^\\\\()[\\]]|"+O+")*)|.*)\\)|)",Q=new RegExp(L+"+","g"),R=new RegExp("^"+L+"+|((?:^|[^\\\\])(?:\\\\.)*)"+L+"+$","g"),S=new RegExp("^"+L+"*,"+L+"*"),T=new RegExp("^"+L+"*([>+~]|"+L+")"+L+"*"),U=new RegExp("="+L+"*([^\\]'\"]*?)"+L+"*\\]","g"),V=new RegExp(P),W=new RegExp("^"+N+"$"),X={ID:new RegExp("^#("+M+")"),CLASS:new RegExp("^\\.("+M+")"),TAG:new RegExp("^("+M.replace("w","w*")+")"),ATTR:new RegExp("^"+O),PSEUDO:new RegExp("^"+P),CHILD:new RegExp("^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\("+L+"*(even|odd|(([+-]|)(\\d*)n|)"+L+"*(?:([+-]|)"+L+"*(\\d+)|))"+L+"*\\)|)","i"),bool:new RegExp("^(?:"+K+")$","i"),needsContext:new RegExp("^"+L+"*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\("+L+"*((?:-\\d)?\\d*)"+L+"*\\)|)(?=[^-]|$)","i")},Y=/^(?:input|select|textarea|button)$/i,Z=/^h\d$/i,$=/^[^{]+\{\s*\[native \w/,_=/^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,aa=/[+~]/,ba=/'|\\/g,ca=new RegExp("\\\\([\\da-f]{1,6}"+L+"?|("+L+")|.)","ig"),da=function(a,b,c){var d="0x"+b-65536;return d!==d||c?b:0>d?String.fromCharCode(d+65536):String.fromCharCode(d>>10|55296,1023&d|56320)},ea=function(){m()};try{H.apply(E=I.call(v.childNodes),v.childNodes),E[v.childNodes.length].nodeType}catch(fa){H={apply:E.length?function(a,b){G.apply(a,I.call(b))}:function(a,b){var c=a.length,d=0;while(a[c++]=b[d++]);a.length=c-1}}}function ga(a,b,d,e){var f,h,j,k,l,o,r,s,w,x;if((b?b.ownerDocument||b:v)!==n&&m(b),b=b||n,d=d||[],k=b.nodeType,"string"!=typeof a||!a||1!==k&&9!==k&&11!==k)return d;if(!e&&p){if(11!==k&&(f=_.exec(a)))if(j=f[1]){if(9===k){if(h=b.getElementById(j),!h||!h.parentNode)return d;if(h.id===j)return d.push(h),d}else if(b.ownerDocument&&(h=b.ownerDocument.getElementById(j))&&t(b,h)&&h.id===j)return d.push(h),d}else{if(f[2])return H.apply(d,b.getElementsByTagName(a)),d;if((j=f[3])&&c.getElementsByClassName)return H.apply(d,b.getElementsByClassName(j)),d}if(c.qsa&&(!q||!q.test(a))){if(s=r=u,w=b,x=1!==k&&a,1===k&&"object"!==b.nodeName.toLowerCase()){o=g(a),(r=b.getAttribute("id"))?s=r.replace(ba,"\\$&"):b.setAttribute("id",s),s="[id='"+s+"'] ",l=o.length;while(l--)o[l]=s+ra(o[l]);w=aa.test(a)&&pa(b.parentNode)||b,x=o.join(",")}if(x)try{return H.apply(d,w.querySelectorAll(x)),d}catch(y){}finally{r||b.removeAttribute("id")}}}return i(a.replace(R,"$1"),b,d,e)}function ha(){var a=[];function b(c,e){return a.push(c+" ")>d.cacheLength&&delete b[a.shift()],b[c+" "]=e}return b}function ia(a){return a[u]=!0,a}function ja(a){var b=n.createElement("div");try{return!!a(b)}catch(c){return!1}finally{b.parentNode&&b.parentNode.removeChild(b),b=null}}function ka(a,b){var c=a.split("|"),e=a.length;while(e--)d.attrHandle[c[e]]=b}function la(a,b){var c=b&&a,d=c&&1===a.nodeType&&1===b.nodeType&&(~b.sourceIndex||C)-(~a.sourceIndex||C);if(d)return d;if(c)while(c=c.nextSibling)if(c===b)return-1;return a?1:-1}function ma(a){return function(b){var c=b.nodeName.toLowerCase();return"input"===c&&b.type===a}}function na(a){return function(b){var c=b.nodeName.toLowerCase();return("input"===c||"button"===c)&&b.type===a}}function oa(a){return ia(function(b){return b=+b,ia(function(c,d){var e,f=a([],c.length,b),g=f.length;while(g--)c[e=f[g]]&&(c[e]=!(d[e]=c[e]))})})}function pa(a){return a&&"undefined"!=typeof a.getElementsByTagName&&a}c=ga.support={},f=ga.isXML=function(a){var b=a&&(a.ownerDocument||a).documentElement;return b?"HTML"!==b.nodeName:!1},m=ga.setDocument=function(a){var b,e,g=a?a.ownerDocument||a:v;return g!==n&&9===g.nodeType&&g.documentElement?(n=g,o=g.documentElement,e=g.defaultView,e&&e!==e.top&&(e.addEventListener?e.addEventListener("unload",ea,!1):e.attachEvent&&e.attachEvent("onunload",ea)),p=!f(g),c.attributes=ja(function(a){return a.className="i",!a.getAttribute("className")}),c.getElementsByTagName=ja(function(a){return a.appendChild(g.createComment("")),!a.getElementsByTagName("*").length}),c.getElementsByClassName=$.test(g.getElementsByClassName),c.getById=ja(function(a){return o.appendChild(a).id=u,!g.getElementsByName||!g.getElementsByName(u).length}),c.getById?(d.find.ID=function(a,b){if("undefined"!=typeof b.getElementById&&p){var c=b.getElementById(a);return c&&c.parentNode?[c]:[]}},d.filter.ID=function(a){var b=a.replace(ca,da);return function(a){return a.getAttribute("id")===b}}):(delete d.find.ID,d.filter.ID=function(a){var b=a.replace(ca,da);return function(a){var c="undefined"!=typeof a.getAttributeNode&&a.getAttributeNode("id");return c&&c.value===b}}),d.find.TAG=c.getElementsByTagName?function(a,b){return"undefined"!=typeof b.getElementsByTagName?b.getElementsByTagName(a):c.qsa?b.querySelectorAll(a):void 0}:function(a,b){var c,d=[],e=0,f=b.getElementsByTagName(a);if("*"===a){while(c=f[e++])1===c.nodeType&&d.push(c);return d}return f},d.find.CLASS=c.getElementsByClassName&&function(a,b){return p?b.getElementsByClassName(a):void 0},r=[],q=[],(c.qsa=$.test(g.querySelectorAll))&&(ja(function(a){o.appendChild(a).innerHTML="",a.querySelectorAll("[msallowcapture^='']").length&&q.push("[*^$]="+L+"*(?:''|\"\")"),a.querySelectorAll("[selected]").length||q.push("\\["+L+"*(?:value|"+K+")"),a.querySelectorAll("[id~="+u+"-]").length||q.push("~="),a.querySelectorAll(":checked").length||q.push(":checked"),a.querySelectorAll("a#"+u+"+*").length||q.push(".#.+[+~]")}),ja(function(a){var b=g.createElement("input");b.setAttribute("type","hidden"),a.appendChild(b).setAttribute("name","D"),a.querySelectorAll("[name=d]").length&&q.push("name"+L+"*[*^$|!~]?="),a.querySelectorAll(":enabled").length||q.push(":enabled",":disabled"),a.querySelectorAll("*,:x"),q.push(",.*:")})),(c.matchesSelector=$.test(s=o.matches||o.webkitMatchesSelector||o.mozMatchesSelector||o.oMatchesSelector||o.msMatchesSelector))&&ja(function(a){c.disconnectedMatch=s.call(a,"div"),s.call(a,"[s!='']:x"),r.push("!=",P)}),q=q.length&&new RegExp(q.join("|")),r=r.length&&new RegExp(r.join("|")),b=$.test(o.compareDocumentPosition),t=b||$.test(o.contains)?function(a,b){var c=9===a.nodeType?a.documentElement:a,d=b&&b.parentNode;return a===d||!(!d||1!==d.nodeType||!(c.contains?c.contains(d):a.compareDocumentPosition&&16&a.compareDocumentPosition(d)))}:function(a,b){if(b)while(b=b.parentNode)if(b===a)return!0;return!1},B=b?function(a,b){if(a===b)return l=!0,0;var d=!a.compareDocumentPosition-!b.compareDocumentPosition;return d?d:(d=(a.ownerDocument||a)===(b.ownerDocument||b)?a.compareDocumentPosition(b):1,1&d||!c.sortDetached&&b.compareDocumentPosition(a)===d?a===g||a.ownerDocument===v&&t(v,a)?-1:b===g||b.ownerDocument===v&&t(v,b)?1:k?J(k,a)-J(k,b):0:4&d?-1:1)}:function(a,b){if(a===b)return l=!0,0;var c,d=0,e=a.parentNode,f=b.parentNode,h=[a],i=[b];if(!e||!f)return a===g?-1:b===g?1:e?-1:f?1:k?J(k,a)-J(k,b):0;if(e===f)return la(a,b);c=a;while(c=c.parentNode)h.unshift(c);c=b;while(c=c.parentNode)i.unshift(c);while(h[d]===i[d])d++;return d?la(h[d],i[d]):h[d]===v?-1:i[d]===v?1:0},g):n},ga.matches=function(a,b){return ga(a,null,null,b)},ga.matchesSelector=function(a,b){if((a.ownerDocument||a)!==n&&m(a),b=b.replace(U,"='$1']"),!(!c.matchesSelector||!p||r&&r.test(b)||q&&q.test(b)))try{var d=s.call(a,b);if(d||c.disconnectedMatch||a.document&&11!==a.document.nodeType)return d}catch(e){}return ga(b,n,null,[a]).length>0},ga.contains=function(a,b){return(a.ownerDocument||a)!==n&&m(a),t(a,b)},ga.attr=function(a,b){(a.ownerDocument||a)!==n&&m(a);var e=d.attrHandle[b.toLowerCase()],f=e&&D.call(d.attrHandle,b.toLowerCase())?e(a,b,!p):void 0;return void 0!==f?f:c.attributes||!p?a.getAttribute(b):(f=a.getAttributeNode(b))&&f.specified?f.value:null},ga.error=function(a){throw new Error("Syntax error, unrecognized expression: "+a)},ga.uniqueSort=function(a){var b,d=[],e=0,f=0;if(l=!c.detectDuplicates,k=!c.sortStable&&a.slice(0),a.sort(B),l){while(b=a[f++])b===a[f]&&(e=d.push(f));while(e--)a.splice(d[e],1)}return k=null,a},e=ga.getText=function(a){var b,c="",d=0,f=a.nodeType;if(f){if(1===f||9===f||11===f){if("string"==typeof a.textContent)return a.textContent;for(a=a.firstChild;a;a=a.nextSibling)c+=e(a)}else if(3===f||4===f)return a.nodeValue}else while(b=a[d++])c+=e(b);return c},d=ga.selectors={cacheLength:50,createPseudo:ia,match:X,attrHandle:{},find:{},relative:{">":{dir:"parentNode",first:!0}," ":{dir:"parentNode"},"+":{dir:"previousSibling",first:!0},"~":{dir:"previousSibling"}},preFilter:{ATTR:function(a){return a[1]=a[1].replace(ca,da),a[3]=(a[3]||a[4]||a[5]||"").replace(ca,da),"~="===a[2]&&(a[3]=" "+a[3]+" "),a.slice(0,4)},CHILD:function(a){return a[1]=a[1].toLowerCase(),"nth"===a[1].slice(0,3)?(a[3]||ga.error(a[0]),a[4]=+(a[4]?a[5]+(a[6]||1):2*("even"===a[3]||"odd"===a[3])),a[5]=+(a[7]+a[8]||"odd"===a[3])):a[3]&&ga.error(a[0]),a},PSEUDO:function(a){var b,c=!a[6]&&a[2];return X.CHILD.test(a[0])?null:(a[3]?a[2]=a[4]||a[5]||"":c&&V.test(c)&&(b=g(c,!0))&&(b=c.indexOf(")",c.length-b)-c.length)&&(a[0]=a[0].slice(0,b),a[2]=c.slice(0,b)),a.slice(0,3))}},filter:{TAG:function(a){var b=a.replace(ca,da).toLowerCase();return"*"===a?function(){return!0}:function(a){return a.nodeName&&a.nodeName.toLowerCase()===b}},CLASS:function(a){var b=y[a+" "];return b||(b=new RegExp("(^|"+L+")"+a+"("+L+"|$)"))&&y(a,function(a){return b.test("string"==typeof a.className&&a.className||"undefined"!=typeof a.getAttribute&&a.getAttribute("class")||"")})},ATTR:function(a,b,c){return function(d){var e=ga.attr(d,a);return null==e?"!="===b:b?(e+="","="===b?e===c:"!="===b?e!==c:"^="===b?c&&0===e.indexOf(c):"*="===b?c&&e.indexOf(c)>-1:"$="===b?c&&e.slice(-c.length)===c:"~="===b?(" "+e.replace(Q," ")+" ").indexOf(c)>-1:"|="===b?e===c||e.slice(0,c.length+1)===c+"-":!1):!0}},CHILD:function(a,b,c,d,e){var f="nth"!==a.slice(0,3),g="last"!==a.slice(-4),h="of-type"===b;return 1===d&&0===e?function(a){return!!a.parentNode}:function(b,c,i){var j,k,l,m,n,o,p=f!==g?"nextSibling":"previousSibling",q=b.parentNode,r=h&&b.nodeName.toLowerCase(),s=!i&&!h;if(q){if(f){while(p){l=b;while(l=l[p])if(h?l.nodeName.toLowerCase()===r:1===l.nodeType)return!1;o=p="only"===a&&!o&&"nextSibling"}return!0}if(o=[g?q.firstChild:q.lastChild],g&&s){k=q[u]||(q[u]={}),j=k[a]||[],n=j[0]===w&&j[1],m=j[0]===w&&j[2],l=n&&q.childNodes[n];while(l=++n&&l&&l[p]||(m=n=0)||o.pop())if(1===l.nodeType&&++m&&l===b){k[a]=[w,n,m];break}}else if(s&&(j=(b[u]||(b[u]={}))[a])&&j[0]===w)m=j[1];else while(l=++n&&l&&l[p]||(m=n=0)||o.pop())if((h?l.nodeName.toLowerCase()===r:1===l.nodeType)&&++m&&(s&&((l[u]||(l[u]={}))[a]=[w,m]),l===b))break;return m-=e,m===d||m%d===0&&m/d>=0}}},PSEUDO:function(a,b){var c,e=d.pseudos[a]||d.setFilters[a.toLowerCase()]||ga.error("unsupported pseudo: "+a);return e[u]?e(b):e.length>1?(c=[a,a,"",b],d.setFilters.hasOwnProperty(a.toLowerCase())?ia(function(a,c){var d,f=e(a,b),g=f.length;while(g--)d=J(a,f[g]),a[d]=!(c[d]=f[g])}):function(a){return e(a,0,c)}):e}},pseudos:{not:ia(function(a){var b=[],c=[],d=h(a.replace(R,"$1"));return d[u]?ia(function(a,b,c,e){var f,g=d(a,null,e,[]),h=a.length;while(h--)(f=g[h])&&(a[h]=!(b[h]=f))}):function(a,e,f){return b[0]=a,d(b,null,f,c),b[0]=null,!c.pop()}}),has:ia(function(a){return function(b){return ga(a,b).length>0}}),contains:ia(function(a){return a=a.replace(ca,da),function(b){return(b.textContent||b.innerText||e(b)).indexOf(a)>-1}}),lang:ia(function(a){return W.test(a||"")||ga.error("unsupported lang: "+a),a=a.replace(ca,da).toLowerCase(),function(b){var c;do if(c=p?b.lang:b.getAttribute("xml:lang")||b.getAttribute("lang"))return c=c.toLowerCase(),c===a||0===c.indexOf(a+"-");while((b=b.parentNode)&&1===b.nodeType);return!1}}),target:function(b){var c=a.location&&a.location.hash;return c&&c.slice(1)===b.id},root:function(a){return a===o},focus:function(a){return a===n.activeElement&&(!n.hasFocus||n.hasFocus())&&!!(a.type||a.href||~a.tabIndex)},enabled:function(a){return a.disabled===!1},disabled:function(a){return a.disabled===!0},checked:function(a){var b=a.nodeName.toLowerCase();return"input"===b&&!!a.checked||"option"===b&&!!a.selected},selected:function(a){return a.parentNode&&a.parentNode.selectedIndex,a.selected===!0},empty:function(a){for(a=a.firstChild;a;a=a.nextSibling)if(a.nodeType<6)return!1;return!0},parent:function(a){return!d.pseudos.empty(a)},header:function(a){return Z.test(a.nodeName)},input:function(a){return Y.test(a.nodeName)},button:function(a){var b=a.nodeName.toLowerCase();return"input"===b&&"button"===a.type||"button"===b},text:function(a){var b;return"input"===a.nodeName.toLowerCase()&&"text"===a.type&&(null==(b=a.getAttribute("type"))||"text"===b.toLowerCase())},first:oa(function(){return[0]}),last:oa(function(a,b){return[b-1]}),eq:oa(function(a,b,c){return[0>c?c+b:c]}),even:oa(function(a,b){for(var c=0;b>c;c+=2)a.push(c);return a}),odd:oa(function(a,b){for(var c=1;b>c;c+=2)a.push(c);return a}),lt:oa(function(a,b,c){for(var d=0>c?c+b:c;--d>=0;)a.push(d);return a}),gt:oa(function(a,b,c){for(var d=0>c?c+b:c;++db;b++)d+=a[b].value;return d}function sa(a,b,c){var d=b.dir,e=c&&"parentNode"===d,f=x++;return b.first?function(b,c,f){while(b=b[d])if(1===b.nodeType||e)return a(b,c,f)}:function(b,c,g){var h,i,j=[w,f];if(g){while(b=b[d])if((1===b.nodeType||e)&&a(b,c,g))return!0}else while(b=b[d])if(1===b.nodeType||e){if(i=b[u]||(b[u]={}),(h=i[d])&&h[0]===w&&h[1]===f)return j[2]=h[2];if(i[d]=j,j[2]=a(b,c,g))return!0}}}function ta(a){return a.length>1?function(b,c,d){var e=a.length;while(e--)if(!a[e](b,c,d))return!1;return!0}:a[0]}function ua(a,b,c){for(var d=0,e=b.length;e>d;d++)ga(a,b[d],c);return c}function va(a,b,c,d,e){for(var f,g=[],h=0,i=a.length,j=null!=b;i>h;h++)(f=a[h])&&(!c||c(f,d,e))&&(g.push(f),j&&b.push(h));return g}function wa(a,b,c,d,e,f){return d&&!d[u]&&(d=wa(d)),e&&!e[u]&&(e=wa(e,f)),ia(function(f,g,h,i){var j,k,l,m=[],n=[],o=g.length,p=f||ua(b||"*",h.nodeType?[h]:h,[]),q=!a||!f&&b?p:va(p,m,a,h,i),r=c?e||(f?a:o||d)?[]:g:q;if(c&&c(q,r,h,i),d){j=va(r,n),d(j,[],h,i),k=j.length;while(k--)(l=j[k])&&(r[n[k]]=!(q[n[k]]=l))}if(f){if(e||a){if(e){j=[],k=r.length;while(k--)(l=r[k])&&j.push(q[k]=l);e(null,r=[],j,i)}k=r.length;while(k--)(l=r[k])&&(j=e?J(f,l):m[k])>-1&&(f[j]=!(g[j]=l))}}else r=va(r===g?r.splice(o,r.length):r),e?e(null,g,r,i):H.apply(g,r)})}function xa(a){for(var b,c,e,f=a.length,g=d.relative[a[0].type],h=g||d.relative[" "],i=g?1:0,k=sa(function(a){return a===b},h,!0),l=sa(function(a){return J(b,a)>-1},h,!0),m=[function(a,c,d){var e=!g&&(d||c!==j)||((b=c).nodeType?k(a,c,d):l(a,c,d));return b=null,e}];f>i;i++)if(c=d.relative[a[i].type])m=[sa(ta(m),c)];else{if(c=d.filter[a[i].type].apply(null,a[i].matches),c[u]){for(e=++i;f>e;e++)if(d.relative[a[e].type])break;return wa(i>1&&ta(m),i>1&&ra(a.slice(0,i-1).concat({value:" "===a[i-2].type?"*":""})).replace(R,"$1"),c,e>i&&xa(a.slice(i,e)),f>e&&xa(a=a.slice(e)),f>e&&ra(a))}m.push(c)}return ta(m)}function ya(a,b){var c=b.length>0,e=a.length>0,f=function(f,g,h,i,k){var l,m,o,p=0,q="0",r=f&&[],s=[],t=j,u=f||e&&d.find.TAG("*",k),v=w+=null==t?1:Math.random()||.1,x=u.length;for(k&&(j=g!==n&&g);q!==x&&null!=(l=u[q]);q++){if(e&&l){m=0;while(o=a[m++])if(o(l,g,h)){i.push(l);break}k&&(w=v)}c&&((l=!o&&l)&&p--,f&&r.push(l))}if(p+=q,c&&q!==p){m=0;while(o=b[m++])o(r,s,g,h);if(f){if(p>0)while(q--)r[q]||s[q]||(s[q]=F.call(i));s=va(s)}H.apply(i,s),k&&!f&&s.length>0&&p+b.length>1&&ga.uniqueSort(i)}return k&&(w=v,j=t),r};return c?ia(f):f}return h=ga.compile=function(a,b){var c,d=[],e=[],f=A[a+" "];if(!f){b||(b=g(a)),c=b.length;while(c--)f=xa(b[c]),f[u]?d.push(f):e.push(f);f=A(a,ya(e,d)),f.selector=a}return f},i=ga.select=function(a,b,e,f){var i,j,k,l,m,n="function"==typeof a&&a,o=!f&&g(a=n.selector||a);if(e=e||[],1===o.length){if(j=o[0]=o[0].slice(0),j.length>2&&"ID"===(k=j[0]).type&&c.getById&&9===b.nodeType&&p&&d.relative[j[1].type]){if(b=(d.find.ID(k.matches[0].replace(ca,da),b)||[])[0],!b)return e;n&&(b=b.parentNode),a=a.slice(j.shift().value.length)}i=X.needsContext.test(a)?0:j.length;while(i--){if(k=j[i],d.relative[l=k.type])break;if((m=d.find[l])&&(f=m(k.matches[0].replace(ca,da),aa.test(j[0].type)&&pa(b.parentNode)||b))){if(j.splice(i,1),a=f.length&&ra(j),!a)return H.apply(e,f),e;break}}}return(n||h(a,o))(f,b,!p,e,aa.test(a)&&pa(b.parentNode)||b),e},c.sortStable=u.split("").sort(B).join("")===u,c.detectDuplicates=!!l,m(),c.sortDetached=ja(function(a){return 1&a.compareDocumentPosition(n.createElement("div"))}),ja(function(a){return a.innerHTML="","#"===a.firstChild.getAttribute("href")})||ka("type|href|height|width",function(a,b,c){return c?void 0:a.getAttribute(b,"type"===b.toLowerCase()?1:2)}),c.attributes&&ja(function(a){return a.innerHTML="",a.firstChild.setAttribute("value",""),""===a.firstChild.getAttribute("value")})||ka("value",function(a,b,c){return c||"input"!==a.nodeName.toLowerCase()?void 0:a.defaultValue}),ja(function(a){return null==a.getAttribute("disabled")})||ka(K,function(a,b,c){var d;return c?void 0:a[b]===!0?b.toLowerCase():(d=a.getAttributeNode(b))&&d.specified?d.value:null}),ga}(a);m.find=s,m.expr=s.selectors,m.expr[":"]=m.expr.pseudos,m.unique=s.uniqueSort,m.text=s.getText,m.isXMLDoc=s.isXML,m.contains=s.contains;var t=m.expr.match.needsContext,u=/^<(\w+)\s*\/?>(?:<\/\1>|)$/,v=/^.[^:#\[\.,]*$/;function w(a,b,c){if(m.isFunction(b))return m.grep(a,function(a,d){return!!b.call(a,d,a)!==c});if(b.nodeType)return m.grep(a,function(a){return a===b!==c});if("string"==typeof b){if(v.test(b))return m.filter(b,a,c);b=m.filter(b,a)}return m.grep(a,function(a){return m.inArray(a,b)>=0!==c})}m.filter=function(a,b,c){var d=b[0];return c&&(a=":not("+a+")"),1===b.length&&1===d.nodeType?m.find.matchesSelector(d,a)?[d]:[]:m.find.matches(a,m.grep(b,function(a){return 1===a.nodeType}))},m.fn.extend({find:function(a){var b,c=[],d=this,e=d.length;if("string"!=typeof a)return this.pushStack(m(a).filter(function(){for(b=0;e>b;b++)if(m.contains(d[b],this))return!0}));for(b=0;e>b;b++)m.find(a,d[b],c);return c=this.pushStack(e>1?m.unique(c):c),c.selector=this.selector?this.selector+" "+a:a,c},filter:function(a){return this.pushStack(w(this,a||[],!1))},not:function(a){return this.pushStack(w(this,a||[],!0))},is:function(a){return!!w(this,"string"==typeof a&&t.test(a)?m(a):a||[],!1).length}});var x,y=a.document,z=/^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]*))$/,A=m.fn.init=function(a,b){var c,d;if(!a)return this;if("string"==typeof a){if(c="<"===a.charAt(0)&&">"===a.charAt(a.length-1)&&a.length>=3?[null,a,null]:z.exec(a),!c||!c[1]&&b)return!b||b.jquery?(b||x).find(a):this.constructor(b).find(a);if(c[1]){if(b=b instanceof m?b[0]:b,m.merge(this,m.parseHTML(c[1],b&&b.nodeType?b.ownerDocument||b:y,!0)),u.test(c[1])&&m.isPlainObject(b))for(c in b)m.isFunction(this[c])?this[c](b[c]):this.attr(c,b[c]);return this}if(d=y.getElementById(c[2]),d&&d.parentNode){if(d.id!==c[2])return x.find(a);this.length=1,this[0]=d}return this.context=y,this.selector=a,this}return a.nodeType?(this.context=this[0]=a,this.length=1,this):m.isFunction(a)?"undefined"!=typeof x.ready?x.ready(a):a(m):(void 0!==a.selector&&(this.selector=a.selector,this.context=a.context),m.makeArray(a,this))};A.prototype=m.fn,x=m(y);var B=/^(?:parents|prev(?:Until|All))/,C={children:!0,contents:!0,next:!0,prev:!0};m.extend({dir:function(a,b,c){var d=[],e=a[b];while(e&&9!==e.nodeType&&(void 0===c||1!==e.nodeType||!m(e).is(c)))1===e.nodeType&&d.push(e),e=e[b];return d},sibling:function(a,b){for(var c=[];a;a=a.nextSibling)1===a.nodeType&&a!==b&&c.push(a);return c}}),m.fn.extend({has:function(a){var b,c=m(a,this),d=c.length;return this.filter(function(){for(b=0;d>b;b++)if(m.contains(this,c[b]))return!0})},closest:function(a,b){for(var c,d=0,e=this.length,f=[],g=t.test(a)||"string"!=typeof a?m(a,b||this.context):0;e>d;d++)for(c=this[d];c&&c!==b;c=c.parentNode)if(c.nodeType<11&&(g?g.index(c)>-1:1===c.nodeType&&m.find.matchesSelector(c,a))){f.push(c);break}return this.pushStack(f.length>1?m.unique(f):f)},index:function(a){return a?"string"==typeof a?m.inArray(this[0],m(a)):m.inArray(a.jquery?a[0]:a,this):this[0]&&this[0].parentNode?this.first().prevAll().length:-1},add:function(a,b){return this.pushStack(m.unique(m.merge(this.get(),m(a,b))))},addBack:function(a){return this.add(null==a?this.prevObject:this.prevObject.filter(a))}});function D(a,b){do a=a[b];while(a&&1!==a.nodeType);return a}m.each({parent:function(a){var b=a.parentNode;return b&&11!==b.nodeType?b:null},parents:function(a){return m.dir(a,"parentNode")},parentsUntil:function(a,b,c){return m.dir(a,"parentNode",c)},next:function(a){return D(a,"nextSibling")},prev:function(a){return D(a,"previousSibling")},nextAll:function(a){return m.dir(a,"nextSibling")},prevAll:function(a){return m.dir(a,"previousSibling")},nextUntil:function(a,b,c){return m.dir(a,"nextSibling",c)},prevUntil:function(a,b,c){return m.dir(a,"previousSibling",c)},siblings:function(a){return m.sibling((a.parentNode||{}).firstChild,a)},children:function(a){return m.sibling(a.firstChild)},contents:function(a){return m.nodeName(a,"iframe")?a.contentDocument||a.contentWindow.document:m.merge([],a.childNodes)}},function(a,b){m.fn[a]=function(c,d){var e=m.map(this,b,c);return"Until"!==a.slice(-5)&&(d=c),d&&"string"==typeof d&&(e=m.filter(d,e)),this.length>1&&(C[a]||(e=m.unique(e)),B.test(a)&&(e=e.reverse())),this.pushStack(e)}});var E=/\S+/g,F={};function G(a){var b=F[a]={};return m.each(a.match(E)||[],function(a,c){b[c]=!0}),b}m.Callbacks=function(a){a="string"==typeof a?F[a]||G(a):m.extend({},a);var b,c,d,e,f,g,h=[],i=!a.once&&[],j=function(l){for(c=a.memory&&l,d=!0,f=g||0,g=0,e=h.length,b=!0;h&&e>f;f++)if(h[f].apply(l[0],l[1])===!1&&a.stopOnFalse){c=!1;break}b=!1,h&&(i?i.length&&j(i.shift()):c?h=[]:k.disable())},k={add:function(){if(h){var d=h.length;!function f(b){m.each(b,function(b,c){var d=m.type(c);"function"===d?a.unique&&k.has(c)||h.push(c):c&&c.length&&"string"!==d&&f(c)})}(arguments),b?e=h.length:c&&(g=d,j(c))}return this},remove:function(){return h&&m.each(arguments,function(a,c){var d;while((d=m.inArray(c,h,d))>-1)h.splice(d,1),b&&(e>=d&&e--,f>=d&&f--)}),this},has:function(a){return a?m.inArray(a,h)>-1:!(!h||!h.length)},empty:function(){return h=[],e=0,this},disable:function(){return h=i=c=void 0,this},disabled:function(){return!h},lock:function(){return i=void 0,c||k.disable(),this},locked:function(){return!i},fireWith:function(a,c){return!h||d&&!i||(c=c||[],c=[a,c.slice?c.slice():c],b?i.push(c):j(c)),this},fire:function(){return k.fireWith(this,arguments),this},fired:function(){return!!d}};return k},m.extend({Deferred:function(a){var b=[["resolve","done",m.Callbacks("once memory"),"resolved"],["reject","fail",m.Callbacks("once memory"),"rejected"],["notify","progress",m.Callbacks("memory")]],c="pending",d={state:function(){return c},always:function(){return e.done(arguments).fail(arguments),this},then:function(){var a=arguments;return m.Deferred(function(c){m.each(b,function(b,f){var g=m.isFunction(a[b])&&a[b];e[f[1]](function(){var a=g&&g.apply(this,arguments);a&&m.isFunction(a.promise)?a.promise().done(c.resolve).fail(c.reject).progress(c.notify):c[f[0]+"With"](this===d?c.promise():this,g?[a]:arguments)})}),a=null}).promise()},promise:function(a){return null!=a?m.extend(a,d):d}},e={};return d.pipe=d.then,m.each(b,function(a,f){var g=f[2],h=f[3];d[f[1]]=g.add,h&&g.add(function(){c=h},b[1^a][2].disable,b[2][2].lock),e[f[0]]=function(){return e[f[0]+"With"](this===e?d:this,arguments),this},e[f[0]+"With"]=g.fireWith}),d.promise(e),a&&a.call(e,e),e},when:function(a){var b=0,c=d.call(arguments),e=c.length,f=1!==e||a&&m.isFunction(a.promise)?e:0,g=1===f?a:m.Deferred(),h=function(a,b,c){return function(e){b[a]=this,c[a]=arguments.length>1?d.call(arguments):e,c===i?g.notifyWith(b,c):--f||g.resolveWith(b,c)}},i,j,k;if(e>1)for(i=new Array(e),j=new Array(e),k=new Array(e);e>b;b++)c[b]&&m.isFunction(c[b].promise)?c[b].promise().done(h(b,k,c)).fail(g.reject).progress(h(b,j,i)):--f;return f||g.resolveWith(k,c),g.promise()}});var H;m.fn.ready=function(a){return m.ready.promise().done(a),this},m.extend({isReady:!1,readyWait:1,holdReady:function(a){a?m.readyWait++:m.ready(!0)},ready:function(a){if(a===!0?!--m.readyWait:!m.isReady){if(!y.body)return setTimeout(m.ready);m.isReady=!0,a!==!0&&--m.readyWait>0||(H.resolveWith(y,[m]),m.fn.triggerHandler&&(m(y).triggerHandler("ready"),m(y).off("ready")))}}});function I(){y.addEventListener?(y.removeEventListener("DOMContentLoaded",J,!1),a.removeEventListener("load",J,!1)):(y.detachEvent("onreadystatechange",J),a.detachEvent("onload",J))}function J(){(y.addEventListener||"load"===event.type||"complete"===y.readyState)&&(I(),m.ready())}m.ready.promise=function(b){if(!H)if(H=m.Deferred(),"complete"===y.readyState)setTimeout(m.ready);else if(y.addEventListener)y.addEventListener("DOMContentLoaded",J,!1),a.addEventListener("load",J,!1);else{y.attachEvent("onreadystatechange",J),a.attachEvent("onload",J);var c=!1;try{c=null==a.frameElement&&y.documentElement}catch(d){}c&&c.doScroll&&!function e(){if(!m.isReady){try{c.doScroll("left")}catch(a){return setTimeout(e,50)}I(),m.ready()}}()}return H.promise(b)};var K="undefined",L;for(L in m(k))break;k.ownLast="0"!==L,k.inlineBlockNeedsLayout=!1,m(function(){var a,b,c,d;c=y.getElementsByTagName("body")[0],c&&c.style&&(b=y.createElement("div"),d=y.createElement("div"),d.style.cssText="position:absolute;border:0;width:0;height:0;top:0;left:-9999px",c.appendChild(d).appendChild(b),typeof b.style.zoom!==K&&(b.style.cssText="display:inline;margin:0;border:0;padding:1px;width:1px;zoom:1",k.inlineBlockNeedsLayout=a=3===b.offsetWidth,a&&(c.style.zoom=1)),c.removeChild(d))}),function(){var a=y.createElement("div");if(null==k.deleteExpando){k.deleteExpando=!0;try{delete a.test}catch(b){k.deleteExpando=!1}}a=null}(),m.acceptData=function(a){var b=m.noData[(a.nodeName+" ").toLowerCase()],c=+a.nodeType||1;return 1!==c&&9!==c?!1:!b||b!==!0&&a.getAttribute("classid")===b};var M=/^(?:\{[\w\W]*\}|\[[\w\W]*\])$/,N=/([A-Z])/g;function O(a,b,c){if(void 0===c&&1===a.nodeType){var d="data-"+b.replace(N,"-$1").toLowerCase();if(c=a.getAttribute(d),"string"==typeof c){try{c="true"===c?!0:"false"===c?!1:"null"===c?null:+c+""===c?+c:M.test(c)?m.parseJSON(c):c}catch(e){}m.data(a,b,c)}else c=void 0}return c}function P(a){var b;for(b in a)if(("data"!==b||!m.isEmptyObject(a[b]))&&"toJSON"!==b)return!1; - -return!0}function Q(a,b,d,e){if(m.acceptData(a)){var f,g,h=m.expando,i=a.nodeType,j=i?m.cache:a,k=i?a[h]:a[h]&&h;if(k&&j[k]&&(e||j[k].data)||void 0!==d||"string"!=typeof b)return k||(k=i?a[h]=c.pop()||m.guid++:h),j[k]||(j[k]=i?{}:{toJSON:m.noop}),("object"==typeof b||"function"==typeof b)&&(e?j[k]=m.extend(j[k],b):j[k].data=m.extend(j[k].data,b)),g=j[k],e||(g.data||(g.data={}),g=g.data),void 0!==d&&(g[m.camelCase(b)]=d),"string"==typeof b?(f=g[b],null==f&&(f=g[m.camelCase(b)])):f=g,f}}function R(a,b,c){if(m.acceptData(a)){var d,e,f=a.nodeType,g=f?m.cache:a,h=f?a[m.expando]:m.expando;if(g[h]){if(b&&(d=c?g[h]:g[h].data)){m.isArray(b)?b=b.concat(m.map(b,m.camelCase)):b in d?b=[b]:(b=m.camelCase(b),b=b in d?[b]:b.split(" ")),e=b.length;while(e--)delete d[b[e]];if(c?!P(d):!m.isEmptyObject(d))return}(c||(delete g[h].data,P(g[h])))&&(f?m.cleanData([a],!0):k.deleteExpando||g!=g.window?delete g[h]:g[h]=null)}}}m.extend({cache:{},noData:{"applet ":!0,"embed ":!0,"object ":"clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"},hasData:function(a){return a=a.nodeType?m.cache[a[m.expando]]:a[m.expando],!!a&&!P(a)},data:function(a,b,c){return Q(a,b,c)},removeData:function(a,b){return R(a,b)},_data:function(a,b,c){return Q(a,b,c,!0)},_removeData:function(a,b){return R(a,b,!0)}}),m.fn.extend({data:function(a,b){var c,d,e,f=this[0],g=f&&f.attributes;if(void 0===a){if(this.length&&(e=m.data(f),1===f.nodeType&&!m._data(f,"parsedAttrs"))){c=g.length;while(c--)g[c]&&(d=g[c].name,0===d.indexOf("data-")&&(d=m.camelCase(d.slice(5)),O(f,d,e[d])));m._data(f,"parsedAttrs",!0)}return e}return"object"==typeof a?this.each(function(){m.data(this,a)}):arguments.length>1?this.each(function(){m.data(this,a,b)}):f?O(f,a,m.data(f,a)):void 0},removeData:function(a){return this.each(function(){m.removeData(this,a)})}}),m.extend({queue:function(a,b,c){var d;return a?(b=(b||"fx")+"queue",d=m._data(a,b),c&&(!d||m.isArray(c)?d=m._data(a,b,m.makeArray(c)):d.push(c)),d||[]):void 0},dequeue:function(a,b){b=b||"fx";var c=m.queue(a,b),d=c.length,e=c.shift(),f=m._queueHooks(a,b),g=function(){m.dequeue(a,b)};"inprogress"===e&&(e=c.shift(),d--),e&&("fx"===b&&c.unshift("inprogress"),delete f.stop,e.call(a,g,f)),!d&&f&&f.empty.fire()},_queueHooks:function(a,b){var c=b+"queueHooks";return m._data(a,c)||m._data(a,c,{empty:m.Callbacks("once memory").add(function(){m._removeData(a,b+"queue"),m._removeData(a,c)})})}}),m.fn.extend({queue:function(a,b){var c=2;return"string"!=typeof a&&(b=a,a="fx",c--),arguments.lengthh;h++)b(a[h],c,g?d:d.call(a[h],h,b(a[h],c)));return e?a:j?b.call(a):i?b(a[0],c):f},W=/^(?:checkbox|radio)$/i;!function(){var a=y.createElement("input"),b=y.createElement("div"),c=y.createDocumentFragment();if(b.innerHTML="
a",k.leadingWhitespace=3===b.firstChild.nodeType,k.tbody=!b.getElementsByTagName("tbody").length,k.htmlSerialize=!!b.getElementsByTagName("link").length,k.html5Clone="<:nav>"!==y.createElement("nav").cloneNode(!0).outerHTML,a.type="checkbox",a.checked=!0,c.appendChild(a),k.appendChecked=a.checked,b.innerHTML="",k.noCloneChecked=!!b.cloneNode(!0).lastChild.defaultValue,c.appendChild(b),b.innerHTML="",k.checkClone=b.cloneNode(!0).cloneNode(!0).lastChild.checked,k.noCloneEvent=!0,b.attachEvent&&(b.attachEvent("onclick",function(){k.noCloneEvent=!1}),b.cloneNode(!0).click()),null==k.deleteExpando){k.deleteExpando=!0;try{delete b.test}catch(d){k.deleteExpando=!1}}}(),function(){var b,c,d=y.createElement("div");for(b in{submit:!0,change:!0,focusin:!0})c="on"+b,(k[b+"Bubbles"]=c in a)||(d.setAttribute(c,"t"),k[b+"Bubbles"]=d.attributes[c].expando===!1);d=null}();var X=/^(?:input|select|textarea)$/i,Y=/^key/,Z=/^(?:mouse|pointer|contextmenu)|click/,$=/^(?:focusinfocus|focusoutblur)$/,_=/^([^.]*)(?:\.(.+)|)$/;function aa(){return!0}function ba(){return!1}function ca(){try{return y.activeElement}catch(a){}}m.event={global:{},add:function(a,b,c,d,e){var f,g,h,i,j,k,l,n,o,p,q,r=m._data(a);if(r){c.handler&&(i=c,c=i.handler,e=i.selector),c.guid||(c.guid=m.guid++),(g=r.events)||(g=r.events={}),(k=r.handle)||(k=r.handle=function(a){return typeof m===K||a&&m.event.triggered===a.type?void 0:m.event.dispatch.apply(k.elem,arguments)},k.elem=a),b=(b||"").match(E)||[""],h=b.length;while(h--)f=_.exec(b[h])||[],o=q=f[1],p=(f[2]||"").split(".").sort(),o&&(j=m.event.special[o]||{},o=(e?j.delegateType:j.bindType)||o,j=m.event.special[o]||{},l=m.extend({type:o,origType:q,data:d,handler:c,guid:c.guid,selector:e,needsContext:e&&m.expr.match.needsContext.test(e),namespace:p.join(".")},i),(n=g[o])||(n=g[o]=[],n.delegateCount=0,j.setup&&j.setup.call(a,d,p,k)!==!1||(a.addEventListener?a.addEventListener(o,k,!1):a.attachEvent&&a.attachEvent("on"+o,k))),j.add&&(j.add.call(a,l),l.handler.guid||(l.handler.guid=c.guid)),e?n.splice(n.delegateCount++,0,l):n.push(l),m.event.global[o]=!0);a=null}},remove:function(a,b,c,d,e){var f,g,h,i,j,k,l,n,o,p,q,r=m.hasData(a)&&m._data(a);if(r&&(k=r.events)){b=(b||"").match(E)||[""],j=b.length;while(j--)if(h=_.exec(b[j])||[],o=q=h[1],p=(h[2]||"").split(".").sort(),o){l=m.event.special[o]||{},o=(d?l.delegateType:l.bindType)||o,n=k[o]||[],h=h[2]&&new RegExp("(^|\\.)"+p.join("\\.(?:.*\\.|)")+"(\\.|$)"),i=f=n.length;while(f--)g=n[f],!e&&q!==g.origType||c&&c.guid!==g.guid||h&&!h.test(g.namespace)||d&&d!==g.selector&&("**"!==d||!g.selector)||(n.splice(f,1),g.selector&&n.delegateCount--,l.remove&&l.remove.call(a,g));i&&!n.length&&(l.teardown&&l.teardown.call(a,p,r.handle)!==!1||m.removeEvent(a,o,r.handle),delete k[o])}else for(o in k)m.event.remove(a,o+b[j],c,d,!0);m.isEmptyObject(k)&&(delete r.handle,m._removeData(a,"events"))}},trigger:function(b,c,d,e){var f,g,h,i,k,l,n,o=[d||y],p=j.call(b,"type")?b.type:b,q=j.call(b,"namespace")?b.namespace.split("."):[];if(h=l=d=d||y,3!==d.nodeType&&8!==d.nodeType&&!$.test(p+m.event.triggered)&&(p.indexOf(".")>=0&&(q=p.split("."),p=q.shift(),q.sort()),g=p.indexOf(":")<0&&"on"+p,b=b[m.expando]?b:new m.Event(p,"object"==typeof b&&b),b.isTrigger=e?2:3,b.namespace=q.join("."),b.namespace_re=b.namespace?new RegExp("(^|\\.)"+q.join("\\.(?:.*\\.|)")+"(\\.|$)"):null,b.result=void 0,b.target||(b.target=d),c=null==c?[b]:m.makeArray(c,[b]),k=m.event.special[p]||{},e||!k.trigger||k.trigger.apply(d,c)!==!1)){if(!e&&!k.noBubble&&!m.isWindow(d)){for(i=k.delegateType||p,$.test(i+p)||(h=h.parentNode);h;h=h.parentNode)o.push(h),l=h;l===(d.ownerDocument||y)&&o.push(l.defaultView||l.parentWindow||a)}n=0;while((h=o[n++])&&!b.isPropagationStopped())b.type=n>1?i:k.bindType||p,f=(m._data(h,"events")||{})[b.type]&&m._data(h,"handle"),f&&f.apply(h,c),f=g&&h[g],f&&f.apply&&m.acceptData(h)&&(b.result=f.apply(h,c),b.result===!1&&b.preventDefault());if(b.type=p,!e&&!b.isDefaultPrevented()&&(!k._default||k._default.apply(o.pop(),c)===!1)&&m.acceptData(d)&&g&&d[p]&&!m.isWindow(d)){l=d[g],l&&(d[g]=null),m.event.triggered=p;try{d[p]()}catch(r){}m.event.triggered=void 0,l&&(d[g]=l)}return b.result}},dispatch:function(a){a=m.event.fix(a);var b,c,e,f,g,h=[],i=d.call(arguments),j=(m._data(this,"events")||{})[a.type]||[],k=m.event.special[a.type]||{};if(i[0]=a,a.delegateTarget=this,!k.preDispatch||k.preDispatch.call(this,a)!==!1){h=m.event.handlers.call(this,a,j),b=0;while((f=h[b++])&&!a.isPropagationStopped()){a.currentTarget=f.elem,g=0;while((e=f.handlers[g++])&&!a.isImmediatePropagationStopped())(!a.namespace_re||a.namespace_re.test(e.namespace))&&(a.handleObj=e,a.data=e.data,c=((m.event.special[e.origType]||{}).handle||e.handler).apply(f.elem,i),void 0!==c&&(a.result=c)===!1&&(a.preventDefault(),a.stopPropagation()))}return k.postDispatch&&k.postDispatch.call(this,a),a.result}},handlers:function(a,b){var c,d,e,f,g=[],h=b.delegateCount,i=a.target;if(h&&i.nodeType&&(!a.button||"click"!==a.type))for(;i!=this;i=i.parentNode||this)if(1===i.nodeType&&(i.disabled!==!0||"click"!==a.type)){for(e=[],f=0;h>f;f++)d=b[f],c=d.selector+" ",void 0===e[c]&&(e[c]=d.needsContext?m(c,this).index(i)>=0:m.find(c,this,null,[i]).length),e[c]&&e.push(d);e.length&&g.push({elem:i,handlers:e})}return h]","i"),ha=/^\s+/,ia=/<(?!area|br|col|embed|hr|img|input|link|meta|param)(([\w:]+)[^>]*)\/>/gi,ja=/<([\w:]+)/,ka=/\s*$/g,ra={option:[1,""],legend:[1,"
","
"],area:[1,"",""],param:[1,"",""],thead:[1,"","
"],tr:[2,"","
"],col:[2,"","
"],td:[3,"","
"],_default:k.htmlSerialize?[0,"",""]:[1,"X
","
"]},sa=da(y),ta=sa.appendChild(y.createElement("div"));ra.optgroup=ra.option,ra.tbody=ra.tfoot=ra.colgroup=ra.caption=ra.thead,ra.th=ra.td;function ua(a,b){var c,d,e=0,f=typeof a.getElementsByTagName!==K?a.getElementsByTagName(b||"*"):typeof a.querySelectorAll!==K?a.querySelectorAll(b||"*"):void 0;if(!f)for(f=[],c=a.childNodes||a;null!=(d=c[e]);e++)!b||m.nodeName(d,b)?f.push(d):m.merge(f,ua(d,b));return void 0===b||b&&m.nodeName(a,b)?m.merge([a],f):f}function va(a){W.test(a.type)&&(a.defaultChecked=a.checked)}function wa(a,b){return m.nodeName(a,"table")&&m.nodeName(11!==b.nodeType?b:b.firstChild,"tr")?a.getElementsByTagName("tbody")[0]||a.appendChild(a.ownerDocument.createElement("tbody")):a}function xa(a){return a.type=(null!==m.find.attr(a,"type"))+"/"+a.type,a}function ya(a){var b=pa.exec(a.type);return b?a.type=b[1]:a.removeAttribute("type"),a}function za(a,b){for(var c,d=0;null!=(c=a[d]);d++)m._data(c,"globalEval",!b||m._data(b[d],"globalEval"))}function Aa(a,b){if(1===b.nodeType&&m.hasData(a)){var c,d,e,f=m._data(a),g=m._data(b,f),h=f.events;if(h){delete g.handle,g.events={};for(c in h)for(d=0,e=h[c].length;e>d;d++)m.event.add(b,c,h[c][d])}g.data&&(g.data=m.extend({},g.data))}}function Ba(a,b){var c,d,e;if(1===b.nodeType){if(c=b.nodeName.toLowerCase(),!k.noCloneEvent&&b[m.expando]){e=m._data(b);for(d in e.events)m.removeEvent(b,d,e.handle);b.removeAttribute(m.expando)}"script"===c&&b.text!==a.text?(xa(b).text=a.text,ya(b)):"object"===c?(b.parentNode&&(b.outerHTML=a.outerHTML),k.html5Clone&&a.innerHTML&&!m.trim(b.innerHTML)&&(b.innerHTML=a.innerHTML)):"input"===c&&W.test(a.type)?(b.defaultChecked=b.checked=a.checked,b.value!==a.value&&(b.value=a.value)):"option"===c?b.defaultSelected=b.selected=a.defaultSelected:("input"===c||"textarea"===c)&&(b.defaultValue=a.defaultValue)}}m.extend({clone:function(a,b,c){var d,e,f,g,h,i=m.contains(a.ownerDocument,a);if(k.html5Clone||m.isXMLDoc(a)||!ga.test("<"+a.nodeName+">")?f=a.cloneNode(!0):(ta.innerHTML=a.outerHTML,ta.removeChild(f=ta.firstChild)),!(k.noCloneEvent&&k.noCloneChecked||1!==a.nodeType&&11!==a.nodeType||m.isXMLDoc(a)))for(d=ua(f),h=ua(a),g=0;null!=(e=h[g]);++g)d[g]&&Ba(e,d[g]);if(b)if(c)for(h=h||ua(a),d=d||ua(f),g=0;null!=(e=h[g]);g++)Aa(e,d[g]);else Aa(a,f);return d=ua(f,"script"),d.length>0&&za(d,!i&&ua(a,"script")),d=h=e=null,f},buildFragment:function(a,b,c,d){for(var e,f,g,h,i,j,l,n=a.length,o=da(b),p=[],q=0;n>q;q++)if(f=a[q],f||0===f)if("object"===m.type(f))m.merge(p,f.nodeType?[f]:f);else if(la.test(f)){h=h||o.appendChild(b.createElement("div")),i=(ja.exec(f)||["",""])[1].toLowerCase(),l=ra[i]||ra._default,h.innerHTML=l[1]+f.replace(ia,"<$1>")+l[2],e=l[0];while(e--)h=h.lastChild;if(!k.leadingWhitespace&&ha.test(f)&&p.push(b.createTextNode(ha.exec(f)[0])),!k.tbody){f="table"!==i||ka.test(f)?""!==l[1]||ka.test(f)?0:h:h.firstChild,e=f&&f.childNodes.length;while(e--)m.nodeName(j=f.childNodes[e],"tbody")&&!j.childNodes.length&&f.removeChild(j)}m.merge(p,h.childNodes),h.textContent="";while(h.firstChild)h.removeChild(h.firstChild);h=o.lastChild}else p.push(b.createTextNode(f));h&&o.removeChild(h),k.appendChecked||m.grep(ua(p,"input"),va),q=0;while(f=p[q++])if((!d||-1===m.inArray(f,d))&&(g=m.contains(f.ownerDocument,f),h=ua(o.appendChild(f),"script"),g&&za(h),c)){e=0;while(f=h[e++])oa.test(f.type||"")&&c.push(f)}return h=null,o},cleanData:function(a,b){for(var d,e,f,g,h=0,i=m.expando,j=m.cache,l=k.deleteExpando,n=m.event.special;null!=(d=a[h]);h++)if((b||m.acceptData(d))&&(f=d[i],g=f&&j[f])){if(g.events)for(e in g.events)n[e]?m.event.remove(d,e):m.removeEvent(d,e,g.handle);j[f]&&(delete j[f],l?delete d[i]:typeof d.removeAttribute!==K?d.removeAttribute(i):d[i]=null,c.push(f))}}}),m.fn.extend({text:function(a){return V(this,function(a){return void 0===a?m.text(this):this.empty().append((this[0]&&this[0].ownerDocument||y).createTextNode(a))},null,a,arguments.length)},append:function(){return this.domManip(arguments,function(a){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var b=wa(this,a);b.appendChild(a)}})},prepend:function(){return this.domManip(arguments,function(a){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var b=wa(this,a);b.insertBefore(a,b.firstChild)}})},before:function(){return this.domManip(arguments,function(a){this.parentNode&&this.parentNode.insertBefore(a,this)})},after:function(){return this.domManip(arguments,function(a){this.parentNode&&this.parentNode.insertBefore(a,this.nextSibling)})},remove:function(a,b){for(var c,d=a?m.filter(a,this):this,e=0;null!=(c=d[e]);e++)b||1!==c.nodeType||m.cleanData(ua(c)),c.parentNode&&(b&&m.contains(c.ownerDocument,c)&&za(ua(c,"script")),c.parentNode.removeChild(c));return this},empty:function(){for(var a,b=0;null!=(a=this[b]);b++){1===a.nodeType&&m.cleanData(ua(a,!1));while(a.firstChild)a.removeChild(a.firstChild);a.options&&m.nodeName(a,"select")&&(a.options.length=0)}return this},clone:function(a,b){return a=null==a?!1:a,b=null==b?a:b,this.map(function(){return m.clone(this,a,b)})},html:function(a){return V(this,function(a){var b=this[0]||{},c=0,d=this.length;if(void 0===a)return 1===b.nodeType?b.innerHTML.replace(fa,""):void 0;if(!("string"!=typeof a||ma.test(a)||!k.htmlSerialize&&ga.test(a)||!k.leadingWhitespace&&ha.test(a)||ra[(ja.exec(a)||["",""])[1].toLowerCase()])){a=a.replace(ia,"<$1>");try{for(;d>c;c++)b=this[c]||{},1===b.nodeType&&(m.cleanData(ua(b,!1)),b.innerHTML=a);b=0}catch(e){}}b&&this.empty().append(a)},null,a,arguments.length)},replaceWith:function(){var a=arguments[0];return this.domManip(arguments,function(b){a=this.parentNode,m.cleanData(ua(this)),a&&a.replaceChild(b,this)}),a&&(a.length||a.nodeType)?this:this.remove()},detach:function(a){return this.remove(a,!0)},domManip:function(a,b){a=e.apply([],a);var c,d,f,g,h,i,j=0,l=this.length,n=this,o=l-1,p=a[0],q=m.isFunction(p);if(q||l>1&&"string"==typeof p&&!k.checkClone&&na.test(p))return this.each(function(c){var d=n.eq(c);q&&(a[0]=p.call(this,c,d.html())),d.domManip(a,b)});if(l&&(i=m.buildFragment(a,this[0].ownerDocument,!1,this),c=i.firstChild,1===i.childNodes.length&&(i=c),c)){for(g=m.map(ua(i,"script"),xa),f=g.length;l>j;j++)d=i,j!==o&&(d=m.clone(d,!0,!0),f&&m.merge(g,ua(d,"script"))),b.call(this[j],d,j);if(f)for(h=g[g.length-1].ownerDocument,m.map(g,ya),j=0;f>j;j++)d=g[j],oa.test(d.type||"")&&!m._data(d,"globalEval")&&m.contains(h,d)&&(d.src?m._evalUrl&&m._evalUrl(d.src):m.globalEval((d.text||d.textContent||d.innerHTML||"").replace(qa,"")));i=c=null}return this}}),m.each({appendTo:"append",prependTo:"prepend",insertBefore:"before",insertAfter:"after",replaceAll:"replaceWith"},function(a,b){m.fn[a]=function(a){for(var c,d=0,e=[],g=m(a),h=g.length-1;h>=d;d++)c=d===h?this:this.clone(!0),m(g[d])[b](c),f.apply(e,c.get());return this.pushStack(e)}});var Ca,Da={};function Ea(b,c){var d,e=m(c.createElement(b)).appendTo(c.body),f=a.getDefaultComputedStyle&&(d=a.getDefaultComputedStyle(e[0]))?d.display:m.css(e[0],"display");return e.detach(),f}function Fa(a){var b=y,c=Da[a];return c||(c=Ea(a,b),"none"!==c&&c||(Ca=(Ca||m("').attr('src',this.options.url); - } - }else if (!this.content){ - var content=''; - if ($.isFunction(this.options.content)){ - content = this.options.content.apply(this.$element[0],arguments); - }else{ - content = this.options.content; - } - this.content = this.$element.attr('data-content')||content; - } - return this.content; - }, - setContent:function(content){ - var $target = this.getTarget(); - this.getContentElement().html(content); - this.$target = $target; - }, - isAsync:function(){ - return this.options.type==='async'; - }, - setContentASync:function(content){ - var that = this; - $.ajax({ - url:this.options.url, - type:'GET', - cache:this.options.cache, - success:function(data){ - if (content&&$.isFunction(content)){ - that.content = content.apply(that.$element[0],[data]); - }else{ - that.content = data; - } - that.setContent(that.content); - var $targetContent = that.getContentElement(); - $targetContent.removeAttr('style'); - that.displayContent(); - } - }); - }, - - bindBodyEvents:function(){ - $('body').off('keyup.webui-popover').on('keyup.webui-popover',$.proxy(this.escapeHandler,this)); - $('body').off('click.webui-popover').on('click.webui-popover',$.proxy(this.bodyClickHandler,this)); - }, - - /* event handlers */ - mouseenterHandler:function(){ - var self = this; - if (self._timeout){clearTimeout(self._timeout);} - if (!self.getTarget().is(':visible')){self.show();} - }, - mouseleaveHandler:function(){ - var self = this; - //key point, set the _timeout then use clearTimeout when mouse leave - self._timeout = setTimeout(function(){ - self.hide(); - },self.options.delay); - }, - escapeHandler:function(e){ - if (e.keyCode===27){ - this.hideAll(); - } - }, - bodyClickHandler:function(){ - this.hideAll(); - }, - - targetClickHandler:function(e){ - e.stopPropagation(); - }, - - //reset and init the target events; - initTargetEvents:function(){ - if (this.options.trigger!=='click'){ - this.$target.off('mouseenter mouseleave') - .on('mouseenter',$.proxy(this.mouseenterHandler,this)) - .on('mouseleave',$.proxy(this.mouseleaveHandler,this)); - } - this.$target.find('.close').off('click').on('click', $.proxy(this.hide,this)); - this.$target.off('click.webui-popover').on('click.webui-popover',$.proxy(this.targetClickHandler,this)); - }, - /* utils methods */ - //caculate placement of the popover - getPlacement:function(pos,targetHeight){ - var - placement, - de = document.documentElement, - db = document.body, - clientWidth = de.clientWidth, - clientHeight = de.clientHeight, - scrollTop = Math.max(db.scrollTop,de.scrollTop), - scrollLeft = Math.max(db.scrollLeft,de.scrollLeft), - pageX = Math.max(0,pos.left - scrollLeft), - pageY = Math.max(0,pos.top - scrollTop), - arrowSize = 20; - - //if placement equals auto，caculate the placement by element information; - if (typeof(this.options.placement)==='function'){ - placement = this.options.placement.call(this, this.getTarget()[0], this.$element[0]); - }else{ - placement = this.$element.data('placement')||this.options.placement; - } - - if (placement==='auto'){ - if (pageXtargetHeight+arrowSize?'top-right':'bottom-right'; - }else if (pageXtargetHeight+arrowSize?'top-left':'bottom-left'; - if (pageY -
-

{{ title }}

-
-
- {% if prev %} - - {% endif %} - {% if next %} - - {% endif %} - -
- diff --git a/common_conf.py b/common_conf.py deleted file mode 100644 index 9fe8718da..000000000 --- a/common_conf.py +++ /dev/null @@ -1,103 +0,0 @@ -# The encoding of source files. -source_encoding = 'utf-8-sig' -#source_encoding = 'shift_jis' - -# The language for content autogenerated by Sphinx. -language = 'en' -#language = 'ja' - -# The theme to use for HTML and HTML Help pages. -#html_theme = 'default' -#html_theme = 'sphinxdoc' -#html_theme = 'scrolls' -#html_theme = 'agogo' -#html_theme = 'traditional' -#html_theme = 'nature' -#html_theme = 'haiku' - -# If this is not the empty string, a 'Last updated on:' timestamp -# is inserted at every page bottom, using the given strftime() format. -# Default is '%b %d, %Y' (or a locale-dependent equivalent). -html_last_updated_fmt = '%Y/%m/%d' - -# A list of paths that contains extra files not directly related to the -# documentation, such as robots.txt or .htaccess. Relative paths are taken -# as relative to the configuration directory. They are copied to the output -# directory. They will overwrite any existing file of the same name. -html_extra_path = ['examples'] - -# Enable Antialiasing -blockdiag_antialias = True -acttdiag_antialias = True -seqdiag_antialias = True -nwdiag_antialias = True - -extensions += ['rst2pdf.pdfbuilder'] -pdf_documents = [ - (master_doc, project, project, copyright), -] -pdf_stylesheets = ['sphinx', 'kerning', 'a4'] -pdf_language = "en_US" -# Mode for literal blocks wider than the frame. Can be -# overflow, shrink or truncate -pdf_fit_mode = "shrink" - -# Section level that forces a break page. -# For example: 1 means top-level sections start in a new page -# 0 means disabled -#pdf_break_level = 0 - -# When a section starts in a new page, force it to be 'even', 'odd', -# or just use 'any' -pdf_breakside = 'any' - -# Insert footnotes where they are defined instead of -# at the end. -pdf_inline_footnotes = False - -# verbosity level. 0 1 or 2 -pdf_verbosity = 0 - -# If false, no index is generated. -pdf_use_index = True - -# If false, no modindex is generated. -pdf_use_modindex = True - -# If false, no coverpage is generated. -pdf_use_coverpage = True - -# Name of the cover page template to use -#pdf_cover_template = 'sphinxcover.tmpl' - -# Documents to append as an appendix to all manuals. -#pdf_appendices = [] - -# Enable experimental feature to split table cells. Use it -# if you get "DelayedTable too big" errors -#pdf_splittables = False - -# Set the default DPI for images -#pdf_default_dpi = 72 - -# Enable rst2pdf extension modules (default is only vectorpdf) -# you need vectorpdf if you want to use sphinx's graphviz support -#pdf_extensions = ['vectorpdf'] - -# Page template name for "regular" pages -#pdf_page_template = 'cutePage' - -# Show Table Of Contents at the beginning? -pdf_use_toc = True - -# How many levels deep should the table of contents be? -pdf_toc_depth = 3 - -# Add section number to section references -pdf_use_numbered_links = False - -# Background images fitting mode -pdf_fit_background_mode = 'scale' -pdf_stylesheets = ['letter', 'fuel'] -pdf_style_path = ['_templates'] - diff --git a/conf.py b/conf.py deleted file mode 100644 index c8bb41c63..000000000 --- a/conf.py +++ /dev/null @@ -1,275 +0,0 @@ -# -*- coding: utf-8 -*- -# -# fuel documentation build configuration file -# -# 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 os -import sys -import subprocess -# import openstackdocstheme - -sys.path.insert(0, os.path.join(os.path.abspath('.'))) - -autodoc_default_flags = ['members', 'show-inheritance'] -autodoc_member_order = 'bysource' - -# 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', - 'rst2pdf.pdfbuilder' -] - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['_templates'] - -# The suffix of source filenames. -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'Fuel' -copyright = u'2012-2017, OpenStack' - -# 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 = '8.0' -# The full version, including alpha/beta/rc tags. -release = '8.0' - -# The language for content autogenerated by Sphinx. Refer to documentation -# for a list of supported languages. -language = 'en' - -# 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', '.*', 'userdocs/snippets/*'] - -# 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 = [] - - -# -- 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 = 'openstackdocs' - -# Theme options are theme-specific and customize the look and feel of a theme -# documentation. -# html_theme_options = - -# Add any paths that contain custom themes here, relative to this directory. -html_theme_path = ['_templates'] - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -#html_title = None - -# 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'] - -# 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 = True - -# Custom sidebar templates, maps document names to template names. -html_sidebars = { - '**': ['localtoc.html', 'relations.html', 'sourcelink.html', 'sidebarpdf.html', 'searchbox.html'], -} - -# 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 = True - -# 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 = False - -# If true, links to the reST sources are added to the pages. -#html_show_sourcelink = True - -# 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 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 - -# Output file base name for HTML help builder. -htmlhelp_basename = 'fuel-doc' - - -# -- Options for LaTeX output ------------------------------------------------- - -latex_elements = { - # The paper size ('letterpaper' or 'a4paper'). - 'papersize': 'a4paper', - - # The font size ('10pt', '11pt' or '12pt'). - 'pointsize': '12pt', - - # Additional stuff for the LaTeX preamble. - 'preamble': ''' - \setcounter{tocdepth}{3} - \usepackage{tocbibind} - \pagenumbering{arabic} - ''' -} - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, documentclass -# [howto/manual]). -latex_documents = [ - ('index', 'fuel.tex', u'Fuel Documentation', u'Mike Scherbakov', '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 = [ - ('index', 'fuel', u'Fuel Documentation', [u'Mike Scherbakov'], 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 = [( - 'index', 'fuel', u'Fuel Documentation', u'Mike Scherbakov', - 'fuel', 'OpenStack Installer', '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' -# -- Additional Settings ------------------------------------------------------ -# The variables to make "Log a bug" link send -# metadata for the project where the docs reside: - -# We ask git for the SHA checksum -# The git SHA checksum is used by "log-a-bug" -git_cmd = ["/usr/bin/git", "rev-parse", "HEAD"] -gitsha = subprocess.Popen(git_cmd, stdout=subprocess.PIPE).communicate()[0].strip('\n') -# tag that reported bugs will be tagged with -bug_tag = "" -# source tree -pwd = os.getcwd() -# html_context allows us to pass arbitrary values into the html template -html_context = {"pwd": pwd, "gitsha": gitsha} -# Must set this variable to include year, month, day, hours, and minutes. -html_last_updated_fmt = '%Y-%m-%d %H:%M' - -execfile('./common_conf.py') diff --git a/devdocs/buildsystem.rst b/devdocs/buildsystem.rst deleted file mode 100644 index 1ef7ce940..000000000 --- a/devdocs/buildsystem.rst +++ /dev/null @@ -1,267 +0,0 @@ -.. _buildsystem: - - -Fuel ISO build system -===================== - -Use the `fuel-main repository `_ -to build Fuel components such as an ISO or an upgrade tarball. -This repository contains a set of GNU Make build scripts. - -Quick start ------------ - -1. You must use Ubuntu 14.04 distribution to build Fuel components or the build process may fail. Note that build only works for x64 platforms. - -2. Check whether you have git installed in - your system. To do that, use the following command: - -:: - - which git - -If git is not found, install it with the following command: - -:: - - - apt-get install git - - -3. Clone the **fuel-main** git repository to the location where - you will work. The root of your repo will be named `fuel-main`. - In this example, it will be located under the *~/fuel* directory: - -:: - - mkdir ~/fuel - cd ~/fuel - git clone https://github.com/openstack/fuel-main.git - cd fuel-main - - -.. note::Fuel build system consists of the following components: - - * a shell script (**./prepare-build-env.sh**) - prepares the build environment by checking - that all necessary packages are installed and installing any that are not. - - * **fuel-main** directory - the only one required repository for building the Fuel ISO. - - The make script then downloads the additional components - (Fuel Library, Nailgun, Astute and OSTF). - Unless otherwise specified in the makefile, - the master branch of each respective repo is used to build the ISO. - -4. Run the shell script: - -:: - - ./prepare-build-env.sh - - and wait until **prepare-build-env.sh** - installs the Fuel build evironment on your computer. - -5. After the script runs successfully, issue the following command to build a - Fuel ISO: - -:: - - make iso - -6. Use the following command to list the available make targets: - -:: - - make help - -For the full list of available targets with description, see :ref:`Build targets ` section below. - -Build system structure ----------------------- - -Fuel consists of several components such as web interface, -puppet modules, orchestration components, testing components. -Source code of all those components is split into multiple git -repositories like, for example: - -- https://github.com/openstack/fuel-web -- https://github.com/openstack/fuel-ui -- https://github.com/openstack/fuel-astute -- https://github.com/openstack/fuel-ostf -- https://github.com/openstack/fuel-library -- https://github.com/openstack/fuel-docs - -The main component of the Fuel build system is -*fuel-main* directory. - -Fuel build processes are quite complicated, -so to make the **fuel-main** code easily -maintainable, it is -split into a bunch of files and directories. - -Those files -and directories contain independent -(or at least almost independent) -pieces of Fuel build system: - -* **Makefile** - the main Makefile which includes all other make modules. - -* **config.mk** - contains parameters used to customize the build process, - specifying items such as build paths, - upstream mirrors, source code repositories - and branches, built-in default Fuel settings and ISO name. - -* **rules.mk** - defines frequently used macros. - -* **repos.mk** - contains make scripts to download the - other repositories to develop Fuel - components put into separate repos. - -* **sandbox.mk** - shell script definitions that create - and destroy the special chroot environment required to - build some components. - For example, for building RPM packages, - CentOS images we use CentOS chroot environment. - -* **mirror** - contains the code which is used to download - all necessary packages from upstream mirrors and build new - ones which are to be copied on Fuel ISO even if Internet - connection is down. - -* **packages** - contains DEB and RPM - specs as well as make code for building those packages, - included in Fuel DEB and RPM mirrors. - -* **bootstrap** - contains a make script intended - to build CentOS-based miniroot image (a.k.a initrd or initramfs). - -* **docker** - contains the make scripts to - build docker containers, deployed on the Fuel Master node. - -* **iso** - contains **make** scripts for building Fuel ISO file. - - -.. _build-targets: - -Build targets -------------- - -* **all** - used for building all Fuel artifacts. - Currently, it is an alias for **iso** target. - -* **bootstrap** - used for building in-memory bootstrap - image which is used for auto-discovering. - -* **mirror** - used for building local mirrors (the copies of CentOS and - Ubuntu mirrors which are then placed into Fuel ISO). - They contain all necessary packages including those listed in - *requirements-*.txt* files with their dependencies as well as those which - are Fuel packages. Packages listed in *requirements-*.txt* files are downloaded - from upstream mirrors while Fuel packages are built from source code. - -* **iso** - used for building Fuel ISO. If build succeeds, - ISO is put into build/artifacts folder. - -* **clean** - removes build directory. - -* **deep_clean** - removes build directory and local mirror. - Note that if you remove a local mirror, then next time - the ISO build job will download all necessary packages again. - So, the process goes faster if you keep local mirrors. - You should also mind the following: - it is better to run *make deep_clean* every time when building an ISO to make sure the local mirror is consistent. - - -Customizing build process -------------------------- - -There are plenty of variables in make files. -Some of them represent a kind of build parameters. -They are defined in **config.mk** file: - -* **TOP_DIR** - a default current directory. - All other build directories are relative to this path. - -* **BUILD_DIR** - contains all files, used during build process. - By default, it is **$(TOP_DIR)/build**. - -* **ARTS_DIR** - contains build artifacts such as ISO and IMG files - By default, it is **$(BUILD_DIR)/artifacts**. - -* **LOCAL_MIRROR** - contains local CentOS and Ubuntu mirrors - By default, it is **$(TOP_DIR)/local_mirror**. - -* **DEPS_DIR** - contains build targets that depend on artifacts - of the previous build jobs, placed there - before build starts. By default, it is **$(TOP_DIR)/deps**. - -* **ISO_NAME** - a name of Fuel ISO without file extension: - if **ISO_NAME** = **MY_CUSTOM_NAME**, then Fuel ISO file will - be placed into **$(MY_CUSTOM_NAME).iso**. - -* **ISO_PATH** - used to specify Fuel ISO full path instead of defining - just ISO name. - By default, it is **$(ARTS_DIR)/$(ISO_NAME).iso**. - -* Fuel ISO contains some default settings for the - Fuel Master node. These settings can be customized - during Fuel Master node installation. - One can customize those - settings using the following variables: - -- **MASTER_IP** - the Fuel Master node IP address. - By default, it is 10.20.0.2. - -- **MASTER_NETMASK** - Fuel Master node IP netmask. - By default, it is 255.255.255.0. - -- **MASTER_GW** - Fuel Master node default gateway. - By default, it is 10.20.0.1. - -- **MASTER_DNS** - the upstream DNS location for the Fuel master node. - FUel Master node DNS will redirect there all DNS requests that it is not able to resolve itself. - By default, it is 10.20.0.1. - - -Other options -------------- - -* **[repo]_REPO** - remote source code repo. - URL or git repository can be specified for each of the Fuel components. - (FUELLIB, NAILGUN, ASTUTE, OSTF). - -* **[repo]_COMMIT** - source branch for each of the Fuel components to build. - -* **[repo]_GERRIT_URL** - gerrit repo. - -* **[repo]_GERRIT_COMMIT** - list of extra commits from gerrit. - -* **[repo]_SPEC_REPO** - repo for RPM/DEB specs of OpenStack packages. - -* **[repo]_SPEC_COMMIT** - branch for checkout. - -* **[repo]_SPEC_GERRIT_URL** - gerrit repo for OpenStack specs. - -* **[repo]_SPEC_GERRIT_COMMIT** - list of extra commits from gerrit for specs. - -* **USE_MIRROR** - pre-built mirrors from Fuel infrastructure. - The following mirrors can be used: - * ext (external mirror, publicly available one) - * none (reserved for building local mirrors: in this case - CentOS and Ubuntu packages will be fetched from upstream mirrors, so - that it will make the build process much slower). - -* **MIRROR_CENTOS** - download CentOS packages from a specific remote repo. - -* **MIRROR_UBUNTU** - download Ubuntu packages from a specific remote repo. - -* **MIRROR_DOCKER** - download docker images from a specific remote url. - -* **EXTRA_RPM_REPOS** - extra repos with RPM packages. - Each repo must be comma separated - tuple with repo-name and repo-path: - , , - For example, - qemu2,http://hostname.domain.tld/some/path/ libvirt,http://hostname.domain.tld/another/path/ - -Note that if you want to add more packages to the Fuel Master node, you should update the **requirements-rpm.txt** file. diff --git a/devdocs/develop.rst b/devdocs/develop.rst deleted file mode 100644 index 5970c7983..000000000 --- a/devdocs/develop.rst +++ /dev/null @@ -1,23 +0,0 @@ -.. _develop: - -Developer Guide -=============== - -.. toctree:: - :maxdepth: 3 - - develop/architecture - develop/sequence - develop/quick_start - develop/addition_examples - develop/env - develop/system_tests/tree - develop/live_masternode - develop/nailgun - develop/module_structure - develop/fuel_settings - develop/puppet_tips - develop/pxe_deployment - develop/ostf_contributors_guide - develop/custom-bootstrap-node - develop/modular-architecture diff --git a/devdocs/develop/_images/dependGraph.png b/devdocs/develop/_images/dependGraph.png deleted file mode 100644 index 46e3d94c9..000000000 Binary files a/devdocs/develop/_images/dependGraph.png and /dev/null differ diff --git a/devdocs/develop/_images/dependGraph02.png b/devdocs/develop/_images/dependGraph02.png deleted file mode 100644 index de0d2a3fe..000000000 Binary files a/devdocs/develop/_images/dependGraph02.png and /dev/null differ diff --git a/devdocs/develop/_images/granularDeployment.png b/devdocs/develop/_images/granularDeployment.png deleted file mode 100644 index 8424a46dc..000000000 Binary files a/devdocs/develop/_images/granularDeployment.png and /dev/null differ diff --git a/devdocs/develop/_images/graph.png b/devdocs/develop/_images/graph.png deleted file mode 100644 index f4dce3c46..000000000 Binary files a/devdocs/develop/_images/graph.png and /dev/null differ diff --git a/devdocs/develop/_images/nmanager.png b/devdocs/develop/_images/nmanager.png deleted file mode 100644 index 7a296a20f..000000000 Binary files a/devdocs/develop/_images/nmanager.png and /dev/null differ diff --git a/devdocs/develop/_images/plugin_structure.png b/devdocs/develop/_images/plugin_structure.png deleted file mode 100644 index f0ac031fe..000000000 Binary files a/devdocs/develop/_images/plugin_structure.png and /dev/null differ diff --git a/devdocs/develop/_images/test_docstring_structure.png b/devdocs/develop/_images/test_docstring_structure.png deleted file mode 100644 index 13a87ec3a..000000000 Binary files a/devdocs/develop/_images/test_docstring_structure.png and /dev/null differ diff --git a/devdocs/develop/_images/uml/astute.png b/devdocs/develop/_images/uml/astute.png deleted file mode 100644 index f481847be..000000000 Binary files a/devdocs/develop/_images/uml/astute.png and /dev/null differ diff --git a/devdocs/develop/_images/uml/cluster_deployment.png b/devdocs/develop/_images/uml/cluster_deployment.png deleted file mode 100644 index 2a4555766..000000000 Binary files a/devdocs/develop/_images/uml/cluster_deployment.png and /dev/null differ diff --git a/devdocs/develop/_images/uml/nailgun-agent.png b/devdocs/develop/_images/uml/nailgun-agent.png deleted file mode 100644 index 9f69125d2..000000000 Binary files a/devdocs/develop/_images/uml/nailgun-agent.png and /dev/null differ diff --git a/devdocs/develop/_images/uml/network_verification.png b/devdocs/develop/_images/uml/network_verification.png deleted file mode 100644 index 0256027ca..000000000 Binary files a/devdocs/develop/_images/uml/network_verification.png and /dev/null differ diff --git a/devdocs/develop/_images/uml/nodes_provisioning.png b/devdocs/develop/_images/uml/nodes_provisioning.png deleted file mode 100644 index 23c94e9e1..000000000 Binary files a/devdocs/develop/_images/uml/nodes_provisioning.png and /dev/null differ diff --git a/devdocs/develop/_images/uml/puppetsync.png b/devdocs/develop/_images/uml/puppetsync.png deleted file mode 100644 index 4468455e8..000000000 Binary files a/devdocs/develop/_images/uml/puppetsync.png and /dev/null differ diff --git a/devdocs/develop/addition_examples.rst b/devdocs/develop/addition_examples.rst deleted file mode 100644 index b1d5010d6..000000000 --- a/devdocs/develop/addition_examples.rst +++ /dev/null @@ -1,198 +0,0 @@ -Fuel Development Examples -========================= - -This section provides examples of the Fuel development -process. It builds on the information in the `How to -contribute -`_ -document, and the :doc:`Fuel Development Quick-Start Guide -` which illustrate the development -process for a single Fuel component. These examples show how -to manage development and integration of a more complicated -example. - -Any new feature effort should start with the creation of a -blueprint where implementation decisions and related commits -are tracked. More information on launchpad blueprints can -be found here: `https://wiki.openstack.org/wiki/Blueprints -`_. - -Understanding the Fuel architecture helps you understand -which components any particular addition will impact. The -following documents provide valuable information about the -Fuel architecture, and the provisioning and deployment -process: - -* `Fuel architecture on the OpenStack wiki `_ -* :doc:`Architecture section of Fuel documentation ` -* :doc:`Visual of provisioning tasks ` - -Adding Zabbix Role ------------------- - -This section outlines the steps followed to add a new role -to Fuel. In this case, monitoring service functionality was -added by enabling the deployment of a Zabbix server -configured to monitor an OpenStack environment deployed by -Fuel. - -The monitoring server role was initially planned in `this -blueprint -`_. -Core Fuel developers provided feedback to small -commits via Gerrit and IRC while the work was coming -together. Ultimately the work was rolled up into two -commits including over 23k lines of code, and these two -commits were merged into `fuel-web `_ -and `fuel-library -`_. - -Additions to Fuel-Web for Zabbix role -------------------------------------- - -In fuel-web, the `Support for Zabbix -`_ commit added the -additional role to :doc:`Nailgun `. The -reader is urged to review this commit closely as a good -example of where specific additions fit. In order to -include this as an option in the Fuel deployment process, -the following files were included in the commit for -fuel-web: - -UI components:: - - nailgun/static/translations/core.json - nailgun/static/js/views/cluster_page_tabs/nodes_tab_screens/node_list_screen.jsx - -Testing additions:: - - nailgun/nailgun/test/integration/test_cluster_changes_handler.py - nailgun/nailgun/test/integration/test_orchestrator_serializer.py - -General Nailgun additions:: - - nailgun/nailgun/errors/__init__.py - nailgun/nailgun/fixtures/openstack.yaml - nailgun/nailgun/network/manager.py - nailgun/nailgun/orchestrator/deployment_serializers.py - nailgun/nailgun/rpc/receiver.py - nailgun/nailgun/settings.yaml - nailgun/nailgun/task/task.py - nailgun/nailgun/utils/zabbix.py - -Additions to Fuel-Library for Zabbix role ------------------------------------------ - -In addition to the Nailgun additions, the related Puppet -modules were added to the `fuel-library repository -`_. This -`Zabbix fuel-library integration -`_ commit included -all the puppet files, many of which are brand new modules -specifically for Zabbix, in addition to adjustments to the -following files:: - - deployment/puppet/openstack/manifests/logging.pp - deployment/puppet/osnailyfacter/manifests/cluster_ha.pp - deployment/puppet/osnailyfacter/manifests/cluster_simple.pp - -Once all these commits passed CI and had been reviewed by -both community members and the Fuel PTLs, they were merged -into master. - -Adding Hardware Support ------------------------ - -This section outlines the steps followed to add support for -a Mellanox network card, which requires a kernel driver that -is available in most Linux distributions but was not loaded -by default. Adding support for other hardware would touch -similar Fuel components, so this outline should provide a -reasonable guide for contributors wishing to add support for -new hardware to Fuel. - -It is important to keep in mind that the Fuel node discovery -process works by providing a bootstrap image via PXE. Once -the node boots with this image, a basic inventory of -hardware information is gathered and sent back to the Fuel -controller. If a node contains hardware requiring a unique -kernel module, the bootstrap image must contain that module -in order to detect the hardware during discovery. - -In this example, loading the module in the bootstrap image -was enabled by adjusting the ISO makefile and specifying the -appropriate requirements. - -Adding a hardware driver to bootstrap -------------------------------------- - -The `Added bootstrap support to Mellanox -`_ commit shows how -this is achieved by adding the modprobe call to load the -driver specified in the requirements-rpm.txt file, requiring -modification of only two files in the fuel-main repository:: - - bootstrap/module.mk - requirements-rpm.txt - -.. note:: Any package specified in the bootstrap building procedure - must be listed in the requirements-rpm.txt file explicitly. - The Fuel mirrors must be rebuilt by the OSCI team prior to - merging requests like this one. - -.. note:: Changes made to bootstrap do not affect package sets for - target systems, so in case if you're adding support for NIC, - for example, you have to add installation of all related - packages to kickstart/preceed as well. - -The `Adding OFED drivers installation -`_ commit shows the -changes made to the preseed (for Ubuntu) and kickstart (for -CentOS) files in the fuel-library repository:: - - deployment/puppet/cobbler/manifests/snippets.pp - deployment/puppet/cobbler/templates/kickstart/centos.ks.erb - deployment/puppet/cobbler/templates/preseed/ubuntu-1404.preseed.erb - deployment/puppet/cobbler/templates/snippets/centos_ofed_prereq_pkgs_if_enabled.erb - deployment/puppet/cobbler/templates/snippets/ofed_install_with_sriov.erb - deployment/puppet/cobbler/templates/snippets/ubuntu_packages.erb - -Though this example did not require it, if the hardware -driver is required during the operating system installation, -the installer images (debian-installer and anaconda) would -also need to be repacked. For most installations though, -ensuring the driver package is available during installation -should be sufficient. - -Adding to Fuel package repositories ------------------------------------ - -If the addition will be committed back to the public Fuel -codebase to benefit others, you will need to submit a bug in -the Fuel project to request the package be added to the -repositories. - -Let's look at this process step by step by the example -of `Add neutron-lbaas-agent package -`_ bug: - -* you create a bug in the Fuel project providing full description on - the packages to be added, and assign it to the Fuel OSCI team -* you create a request to add these packages to Fuel requirements-\*.txt - files `Add all neutron packages to requirements - `_ - You receive +1 vote from Fuel CI if these packages already exist on - either Fuel internal mirrors or upstream mirrors for respective OS - type (rpm/deb), or -1 vote in any other case. -* if requested packages do not exist in the upstream OS distributive, - OSCI team builds them and then places on internal Fuel mirrors -* OSCI team rebuilds public Fuel mirrors with `Add all neutron packages to - requirements `_ request -* `Add all neutron packages to requirements - `_ request is merged - -.. note:: The package must include a license that complies - with the Fedora project license requirements for binary - firmware. See the `Fedora Project licensing page - `_ - for more information. diff --git a/devdocs/develop/architecture.rst b/devdocs/develop/architecture.rst deleted file mode 100644 index 40aca0ab7..000000000 --- a/devdocs/develop/architecture.rst +++ /dev/null @@ -1,110 +0,0 @@ -Fuel Architecture -================= - -Good overview of Fuel architecture is represented on -`OpenStack wiki `_. -You can find a detailed breakdown of how this works in the -:doc:`Sequence Diagrams `. - -Master node is the main part of the Fuel project. It contains all the -services needed for network provisioning of other managed nodes, -installing an operating system, and then deploying OpenStack services to -create a cloud environment. *Nailgun* is the most important service. -It is a RESTful application written in Python that contains all the -business logic of the system. A user can interact with it either using -the *Fuel Web* interface or by the means of *CLI utility*. He can create -a new environment, edit its settings, assign roles to the discovered -nodes, and start the deployment process of the new OpenStack cluster. - -Nailgun stores all of its data in a *PostgreSQL* database. It contains -the hardware configuration of all discovered managed nodes, the roles, -environment settings, current deployment status and progress of -running deployments. - -.. image:: _images/uml/nailgun-agent.png - :width: 100% - -Managed nodes are discovered over PXE using a special bootstrap image -and the PXE boot server located on the master node. The bootstrap image -runs a special script called Nailgun agent. The agent **nailgun-agent.rb** -collects the server's hardware information and submits it to Nailgun -through the REST API. - -The deployment process is started by the user after he has configured -a new environment. The Nailgun service creates a JSON data structure -with the environment settings, its nodes and their roles and puts this -file into the *RabbitMQ* queue. This message should be received by one -of the worker processes who will actually deploy the environment. These -processes are called *Astute*. - -.. image:: _images/uml/astute.png - :width: 100% - -The Astute workers are listening to the RabbitMQ queue and receives -messages. They use the *Astute* library which implements all deployment -actions. First, it starts the provisioning of the environment's nodes. -Astute uses XML-RPC to set these nodes' configuration in Cobbler and -then reboots the nodes using *MCollective agent* to let Cobbler install -the base operating system. *Cobbler* is a deployment system that can -control DHCP and TFTP services and use them to network boot the managed -node and start the OS installer with the user-configured settings. - -Astute puts a special message into the RabbitMQ queue that contains -the action that should be executed on the managed node. MCollective -servers are started on all bootstrapped nodes and they constantly listen -for these messages, when they receive a message, they run the required -agent action with the given parameters. MCollective agents are just Ruby -scripts with a set of procedures. These procedures are actions that the -MCollective server can run when asked to. - -When the managed node's OS is installed, Astute can start the deployment -of OpenStack services. First, it uploads the node's configuration -to the **/etc/astute.yaml** file on node using the **uploadfile** agent. -This file contains all the variables and settings that will be needed -for the deployment. - -Next, Astute uses the **puppetsync** agent to synchronize Puppet -modules and manifests. This agent runs an rsync process that connects -to the rsyncd server on the Master node and downloads the latest version -of Puppet modules and manifests. - -.. image:: _images/uml/puppetsync.png - :width: 100% - -When the modules are synchronized, Astute can run the actual deployment -by applying the main Puppet manifest **site.pp**. MCollective agent runs -the Puppet process in the background using the **daemonize** tool. -The command looks like this: -:: - - daemonize puppet apply /etc/puppet/manifests/site.pp - -Astute periodically polls the agent to check if the deployment has -finished and reports the progress to Nailgun through its RabbitMQ queue. - -When started, Puppet reads the **astute.yaml** file content as a fact -and then parses it into the **$fuel_settings** structure used to get all -deployment settings. - -When the Puppet process exits either successfully or with an error, -Astute gets the summary file from the node and reports the results to -Nailgun. The user can always monitor both the progress and the -results using Fuel Web interface or the CLI tool. - -Fuel installs the **puppet-pull** script. Developers can use it if -they need to manually synchronize manifests from the Master node and -run the Puppet process on node again. - -Astute also does some additional actions, depending on environment -configuration, either before the deployment of after successful one: - -* Generates and uploads SSH keys that will be needed during deployment. -* During network verification phase **net_verify.py** script. -* Uploads CirrOS guest image into Glance after the deployment. -* Updates **/etc/hosts** file on all nodes when new nodes are deployed. -* Updates RadosGW map when Ceph nodes are deployed. - -Astute also uses MCollective agents when a node or the entire -environment is being removed. It erases all boot sectors on the node -and reboots it. The node will be network booted with the bootstrap -image again, and will be ready to be used in a new environment. diff --git a/devdocs/develop/custom-bootstrap-node.rst b/devdocs/develop/custom-bootstrap-node.rst deleted file mode 100644 index 2bf75667a..000000000 --- a/devdocs/develop/custom-bootstrap-node.rst +++ /dev/null @@ -1,1274 +0,0 @@ -.. _custom-bootstrap-node: - -Bootstrap node -============== - -The Fuel bootstrap nodes can be based on the CentOS or Ubuntu -distributions and are respectively called CentOS or Ubuntu bootstrap -nodes. In previous versions of Fuel, the Fuel bootstrap nodes -were based exclusively on CentOS. However, since Fuel 7.0, you can -select from the two bootstraps. Initially, the Ubuntu bootstrap was -introduced as an experimental feature. In current version, the Ubuntu -bootstrap feature is fully supported. - -Ubuntu bootstrap ----------------- - -This section describes how to build and use the Ubuntu bootstrap. - -.. note:: - - The CentOS bootstrap located in the - ``/var/www/nailgun/bootstrap`` folder. - The Ubuntu bootstrap is located in the - ``/var/www/nailgun/bootstraps/active`` folder. - The bootstrap location can be changed in the future releases. - -To modify a bootsrtap, use one of the following options: - -* Create a custom image for bootstrap to replace the default one. - -* Modify the copy of original bootstrap image manually - and activate it. - -Let's take a look at every approach in more details. - -.. warning:: Altering the active bootstrap image is quite risky. - Please create a backup copy of the active bootstrap image, - make your changes on a copy of the active bootstrap and activate - the altered image later. - You can always create new custom bootstrap if something goes wrong - and activate the new bootstrap. - -Creating a custom bootstrap node -++++++++++++++++++++++++++++++++ - -You can create a new Ubuntu bootstrap using the -:command:`fuel-bootsrtap` command. -To create and activate a new Ubuntu bootstrap: - -#. Build a new bootstrap image as a ``.tar`` archive. - -#. Import the configured image from the archive. - -#. Activate the new image. - -.. note:: The commands for creating the Ubuntu bootstrap - vary for different versions of Fuel. - -To build the new bootstrap image: - -#. Type the command: - - .. code-block:: console - - fuel-bootstrap build - - **System response:** - - .. code-block:: console - - Try to build image with data: - bootstrap: - container: {format: tar.gz, meta_file: metadata.yaml} - extend_kopts: biosdevname=0 net.ifnames=1 debug ignore_loglevel log_buf_len=10M - print_fatal_signals=1 LOGLEVEL=8 - extra_files: [/usr/share/fuel_bootstrap_cli/files/trusty] - label: 93f117b9-65b7-41fa-ade2-52002989dda1 - modules: - - {mask: kernel, name: kernel, uri: 'http://127.0.0.1:8080/bootstraps/93f117b9-65b7-41fa-ade2-52002989dda1/vmlinuz'} - - {compress_format: xz, mask: initrd, name: initrd, uri: 'http://127.0.0.1:8080/bootstraps/93f117b9-65b7-41fa-ade2-52002989dda1/initrd.img'} - - &id001 {compress_format: xz, container: raw, format: ext4, mask: rootfs, name: rootfs, - uri: 'http://127.0.0.1:8080/bootstraps/93f117b9-65b7-41fa-ade2-52002989dda1/root.squashfs'} - post_script_file: null - root_ssh_authorized_file: /root/.ssh/id_rsa.pub - uuid: 93f117b9-65b7-41fa-ade2-52002989dda1 - - ... - - Build process is in progress. Usually it takes 15-20 minutes. It depends on your Internet connection and hardware performance. - --- Building bootstrap image (do_mkbootstrap) --- - *** Preparing image space *** - Installing BASE operating system into image - Starting new HTTP connection (1): 127.0.0.1 - Starting new HTTP connection (1): mirror.fuel-infra.org - Starting new HTTP connection (1): mirror.fuel-infra.org - Starting new HTTP connection (1): mirror.fuel-infra.org - Building initramfs - Building squashfs - squashfs_image clean-up - Creating archive: /tmp/93f117b9-65b7-41fa-ade2-52002989dda1.tar.gz - --- Building bootstrap image END (do_mkbootstrap) --- - Cleanup chroot - Bootstrap image 93f117b9-65b7-41fa-ade2-52002989dda1 has been built: /tmp/93f117b9-65b7-41fa-ade2-52002989dda1.tar.gz - - - A new bootstrap image has been successfully built. - By default, Fuel places the new bootstrap image into the - ``/tmp`` folder. For example, - ``/tmp/93f117b9-65b7-41fa-ade2-52002989dda1.tar.gz``. - -#. Import the bootstrap image: - - .. code-block:: console - - fuel-bootstrap import /tmp/93f117b9-65b7-41fa-ade2-52002989dda1.tar.gz - - **System response:** - - .. code-block:: console - - fuel-bootstrap import /tmp/93f117b9-65b7-41fa-ade2-52002989dda1.tar.gz - - Try extract /tmp/93f117b9-65b7-41fa-ade2-52002989dda1.tar.gz to /tmp/tmpaLrxol - Bootstrap image 93f117b9-65b7-41fa-ade2-52002989dda1 has been imported. - -#. Activate the bootstrap image: - - .. code-block:: console - - fuel-bootstrap activate 93f117b9-65b7-41fa-ade2-52002989dda1 - - **System response:** - - .. code-block:: console - - Starting new HTTP connection (1): 10.20.0.2 - Starting new HTTP connection (1): 10.20.0.2 - Starting new HTTP connection (1): 10.20.0.2 - Starting new HTTP connection (1): 10.20.0.2 - Bootstrap image 93f117b9-65b7-41fa-ade2-52002989dda1 has been activated. - -.. note:: - - If you use Fuel 7.0, create and activate a custom Ubuntu - bootstrap image using the following commands: - - .. code-block:: console - - fuel-bootstrap-image - fuel-bootstrap-image-set ubuntu - -See also: - -* Fuel Installation Guide - -Modifying initramfs image manually for the bootstrap node -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -The ``fuel-bootstrap`` utility builds Ubuntu bootstrap. The bootstrap is -split into two files: ``initrd.img`` and ``root.squashfs``. -Fuel downloads and unpacks the ``intrd.img`` file as a temporary -file system during the PXE boot. -The image makes initialization and downloads the ``root.squashfs`` image. -After that, the ``root.squashfs`` is unpacked. The mount point of the file -system is switched to ``root.squasfs``. - -There is a possibility to add a package into a bootstrap -"on the fly" using the following command: - -.. code-block:: console - - fuel-bootstrap build --package - -The command adds the package into both images: ``initrd.img`` and -``root.squashfs``. - -You can add an arbitrary files and folders into -``root.squasfs`` (but not to ``initrd.img``) using -the following command: - -.. code-block:: console - - fuel-bootstrap build --extra-dir - -There are tasks that require editing a bootstrap manually. -For example, adding kernel module binaries into ``initramfs`` and ``root.squashfs``. - -To edit the ``initramfs`` (``initrd.img``) image, unpack the image, modify, and pack it back. -The ``initramfs`` image is a compressed ``cpio`` archive. - -.. warning:: The ``initrd.img`` and ``root.squashfs`` location may vary - for different Fuel versions. - -.. warning:: Install ``squashfs-tools`` prior to working with the ``root.squashfs`` image. - -.. warning:: Operating on active bootstrap may lead to the case when - a suddenly rebooted node fails to download bootstrap images ``initrd`` - and ``root.squashfs``. The rebooted node will repeat the attempts until - the bootstrap files have been updated and downloaded successfully. - You can also create a new bootstrap image using the commands - :command:`fuel-bootstrap build` and :command:`fuel-bootstrap import`. - Modify the ``initrd`` and ``root.squashfs`` files as described - below and activate this new image using the command - :command:`fuel-bootstrap active `. - In such case, use the ``/var/www/nailgun/bootstraps/`` - path to your bootstrap instead of ``/var/www/nailgun/bootstraps/active_bootstrap`` - in the commands below. - -To change the ``initramfs`` image (``initrd.img``) and ``root.squashfs``, follow the steps below. - -#. Unpack ``initrd.img`` and ``root.squashfs``: - - #. Create a folder for modifying bootstrap and copy the ``initramfs`` - and ``root.squashfs`` images into it: - - .. code-block:: console - - mkdir /tmp/initrd-orig - cp /var/www/nailgun/bootstraps/active_bootstrap/initrd.img /tmp/initrd-orig/ - cp /var/www/nailgun/bootstraps/active_bootstrap/root.squashfs /tmp/initrd-orig/ - - #. Unpack ``initramfs``. - - #. Uncompress the ``initrd.img`` file: - - .. code-block:: console - - cd /tmp/initrd-orig/ - mv initrd.img initrd.img.xz - xz -d initrd.img.xz - - #. Unpack the ``cpio`` archive to the ``initramfs`` folder: - - .. code-block:: console - - mkdir initramfs - cd initramfs - cpio -i < ../initrd.img - - #. Unpack the ``root.squashfs`` image into the ``squashfs-root`` folder: - - .. code-block:: console - - cd /tmp/initrd-orig/ - unsquashfs root.squashfs - - #. See the RAM content that you will have in the bootstrap: - - .. code-block:: console - - ls -l /tmp/initrd-orig/initramfs - ls -l /tmp/initrd-orig/squashfs-root - -#. Modify ``initrd.img`` and ``root.squashfs`` - - .. warning:: - - To add or update a new kernel module, use the :command:`depmod` command. - It will update the ``modules.alias`` and ``modules.dep`` files informing - the kernel about the new module. - - .. note:: - - There is `a safe way to update kernel modules`_ for Ubuntu, when - the new module is installed into the ``/lib/modules//updates`` folder. - The previous kernel module is still kept in the system, but hidden by - the new module. When something goes wrong with the new module it can be - easily removed from the ``/update`` folder and the older version of module - will be returned back. - - .. _`a safe way to update kernel modules`: http://www.linuxvox.com/2009/10/update-kernel-modules-the-smart-and-safe-way/ - - #. Modify it as you need. For example, copy new kernel module ``aacraid`` - into the ``initrd`` corresponding kernel folder: - - .. code-block:: console - - mkdir -p /tmp/initrd-orig/initramfs/lib/modules/3.13.0-77-generic/updates - cp aacraid.ko /tmp/initrd-orig/initramfs/lib/modules/3.13.0-77-generic/updates - - #. Modify the ``squashfs-root`` by copying the new kernel module ``aacraid`` - into the specified folder (kernel version may be different in your case): - - .. code-block:: console - - mkdir -p /tmp/initrd-orig/squashfs-root/lib/modules/3.13.0-77-generic/updates - cp aacraid.ko /tmp/initrd-orig/squashfs-root/lib/modules/3.13.0-77-generic/updates - - #. Run :command:`depmod` to update information about kernel modules on ``initrd`` and ``root.squashfs``: - - .. code-block:: console - - depmod -a -b /tmp/initrd-orig/initramfs/ -F /tmp/initrd-orig/squashfs-root/boot/System.map-3.13.0-77-generic 3.13.0-77-generic - depmod -a -b /tmp/initrd-orig/squashfs-root/ -F /tmp/initrd-orig/squashfs-root/boot/System.map-3.13.0-77-generic 3.13.0-77-generic - - See :command:`depmod` command parameters: - - .. code-block:: console - - depmod -a -b -F - - **System response** - - .. code-block:: console - - ==== ================================================================= - -a Rebuild information for all modules - -b Base folder, If your modules are not currently in the (normal) - directory /lib/modules/version. In our case it were the folders - where initramfs and root.squasfs - -F location of the System.map produced when the kernel was built - ==== ================================================================= - - .. note:: - - It is important to pass a correct kernel version to the :command:`depmod` command - at the end of the parameters. Otherwise, the version of the current kernel on - the Fuel master node will be used. - - The following files will be modified in the ``initramfs`` and ``squashfs-root`` - folders after running the :command:`depmod` command: - - * ``lib/modules/3.13.0-77-generic/modules.alias`` - * ``lib/modules/3.13.0-77-generic/modules.alias.bin`` - * ``lib/modules/3.13.0-77-generic/modules.dep`` - * ``lib/modules/3.13.0-77-generic/modules.dep.bin`` - * ``lib/modules/3.13.0-77-generic/modules.symbols.bin`` - - To get more information on how to: - - * Pass options to a module - * Start ``dependent`` modules - * Start ``black-list`` modules - - see the ``modprobe.d`` man page. - -#. Pack the ``initramfs`` and ``squashfs-root`` - - #. Pack the ``initramfs`` back to ``initfamfs.img.new`` image: - - .. code-block:: console - - cd /tmp/initrd-orig/initramfs - find . | cpio --quiet -o -H newc | xz --check=crc32 > ../initrd.img.new - - #. Pack the ``squashfs`` to the ``root.squashfs.new`` - - .. warning:: - - ``squashfs`` utilities (``mksquashfs``) installed on a user's machine or - the Fuel Master node can be incompatible with ``squashfs`` code in the bootstrap - kernel. To verify the generated ``squashfs image`` is compatible with the - bootstrap kernel, use ``mksquashfs`` utility installed in ``squashfs-root``. - A simple way to do that is using bind mounts: - - .. code-block:: console - - cd /tmp/initrd-orig - mkdir -p /tmp/initrd-orig/squashfs-root/mnt/dst - mkdir -p /tmp/initrd-orig/dst - mount --bind dst squashfs-root/mnt/dst - chroot squashfs-root mksquashfs / /mnt/dst/root.squashfs.new -comp xz -noappend -e /mnt/dst - # clean up - umount squashfs-root/mnt/dst - - The output of the mksquashfs command should be as follows: - - .. code-block:: console - - mksquashfs squashfs-root root.squashfs.new -comp xz - - quashfs squashfs-root root.squashfs.new -comp xz - Parallel mksquashfs: Using 2 processors - Creating 4.0 filesystem on root.squashfs.new, block size 131072. - [================================================\] 105857/105857 100% - - Exportable Squashfs 4.0 filesystem, xz compressed, data block size 131072 - compressed data, compressed metadata, compressed fragments, compressed xattrs - duplicates are removed - Filesystem size 598514.76 Kbytes (584.49 Mbytes) - 47.89% of uncompressed filesystem size (1249842.98 Kbytes) - Inode table size 933186 bytes (911.31 Kbytes) - 23.04% of uncompressed inode table size (4050950 bytes) - Directory table size 1904568 bytes (1859.93 Kbytes) - 48.93% of uncompressed directory table size (3892589 bytes) - Number of duplicate files found 7780 - Number of inodes 121770 - Number of files 106698 - Number of fragments 4627 - Number of symbolic links 6388 - Number of device nodes 81 - Number of fifo nodes 0 - Number of socket nodes 0 - Number of directories 8603 - Number of ids (unique uids + gids) 18 - Number of uids 4 - root (0) - unknown (102) - unknown (100) - unknown (101) - Number of gids 17 - root (0) - unknown (44) - unknown (29) - tty (5) - man (15) - disk (6) - unknown (42) - unknown (102) - unknown (43) - unknown (103) - mem (8) - unknown (106) - ftp (50) - unknown (101) - unknown (105) - adm (4) - unknown (104) - - #. Copy new files and update the current bootstrap - - .. code-block:: console - - cp dst/root.squashfs.new initrd.img.new /var/www/nailgun/bootstraps/active_bootstrap/ - cd /var/www/nailgun/bootstraps/active_bootstrap/ - mv initrd.img initrd.img.orig - mv root.squashfs root.squashfs.orig - cp initrd.img.new initrd.img - cp root.squashfs.new root.squashfs - cobbler sync - - #. Clean up. Remove ``/tmp/initrd-orig`` temporary folder: - - .. code-block:: console - - rm -Rf /tmp/initrd-orig - -.. _chroot: - -Creating Ubuntu chroot on the Fuel Master node ----------------------------------------------- - -.. note:: There is an alternative way of creating a ``chroot`` folder on the - Fuel Master node. You can download prebuilt `VM images`_ for Ubuntu and - run it with your favorite hypervisor. You can also use an IBP Ubuntu image - which is built to your Fuel Master node. - -.. _`VM images`: http://uec-images.ubuntu.com/trusty/current - -This section describes how to create a chroot with Ubuntu on the Fuel Master -node and provides the implementation script. - -Creating a ``chroot`` folder on Ubuntu can be useful for: - -* Rebuilding kernel modules for Ubuntu -* Creating DKMS DEB packages from sources -* Building kernel modules binaries for a given kernel version with DKMS - -The script below creates ``chroot`` on the Fuel Master node using a prebuilt -Ubuntu cloud image **trusty-server-cloudimg-amd64-root.tar.gz** that is -downloaded from the `VM images`_ site. The name of the image and the link -are kept in the ``UBUNTU_IMAGE`` and ``PREBUILT_IMAGE_LINK`` variables -respectively. - -.. note:: Before you copy and run the script, modify the ``UBUNTU_IMAGE``, - ``PREBUILT_IMAGE_LINK``, ``DISTRO_RELEASE``, ``KERNEL_FLAVOR``, or - ``MIRROR_DISTRO`` variables if required. - -The script completes the following steps: - -#. Creates ``chroot`` in the ``/tmp`` folder with the *ubuntu-chroot.XXXXX* - template name (where *XXXXX* is substituted with digits and characters, - for example, ``/tmp/ubuntu-chroot.Yusk8G``). -#. Mounts the ``/proc`` filesystem and creates a ``/dev`` folder with links to - ``/proc`` into the ``chroot`` folder. -#. Prepares a configuration for the ``apt`` package manager. -#. Downloads and installs an additional set of packages, listed in the - ``UBUNTU_PKGS`` variable, to ``chroot``. The packages are required to build - DKMS and deal with the DEB packages. These packages are: ``linux-headers``, - ``dkms``, ``build-essential``, and ``debhelper``. - -.. note:: The Fuel Master node should have access to the Internet to download - a required DEB package from the Ubuntu repository. - - Unmount the ``chroot/proc`` file system and delete ``chroot`` - when you do not need it anymore. - -.. code-block:: console - - #!/bin/bash - - # Define the kernel flavor and path to the link to a prebuild image. - [ -z "$KERNEL_FLAVOR" ] && KERNEL_FLAVOR="-generic-lts-trusty" - [ -z "$DISTRO_RELEASE" ] && DISTRO_RELEASE="trusty" - [ -z "$UBUNTU_IMAGE" ] && UBUNTU_IMAGE="trusty-server-cloudimg-amd64-root.tar.gz" - [ -z "$PREBUILT_IMAGE_LINK" ] && \ - PREBUILT_IMAGE_LINK="http://uec-images.ubuntu.com/${DISTRO_RELEASE}/current" - - UBUNTU_PKGS="linux-headers${KERNEL_FLAVOR} linux-firmware dkms build-essential debhelper" - - # Create a temporary directory (ubuntu-chroot) using the command: - # [ -z "$root_dir" ] && - root_dir=$(mktemp -d --tmpdir ubuntu-chroot.XXXXX) - chmod 755 ${root_dir} - - # Download a prebuilt image and un-tar it. - # Check if it has been downloaded already. - if [ ! -e "$UBUNTU_IMAGE" ]; then - # download - wget ${PREBUILT_IMAGE_LINK}/${UBUNTU_IMAGE} - fi - tar -xzvf "${UBUNTU_IMAGE}" -C ${root_dir} - - # Install required packages and resolve dependencies. - chroot $root_dir env \ - LC_ALL=C \ - DEBIAN_FRONTEND=noninteractive \ - DEBCONF_NONINTERACTIVE_SEEN=true \ - TMPDIR=/tmp \ - TMP=/tmp \ - PATH=$PATH:/sbin:/bin \ - apt-get update - - chroot $root_dir env \ - LC_ALL=C \ - DEBIAN_FRONTEND=noninteractive \ - DEBCONF_NONINTERACTIVE_SEEN=true \ - TMPDIR=/tmp \ - TMP=/tmp \ - PATH=$PATH:/sbin:/bin \ - apt-get install --force-yes --yes $UBUNTU_PKGS - - echo "Don't forget to delete $root_dir at the end" - - -Adding DKMS kernel modules into bootstrap (Ubuntu) --------------------------------------------------- - -The key strength of `Dynamic Kernel Module Support (DKMS) `_ -is the ability to rebuild the required kernel module for a different version of -kernels. But there is a drawback of installing DKMS kernel modules into -bootstrap. DKMS builds a module during installation, that queries the -installation of additional packages like ``linux-headers`` and a tool-chain -building. It unnecessarily oversizes the bootstrap. The DKMS package actually -should be installed into an IBP (image-based provisioning) image, which will -be deployed on nodes and be re-built during the kernel updates. - -.. note:: - You can add kernel modules on bootstrap by making the - kernel module binaries in a form of a DEB package and by installing the - package on bootstrap like other packages. - -DKMS provides an ability to build a DEB package and a disk driver archive -on the fly from sources. - -Ubuntu packages can be built on the Fuel Master node in ``chroot`` with Ubuntu -deployed in ``chroot``. For details, see :ref:`chroot`. - -**To create a DKMS package in the .deb format:** - -#. Copy the required module sources to a folder with the corresponding name - located in ``/usr/src`` of ``chroot``. -#. Create a ``dkms.conf`` configuration file in the ``/usr/src`` directory. -#. Optimize the ``dkms.conf`` file as described in the - :ref:`dkms_example` section. - -.. note:: - If you already have a DKMS package built with sources and want to simply - export the kernel module binaries to DEB format, install the existing - DKMS package into the ``chroot`` folder (and skip the - :ref:`Creating DKMS ` chapter). - -.. _create_dkms: - -Creating a DKMS package from sources -++++++++++++++++++++++++++++++++++++ - -Before creating a ``DKMS`` package from sources, verify that you have -completed the following steps: - -#. Create the :ref:`chroot folder `. -#. Install the following packages to the ``chroot`` folder: ``DKMS``, - ``build-essential``, and ``debhelper``. - -Once you complete the steps above, create a DKMS package from sources: - -#. Create a folder for a required kernel module in the *-* - format in the ``/usr/src`` directory located in ``chroot``. - For example, if the module name is i40e and module version is 1.3.47, - create a ``/usr/src/i40e-1.3.47`` folder in ``chroot``. - -#. Copy the sources into the created folder. - -#. Create and modify a ``dkms.conf`` file in the - ``/usr/src/-/`` directory. - -Example of a minimal dkms.conf file -*********************************** - -Below is an example of a minimal -`dkms.conf `_ file: - -.. code-block:: console - - PACKAGE_NAME="$module_name-dkms" - PACKAGE_VERSION="$module_version" - BUILT_MODULE_NAME="$module_name" - DEST_MODULE_LOCATION="/updates" - -The parameters in the minimal ``dkms.conf`` file are obligatory but not -sufficient to build a module. Therefore, proceed with adding additional -parameters to the ``dkms.conf`` file to make it operational. See the -:ref:`dkms_example` section for details. - -.. _dkms_example: - -Example of an improved dkms.conf file -************************************* - -To make your ``dkms.conf`` file operational, add and configure the following -fields: ``MAKE``, ``CLEAN``, and ``BUILD_MODULE_LOCATION``. There are also internal -variables in DKMS that you can use in ``dkms.conf``, for example, -``$kernelver``. For details, see `DKMS Manual page `_. - -The table below lists the fields that we use in our example to optimize the -``dkms.conf`` file: - -======================= =================================================== -PACKAGE_NAME The DKMS package name. -PACKAGE_VERSION The DKMS package version. -BUILT_MODULE_NAME The binary kernel module name to be installed. -DEST_MODULE_LOCATION The install location of the binary kernel module. -MAKE The :command:`make` command to build the kernel - module bounded to the kernel version, sources, and - so on. -BUILD_KERNEL The kernel version for which the module should be - build. Use an internal variable ``$kernelver`` here. -CLEAN The ``clean`` directive to clean up after the module - build. -BUILT_MODULE_LOCATION The location of the sources in the DKMS tree. -REMAKE_INITRD Whether the ``initrd`` will be rebuilt or not when - the module is installed. -======================= =================================================== - -For the i40e module that is used in our example, the following configuration -is applied: - -.. code-block:: console - - PACKAGE_NAME="i40e-dkms" - PACKAGE_VERSION="1.3.47" - BUILT_MODULE_NAME="i40e" - DEST_MODULE_LOCATION="/updates" - MAKE="make -C src/ KERNELDIR=/lib/modules/\${kernelver}/build" - BUILD_KERNEL="\${kernelver}" - CLEAN="make -C src/ clean" - BUILT_MODULE_LOCATION="src/" - REMAKE_INITRD="yes" - -.. note:: - The path that is set in the configuration file is bound to the DKMS tree. - For example, ``DEST_MODULE_LOCATION="/updates"`` actually means - ``/lib/modules/$kernelver/updates``. - - We recommend that you install new modules in the ``/updates`` directory for a - `safe update `_ - of the kernel modules. - -Exporting DKMS package and kernel binaries -****************************************** - -When ``dkms.conf`` is ready, you can build the binaries in ``chroot`` and -export the ``DKMS`` package with kernel module binaries to the ``.deb`` format. - -Use the DKMS commands to add and build a DKMS module for a particular kernel -version. - -When the build is done, run the following commands to create a DEB package -and a disk-driver ``.tar`` archive in ``chroot``: - -.. code-block:: console - - mkdeb - mkdriverdisk - -See details in the bash script below. - -The script builds a DKMS package in ``chroot``. The output is a disk-driver -archive containing the module binaries built against the kernel installed in -the ``chroot`` . - -The second produced package is a DKMS module. The output is placed into the -``/tmp/dkms-deb`` folder: - -.. code-block:: console - - $ ls /tmp/dkms-deb/ - i40e-1.3.47-ubuntu-dd.tar i40e-dkms_1.3.47_all.deb - -.. code-block:: console - - The script requires following parameters to be provided: - $1 - ``chroot`` folder with Ubuntu has been deployed - $2 - module name - $3 - module version - $4 - path to the folder where is sources of the kernel module - -.. warning:: - The script unmounts the ``/proc`` file system from ``chroot`` and - finally deletes ``chroot`` made by the first script. Run the script with - the root privileges. - -.. code-block:: console - - #!/bin/bash - # Check passed parameters, expectations are following: - # $1 - chroot folder with Ubuntu has been deployed - # $2 - module name - # $3 - module version - # $4 - path to the folder where is sources of the kernel module - - if [ $# != 4 ] ; - then - echo "ERR: Passed wrong number of parameters, the expectation are following" - echo " $1 - chroot folder with Ubuntu has been deployed" - echo " $2 - module name" - echo " $3 - module version" - echo " $4 - path to the folder where is sources of the module" - echo "$0 " - exit 1; - else - root_dir=$1 # chroot folder - module_name=$2 - module_version=$3 - module_src_dir=$4 - fi - if [ ! -d "$root_dir" ] || [ ! -d "$module_src_dir" ] ; - then - echo "ERR: The $root_dir or $module_src_dir was not found"; - exit 1; - fi - - output_dir="/tmp/dkms-deb" - - # Create the folder ${root_dir}/usr/src/${module-name}-${module-version} - mkdir -p "${root_dir}/usr/src/${module_name}-${module_version}" - chmod 755 "${root_dir}/usr/src/${module_name}-${module_version}" - - # Copy sources into the folder - cp -R "$module_src_dir"/* \ - ${root_dir}/usr/src/${module_name}-${module_version} - - # Create the dkms.conf package - cat > "${root_dir}/usr/src/${module_name}-${module_version}/dkms.conf" <<-EOF - MAKE="make -C src/ KERNELDIR=/lib/modules/\${kernelver}/build" - BUILD_KERNEL="\${kernelver}" - CLEAN="make -C src/ clean" - BUILT_MODULE_NAME="$module_name" - BUILT_MODULE_LOCATION="src/" - DEST_MODULE_LOCATION="/updates" - PACKAGE_NAME="$module_name-dkms" - PACKAGE_VERSION="$module_version" - REMAKE_INITRD="yes" - EOF - - # Deduce the kernel version - KERNELDIR=$(ls -d ${root_dir}/lib/modules/*) - kv="${KERNELDIR##*/}" - - # Build the binaries by DKMS - # Add the dkms - chroot $root_dir env \ - LC_ALL=C \ - DEBIAN_FRONTEND=noninteractive \ - DEBCONF_NONINTERACTIVE_SEEN=true \ - TMPDIR=/tmp \ - TMP=/tmp \ - PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ - BUILD_KERNEL=${kv} \ - dkms add -m "${module_name}"/"${module_version}" -k ${kv} - - # Build the kernel module by dkms - chroot $root_dir env \ - LC_ALL=C \ - DEBIAN_FRONTEND=noninteractive \ - DEBCONF_NONINTERACTIVE_SEEN=true \ - TMPDIR=/tmp \ - TMP=/tmp \ - PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ - BUILD_KERNEL=${kv} \ - dkms build -m "${module_name}"/"${module_version}" -k ${kv} - - # Create the deb-dkms package - chroot $root_dir env \ - LC_ALL=C \ - DEBIAN_FRONTEND=noninteractive \ - DEBCONF_NONINTERACTIVE_SEEN=true \ - TMPDIR=/tmp \ - TMP=/tmp \ - PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ - BUILD_KERNEL=${kernelver} \ - dkms mkdeb -m "${module_name}"/"${module_version}" -k ${kv} - - # Create the disk-driver archive with - # module binaries in deb package ready to install on bootstrap - chroot $root_dir env \ - LC_ALL=C \ - DEBIAN_FRONTEND=noninteractive \ - DEBCONF_NONINTERACTIVE_SEEN=true \ - TMPDIR=/tmp \ - TMP=/tmp \ - BUILD_KERNEL=${kv} \ - PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ - dkms mkdriverdisk -m "${module_name}"/"${module_version}" \ - -k ${kv} -d ubuntu --media tar - - # Create /tmp/dkms-deb folder and copy the created deb file into it - if [ ! -d "${output_dir}" ]; - then - mkdir -p ${output_dir} - fi - # Copy the built deb dkms package into the folder - # and driver disk tar archive.i - # The archive contains the binary module as a deb package for given kernel version - # - cp ${root_dir}/var/lib/dkms/${module_name}/${module_version}/deb/*.deb ${output_dir} - cp ${root_dir}/var/lib/dkms/${module_name}/${module_version}/driver_disk/*.tar ${output_dir} - - # Don't forget to umount ${root_dir}/proc and remove ${root_dir} - umount ${root_dir}/proc - rm -Rf ${root_dir} - -Extracting kernel module binaries -********************************* - -The ``/tmp/dkms-deb`` folder contains a built DKMS DEB package. You can -install it into IBP. The ``DEB`` package with the kernel module binaries -built for a given kernel version is archived in the disk-driver archive. - -Unpack the ``.tar`` file and copy the ``.deb`` file into the repository. -For example, if the archive is ``i40e-1.3.47-ubuntu-dd.tar`` and the i40e -module was built for kernel 3.13.0-77-generic, the output should be the -following: - -.. code-block:: console - - tar -xvf i40e-1.3.47-ubuntu-dd.tar - ./ - ./ubuntu-drivers/ - ./ubuntu-drivers/3.13.0/ - ./ubuntu-drivers/3.13.0/i40e_1.3.47-3.13.0-77-generic_x86_64.deb - ... - -The ``i40e_1.3.47-3.13.0-77-generic_x86_64.deb`` package contains the kernel -module binaries for kernel 3.13.0-77-generic that you install on the -bootstrap with the kernel. - -.. warning:: - Updating the new kernel for Ubuntu requires rebuilding the DKMS package - against a new kernel in order to get the module binaries package. - -Known Issues -************ - -Not all the kernel module sources can be compiled by DKMS. - -DKMS builds the given drivers sources against different kernels versions. -The ABI (kernel functions) may be changed among different kernels, and -the compilation of a module can potentially fail when calling -non-existing of expired functions. - -The example below shows an attempt to build a module taken from one kernel -version against the other kernel version: - -.. code-block:: console - - # dkms build -m be2net/10.4u - - Kernel preparation unnecessary for this kernel. Skipping... - - Building module: - make clean - make: *** No rule to make target `clean'. Stop. - (bad exit status: 2) - { make KERNELRELEASE=3.13.0-77-generic -C /lib/modules/3.13.0-77-generic/build SUBDIRS=/var/lib/dkms/be2net/10.4u/build modules; } >> /var/lib/dkms/be2net/10.4u/build/make.log 2>&1 - (bad exit status: 2) - ERROR (dkms apport): binary package for be2net: 10.4u not found - Error! Bad return status for module build on kernel: 3.13.0-77-generic (x86_64) - Consult /var/lib/dkms/be2net/10.4u/build/make.log for more information. - -The ``make.log`` file contains errors that some functions or structures -have not been declared or declared implicitly: - -.. code-block:: console - - # cat /var/lib/dkms/be2net/10.4u/build/make.log - DKMS make.log for be2net-10.4u for kernel 3.13.0-77-generic (x86_64) - - make: Entering directory `/usr/src/linux-headers-3.13.0-77-generic' - CC [M] /var/lib/dkms/be2net/10.4u/build/be_main.o - /var/lib/dkms/be2net/10.4u/build/be_main.c: In function ‘be_mac_addr_set’: - /var/lib/dkms/be2net/10.4u/build/be_main.c:315:2: error: implicit declaration of function ‘ether_addr_copy’ [-Werror=implicit-function-declaration] - ether_addr_copy(netdev->dev_addr, addr->sa_data); - ^ - /var/lib/dkms/be2net/10.4u/build/be_main.c: In function ‘be_get_tx_vlan_tag’: - /var/lib/dkms/be2net/10.4u/build/be_main.c:727:2: error: implicit declaration of function ‘skb_vlan_tag_get’ [-Werror=implicit-function-declaration] - vlan_tag = skb_vlan_tag_get(skb); - ^ - /var/lib/dkms/be2net/10.4u/build/be_main.c: In function ‘be_get_wrb_params_from_skb’: - /var/lib/dkms/be2net/10.4u/build/be_main.c:789:2: error: implicit declaration of function ‘skb_vlan_tag_present’ [-Werror=implicit-function-declaration] - if (skb_vlan_tag_present(skb)) { - ^ - /var/lib/dkms/be2net/10.4u/build/be_main.c: In function ‘be_insert_vlan_in_pkt’: - /var/lib/dkms/be2net/10.4u/build/be_main.c:1001:3: error: implicit declaration of function ‘vlan_insert_tag_set_proto’ [-Werror=implicit-function-declaration] - skb = vlan_insert_tag_set_proto(skb, htons(ETH_P_8021Q), - ^ - /var/lib/dkms/be2net/10.4u/build/be_main.c:1001:7: warning: assignment makes pointer from integer without a cast [enabled by default] - skb = vlan_insert_tag_set_proto(skb, htons(ETH_P_8021Q), - ^ - /var/lib/dkms/be2net/10.4u/build/be_main.c:1011:7: warning: assignment makes pointer from integer without a cast [enabled by default] - skb = vlan_insert_tag_set_proto(skb, htons(ETH_P_8021Q), - ^ - /var/lib/dkms/be2net/10.4u/build/be_main.c: In function ‘be_xmit_workarounds’: - /var/lib/dkms/be2net/10.4u/build/be_main.c:1132:3: error: implicit declaration of function ‘skb_put_padto’ [-Werror=implicit-function-declaration] - if (skb_put_padto(skb, 36)) - ^ - /var/lib/dkms/be2net/10.4u/build/be_main.c: In function ‘be_xmit’: - /var/lib/dkms/be2net/10.4u/build/be_main.c:1299:19: error: ‘struct sk_buff’ has no member named ‘xmit_more’ - bool flush = !skb->xmit_more; - -To make the kernel module sources compatible with different kernels, the -sources should contain the wrappers, which are re-declaring changed functions -depending on the kernel version. This work should be done by driver developers. - -The example below shows the ``compat.h`` file wrapper: - -.. code-block:: console - - /* - * This file is part of the Linux NIC driver for Emulex networking products. - * - * Copyright (C) 2005-2015 Emulex. All rights reserved. - * - * EMULEX and SLI are trademarks of Emulex. - * www.emulex.com - * linux-drivers@emulex.com - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of version 2 of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful. - * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, - * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A - * PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE - * EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. - * See the GNU General Public License for more details, a copy of which - * can be found in the file COPYING included with this package - */ - - #ifndef BE_COMPAT_H - #define BE_COMPAT_H - - #ifdef RHEL_RELEASE_CODE - #define RHEL - #endif - - #ifndef RHEL_RELEASE_CODE - #define RHEL_RELEASE_CODE 0 - #endif - - #ifndef RHEL_RELEASE_VERSION - #define RHEL_RELEASE_VERSION(a,b) (((a) << 8) + (b)) - #endif - - #ifndef NETIF_F_HW_VLAN_CTAG_DEFINED - #define NETIF_F_HW_VLAN_CTAG_TX NETIF_F_HW_VLAN_TX - #define NETIF_F_HW_VLAN_CTAG_RX NETIF_F_HW_VLAN_RX - #define NETIF_F_HW_VLAN_CTAG_FILTER NETIF_F_HW_VLAN_FILTER - #endif - - /*************************** NAPI backport ********************************/ - #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 27) - - /* RHEL 5.4+ has a half baked napi_struct implementation. - * Bypass it and use simulated NAPI using multiple netdev structs - */ - #ifdef RHEL - typedef struct napi_struct rhel_napi; - #endif - - #define netif_napi_add netif_napi_add_compat - #define netif_napi_del netif_napi_del_compat - #define napi_gro_frags(napi) napi_gro_frags((rhel_napi*) napi) - #define napi_get_frags(napi) napi_get_frags((rhel_napi*) napi) - #define vlan_gro_frags(napi, g, v) vlan_gro_frags((rhel_napi*) napi, g, v); - #define napi_schedule(napi) netif_rx_schedule((napi)->dev) - #define napi_enable(napi) netif_poll_enable((napi)->dev) - #define napi_disable(napi) netif_poll_disable((napi)->dev) - #define napi_complete(napi) napi_gro_flush((rhel_napi *)napi); \ - netif_rx_complete(napi->dev) - #define napi_schedule_prep(napi) netif_rx_schedule_prep((napi)->dev) - #define __napi_schedule(napi) __netif_rx_schedule((napi)->dev) - - #define napi_struct napi_struct_compat - - struct napi_struct_compat { - #ifdef RHEL - rhel_napi napi; /* must be the first member */ - #endif - struct net_device *dev; - int (*poll) (struct napi_struct *napi, int budget); - }; - - extern void netif_napi_del_compat(struct napi_struct *napi); - extern void netif_napi_add_compat(struct net_device *, struct napi_struct *, - int (*poll) (struct napi_struct *, int), int); - #endif /*********************** NAPI backport *****************************/ - -CentOS bootstrap ----------------- - -This section describes creating a custom CentOS bootstrap image. - -.. note:: - - Since the Fuel 8.0 version, CentOS bootstrap is depricated and not - recommended for using. - -Creating and injecting the initrd_update into bootstrap -+++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -A typical use case for creating initrd_update looks as follows: -a great number of proprietary drivers for equipment cannot be -shipped with GA Fuel ISO due to legal issues -and should be installed by users themselves. - -That means, you can add (or inject) the required issues (drivers, -scripts etc.) during Fuel ISO -installation procedure. - -Injection workflow consists of several stages: - -#. Prepare the injected initramfs image with the required kernel modules (for CentOS). -#. Modify bootstrap (CentOS) - -**Prepare injected initramfs image for CentOS** - -The injected initramfs image should contain -the files what are going to be put on (or let's say injected into) -the original initramfs on the bootstrap in addition to -the deployed (original) RAM file system. - -The injected initramfs image should have the following structure: - -:: - - / - /lib/modules//kernel// - /etc/modprobe.d/.conf - -Let's put all required files into the folder called *dd-src* and create the image. -For example, we need the 2.6.32-504 (CentOs 6.6) kernel: - -#. Create the working folder dd-src: - - :: - - mkdir dd-src - -#. Put the kernel modules into: - - :: - - mkdir -p ./dd-src/lib/modules/2.6.32-504.1.3.el6.x86_64/kernel/drivers/scsi - cp hpvsa.ko ./dd-src/lib/modules/2.6.32-504.1.3.el6.x86_64/kernel/drivers/scsi - - -#. Put the *.conf* file with the modprobe command into - the *etc/modprobe.d/* folder: - - :: - - mkdir -p ./dd-src/etc/modprobe.d/ - echo modprobe hpvsa > ./dd-src/etc/modprobe.d/hpvsa.conf - chmod +x ./dd-src/etc/modprobe.d/hpvsa.conf - - - There is the second (deprecated) way: - create the */etc/rc.modules* executable file and list the command to probe with the module name. - Do not use */etc/rc.local* file for this purpose, - because it is too late for init hardware: - - :: - - mkdir ./dd-src/etc - echo modprobe hpvsa > ./dd-src/etc/rc.modules - chmod +x ./dd-src/etc/rc.modules - - - - -#. Create the dd-src.tar.gz file for coping to the Fuel Master node: - - :: - - tar -czvf dd-src.tar.gz ./dd-src - - The *dd-src.tar.gz* file can now be copied to the Fuel Master node. - - -**Adding initrd_update image to the bootstrap** - -.. note:: Currently, the bootstrap is based on CentOS (kernel and modules). - -Assume that the Fuel Master node has been deployed: - -#. Connect to the Fuel Master node: - - :: - - ssh root@ - -#. Prepare initramfs update image: - - :: - - tar -xzvf dd-src.tar.gz - cd dd-src - find . | cpio --quiet -o -H newc | gzip -9 > /tmp/initrd_update.img - -#. Copy into the TFTP (PXE) bootstrap folder: - - :: - - cp /tmp/initrd_update.img /var/www/nailgun/bootstrap/ - chmod 755 /var/www/nailgun/bootstrap/initrd_update.img - -#. Copy inside the cobbler container to the folder: - - :: - - dockerctl copy initrd_update.img cobbler:/var/lib/tftpboot/initrd_update.img - -#. Modify the bootstrap menu initrd parameter. - - * Log into the cobbler container: - - :: - - dockerctl shell cobbler - - * Get the variable kopts variable value: - - :: - - cobbler profile dumpvars --name=bootstrap | grep kernel_options - kernel_options : ksdevice=bootif locale=en_US text mco_user=mcollective initrd=initrd_update.img biosdevname=0 lang url=http://10.20.0.2:8000/api priority=critical mco_pass=HfQqE2Td kssendmac - - * Add *initrd=initrd_update.img* at the beginning of the string - and re-sync the container. It turns into the kernel - parameter passing to the kernel on boot - 'initrd=initramfs.img,initrd_update.img': - - :: - - cobbler profile edit --name bootstrap --kopts='initrd=initrd_update.img ksdevice=bootif lang= locale=en_US text mco_user=mcollective priority=critical url=http://10.20.0.2:8000/api biosdevname=0 mco_pass=HfQqE2Td kssendmac' - cobbler sync - - -Modifying initramfs image manually for bootstrap node -+++++++++++++++++++++++++++++++++++++++++++++++++++++ - -To edit the initramfs (initrd) image, -you should unpack it, modify and pack back. -Initramfs image is a gzip-ed cpio archive. - -To change initramfs image, follow these steps: - -#. Create a folder for modifying initramfs image and copy the initramfs image into it: - - :: - - mkdir /tmp/initrd-orig - dockerctl copy cobbler:/var/lib/tftpboot/images/bootstrap/initramfs.img /tmp/initrd-orig/ - -#. Unpack initramfs image. First of all, unzip it: - - :: - - cd /tmp/initrd-orig/ - mv initramfs.img initramfs.img.gz - gunzip initramfs.img.gz - -#. Unpack the cpio archive to the initramfs folder: - - :: - - mkdir initramfs - cd initramfs - cpio -i < ../initramfs.img - -#. Now you have the file system what you have in the RAM on the bootstrap: - - :: - - ls -l /tmp/initrd-orig/initramfs - -#. Modify it as you need. For example, copy files or modify the scripts: - - :: - - cp hpvsa.ko lib/modules/2.6.32-504.1.3.el6.x86_64/kernel/drivers/scsi/ - echo "modprobe hpvsa" > etc/modprobe.d/hpvsa.conf - - - To get more information on how to pass options to - the module, start dependent modules or black-list modules please, - consult see the *modprobe.d* man page. - - :: - - vi etc/modprobe.d/blacklist.conf - -#. Pack the initramfs back to **initramfs.img.new** image: - - :: - - cd /tmp/initrd-orig/initramfs - find . | cpio --quiet -o -H newc | gzip -9 > /tmp/initramfs.img.new - -#. Clean up. Remove */tmp/initrd-orig* temporary folder: - - :: - - rm -Rf /tmp/initrd-orig/ - - -Creating a custom bootstrap node -++++++++++++++++++++++++++++++++ - -This option requires further investigation -and will be introduced in the near future. - - -**Replacing default bootstrap node with the custom one** - -Let's suppose that you have created or modified -the initramfs image. It is placed in the */tmp* folder under **initramfs.img.new** name. - -To replace the default bootstrap with the custom, -follow these steps: - -#. Save the previous initramfs image: - - :: - - mv /var/www/nailgun/bootstrap/initramfs.img /var/www/nailgun/bootstrap/initramfs.img.old - - -#. Copy the new initramfs image into the bootstrap folder: - - :: - - cd /tmp - cp initramfs.img.new /var/www/nailgun/bootstrap/initramfs.img - dockerctl copy /var/www/nailgun/bootstrap/initramfs.img cobbler:/var/lib/tftpboot/images/bootstrap/initramfs.img - -#. Make the Cobbler update the files: - - :: - - cobbler sync - diff --git a/devdocs/develop/env.rst b/devdocs/develop/env.rst deleted file mode 100644 index db7fc9ef8..000000000 --- a/devdocs/develop/env.rst +++ /dev/null @@ -1,370 +0,0 @@ -Fuel Development Environment -============================ - -.. warning:: Fuel ISO build works only on 64-bit operating system. - -If you are modifying or augmenting the Fuel source code or if you -need to build a Fuel ISO from the latest branch, you will need -an environment with the necessary packages installed. This page -lays out the steps you will need to follow in order to prepare -the development environment, test the individual components of -Fuel, and build the ISO which will be used to deploy your -Fuel master node. - -The basic operating system for Fuel development is Ubuntu Linux. -The setup instructions below assume Ubuntu 14.04 (64 bit) though most of -them should be applicable to other Ubuntu and Debian versions, too. - -Each subsequent section below assumes that you have followed the steps -described in all preceding sections. By the end of this document, you -should be able to run and test all key components of Fuel, build the -Fuel master node installation ISO, and generate documentation. - -.. _getting-source: - -Getting the Source Code ------------------------ - -Source code of OpenStack Fuel can be found at git.openstack.org or -GitHub. - -Follow these steps to clone the repositories for each of -the Fuel components: -:: - - apt-get install git - git clone https://github.com/openstack/fuel-main - git clone https://github.com/openstack/fuel-web - git clone https://github.com/openstack/fuel-ui - git clone https://github.com/openstack/fuel-agent - git clone https://github.com/openstack/fuel-astute - git clone https://github.com/openstack/fuel-ostf - git clone https://github.com/openstack/fuel-library - git clone https://github.com/openstack/fuel-docs - - -.. _building-fuel-iso: - -Building the Fuel ISO ---------------------- - -The "fuel-main" repository is the only one required in order -to build the Fuel ISO. The make script then downloads the -additional components (Fuel Library, Nailgun, Astute and OSTF). -Unless otherwise specified in the makefile, the master branch of -each respective repo is used to build the ISO. - -The basic steps to build the Fuel ISO from trunk in an -Ubuntu 14.04 environment are: -:: - - apt-get install git - git clone https://github.com/openstack/fuel-main - cd fuel-main - ./prepare-build-env.sh - make iso - -If you want to build an ISO using a specific commit or repository, -you will need to modify the "Repos and versions" section in the -config.mk file found in the fuel-main repo before executing "make -iso". For example, this would build a Fuel ISO against the v5.0 -tag of Fuel: -:: - - # Repos and versions - FUELLIB_COMMIT?=tags/5.0 - NAILGUN_COMMIT?=tags/5.0 - FUEL_UI_COMMIT?=tags/5.0 - ASTUTE_COMMIT?=tags/5.0 - OSTF_COMMIT?=tags/5.0 - - FUELLIB_REPO?=https://github.com/openstack/fuel-library.git - NAILGUN_REPO?=https://github.com/openstack/fuel-web.git - FUEL_UI_REPO?=https://github.com/openstack/fuel-ui.git - ASTUTE_REPO?=https://github.com/openstack/fuel-astute.git - OSTF_REPO?=https://github.com/openstack/fuel-ostf.git - -To build an ISO image from custom gerrit patches on review, edit the -"Gerrit URLs and commits" section of config.mk, e.g. for -https://review.openstack.org/#/c/63732/8 (id:63732, patch:8) set: -:: - - FUELLIB_GERRIT_COMMIT?=refs/changes/32/63732/8 - -If you are building Fuel from an older branch that does not contain the -"prepare-build-env.sh" script, you can follow these steps to prepare -your Fuel ISO build environment on Ubuntu 14.04: - -#. ISO build process requires sudo permissions, allow yourself to run - commands as root user without request for a password:: - - echo "`whoami` ALL=(ALL) NOPASSWD: ALL" | sudo tee -a /etc/sudoers - -#. Install software:: - - sudo apt-get update - sudo apt-get install apt-transport-https - echo deb http://mirror.yandex.ru/mirrors/docker/ docker main | sudo tee /etc/apt/sources.list.d/docker.list - sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9 - sudo apt-get update - sudo apt-get install lxc-docker - sudo apt-get update - sudo apt-get remove nodejs nodejs-legacy npm - sudo apt-get install software-properties-common python-software-properties - sudo add-apt-repository -y ppa:chris-lea/node.js - sudo apt-get update - sudo apt-get install build-essential make git ruby ruby-dev rubygems debootstrap createrepo \ - python-setuptools yum yum-utils libmysqlclient-dev isomd5sum \ - python-nose libvirt-bin python-ipaddr python-paramiko python-yaml \ - python-pip kpartx extlinux unzip genisoimage nodejs multistrap \ - lrzip python-daemon - sudo gem install bundler -v 1.2.1 - sudo gem install builder - sudo pip install xmlbuilder jinja2 - -#. If you haven't already done so, get the source code:: - - git clone https://github.com/openstack/fuel-main - -#. Now you can build the Fuel ISO image:: - - cd fuel-main - make iso - -#. If you encounter issues and need to rebase or start over:: - - make clean #remove build/ directory - make deep_clean #remove build/ and local_mirror/ - -.. note:: - - In case you use a virtual machine for building the image, verify the - following: - - - Both ``BUILD_DIR`` and ``LOCAL_MIRROR`` build directories are - out of the shared folder path in the `config.mk - `_ - file. For more information, see: - - - `Shared folders of VitrualBox - `_ - documentation - - - `Synced folders of Vargant - `_ - documentation - - - To prevent a random docker unexpected termination, a virtual - machine has a kernel that supports the ``aufs`` file system. - - To install the kernel, run: - - .. code-block:: console - - sudo apt-get install --yes linux-image-extra-virtual - - Reboot the kernel when the installation is complete. Check that - docker is using ``aufs`` by running: - - .. code-block:: console - - sudo docker info 2>&1 | grep -q 'Storage Driver: aufs' \ - && echo OK || echo KO - - For more information, see `Select a storage driver for docker - `_. - -You can also use the following tools to make your work and development process -with Fuel easier: - -* CGenie fuel-utils - a set of tools to interact with code on a Fuel Master node created - from the ISO. It provides the *fuel* command - that gives a simple way to upload Python or UI code (with staticfiles compression) - to Docker containers, SSH into machine and into the container, - display the logs etc. - -* Vagrant SaltStack-based -Vagrant box definition with quick and basic Fuel - environment with fake tasks. - This is useful for UI or Nailgun development. - -You can download both tools from the -`fuel-dev-tools `_. - -Nailgun (Fuel-Web) ------------------- - -Nailgun is the heart of Fuel project. It implements a REST API as well -as deployment data management. It manages disk volume configuration data, -network configuration data and any other environment specific data -necessary for a successful deployment of OpenStack. It provides the -required orchestration logic for provisioning and -deployment of the OpenStack components and nodes in the right order. -Nailgun uses a SQL database to store its data and an AMQP service to -interact with workers. - -Requirements for preparing the nailgun development environment, along -with information on how to modify and test nailgun can be found in -the Nailgun Development Instructions document: :ref:`nailgun-development` - - -Astute ------- - -Astute is the Fuel component that represents Nailgun's workers, and -its function is to run actions according to the instructions provided -from Nailgun. Astute provides a layer which encapsulates all the details -about interaction with a variety of services such as Cobbler, Puppet, -shell scripts, etc. and provides a universal asynchronous interface to -those services. - -#. Astute can be found in fuel-astute repository - -#. Install Ruby dependencies:: - - sudo apt-get install git curl - curl -sSL https://get.rvm.io | bash -s stable - source ~/.rvm/scripts/rvm - rvm install 2.1 - rvm use 2.1 - git clone https://github.com/nulayer/raemon.git - cd raemon - git checkout b78eaae57c8e836b8018386dd96527b8d9971acc - gem build raemon.gemspec - gem install raemon-0.3.0.gem - cd .. - rm -Rf raemon - -#. Install or update dependencies and run unit tests:: - - cd fuel-astute - ./run_tests.sh - -#. (optional) Run Astute MCollective integration test (you'll need to - have MCollective server running for this to work):: - - cd fuel-astute - bundle exec rspec spec/integration/mcollective_spec.rb - -Running Fuel Puppet Modules Unit Tests --------------------------------------- - -If you are modifying any puppet modules used by Fuel, or including -additional modules, you can use the PuppetLabs RSpec Helper -to run the unit tests for any individual puppet module. Follow -these steps to install the RSpec Helper: - -#. Install PuppetLabs RSpec Helper:: - - cd ~ - gem2deb puppetlabs_spec_helper - sudo dpkg -i ruby-puppetlabs-spec-helper_0.4.1-1_all.deb - gem2deb rspec-puppet - sudo dpkg -i ruby-rspec-puppet_0.1.6-1_all.deb - -#. Run unit tests for a Puppet module:: - - cd fuel/deployment/puppet/module - rake spec - -Installing Cobbler ------------------- - -Install Cobbler from GitHub (it can't be installed from PyPi, and deb -package in Ubuntu is outdated):: - - cd ~ - git clone git://github.com/cobbler/cobbler.git - cd cobbler - git checkout release24 - sudo make install - -Building Documentation ----------------------- - -You should prepare your build environment before you can build -this documentation. First you must install Java, using the -appropriate procedure for your operating system. - -Java is needed to use PlantUML to automatically generate UML diagrams -from the source. You can also use `PlantUML Server -`_ for a quick preview of your -diagrams and language documentation. - -Then you need to install all the packages required for creating of -the Python virtual environment and dependencies installation. -:: - - sudo apt-get install make postgresql postgresql-server-dev-9.1 - sudo apt-get install python-dev python-pip python-virtualenv - -Now you can create the virtual environment and activate it. -:: - - virtualenv fuel-web-venv - . fuel-web-venv/bin/activate - -And then install the dependencies. -:: - - pip install -r nailgun/test-requirements.txt - -Now you can look at the list of available formats and generate -the one you need: -:: - - cd docs - make help - make html - -There is a helper script **build-docs.sh**. It can perform -all the required steps automatically. The script can build documentation -in required format. -:: - - Documentation build helper - -o - Open generated documentation after build - -c - Clear the build directory - -n - Don't install any packages - -f - Documentation format [html,signlehtml,latexpdf,pdf,epub] - -For example, if you want to build HTML documentation you can just -use the following script, like this: -:: - - ./build-docs.sh -f html -o - -It will create virtualenv, install the required dependencies and -build the documentation in HTML format. It will also open the -documentation with your default browser. - -If you don't want to install all the dependencies and you are not -interested in building automatic API documentation there is an easy -way to do it. - -First remove autodoc modules from extensions section of **conf.py** -file in the **docs** directory. This section should be like this: -:: - - extensions = [ - 'rst2pdf.pdfbuilder', - 'sphinxcontrib.plantuml', - ] - -Then remove **develop/api_doc.rst** file and reference to it from -**develop.rst** index. - -Now you can build documentation as usual using make command. -This method can be useful if you want to make some corrections to -text and see the results without building the entire environment. -The only Python packages you need are Sphinx packages: -:: - - Sphinx - sphinxcontrib-actdiag - sphinxcontrib-blockdiag - sphinxcontrib-nwdiag - sphinxcontrib-plantuml - sphinxcontrib-seqdiag - -Just don't forget to rollback all these changes before you commit your -corrections. diff --git a/devdocs/develop/fuel_settings.rst b/devdocs/develop/fuel_settings.rst deleted file mode 100644 index c0002fd03..000000000 --- a/devdocs/develop/fuel_settings.rst +++ /dev/null @@ -1,130 +0,0 @@ -Using Fuel settings -~~~~~~~~~~~~~~~~~~~ - -Fuel uses a special method to pass settings from Nailgun to Puppet manifests: - -- Before the deployment process begins, - Astute uploads all settings - to the */etc/astute.yaml* files that are located on each node. -- When Puppet is run, - Facter reads the contents of all these */etc/astute.yaml* files - and creates a single file called *$astute_settings_yaml*. -- The **parseyaml** function (at the beginning of the *site.pp* file) - then parses these settings - and creates a rich data structure called *$fuel_settings*. - All of the settings used during node deployment are stored there - and can be used anywhere in Puppet code. - -For example, single top level variables are available as -*$::fuel_settings['debug']*. -More complex structures are also available as -values of *$::fuel_settings* hash keys -and can be accessed like normal hashes and arrays. -Many aliases and generated values are provided -to help you retrieve values easily. -You can create a variable from any hash key in *$fuel_settings* -and work with this variable within your local scope -or from other classes, using fully qualified paths:: - - $debug = $::fuel_settings['debug'] - -Some variables and structures are generated from the settings hash -by filtering and transformation functions. -For example the $node structure only contains -settings of the current node, -filtered from the has of all nodes. -It can be accessed as:: - - $node = filter_nodes($nodes_hash, 'name', $::hostname) - -If you are going to use your module inside the Fuel Library -and need some settings, -you can get them from this *$::fuel_settings* structure. -Most variables related to network and OpenStack services configuration -are already available there and you can use them as they are. -If your modules require some additional or custom settings, -you must either use **Custom Attributes** -by editing the JSON files before deployment, or, -if you are integrating your project with the Fuel Library, -you can contact the Fuel UI developers -and ask them to add your configuration options to the Fuel setting panel. - -After you have defined all classes you need inside your module, -you can add this module's declaration -into the Fuel manifests such as -*cluster_simple.pp* and *cluster_ha.pp* located inside -the *osnailyfacter/manifests* folder -or, if your additions are related to another class, -can add them into that class. - -Example module -~~~~~~~~~~~~~~ - -To demonstrate how to add a new module to the Fuel Library, -let us add a simple class -that changes the terminal color of Red Hat based systems. -Our module is named *profile* and has only one class.:: - - profile - profile/manifests - profile/manifests/init.pp - profile/files - profile/files/colorcmd.sh - -init.pp could have a class definition such as::: - - class profile { - if $::osfamily == 'RedHat' { - file { 'colorcmd.sh' : - ensure => present, - owner => 'root', - group => 'root', - mode => '0644', - path => "/etc/profile.d/colorcmd.sh", - source => 'puppet:///modules/profile/colorcmd.sh', - } - } - } - -This class downloads the *colorcmd.sh* file -and places it in the defined location -when the class is run on a Red Hat or CentOS system. -The profile module can be added to Fuel modules -by uploading its folder to */etc/puppet/modules* -on the Fuel Master node. - -Now we need to declare this module somewhere inside the Fuel manifests. -Since this module should be run on every server, -we can use our main *site.pp* manifest -found inside the *osnailyfacter/examples* folder. -On the deployed master node, -this file will be copied to */etc/puppet/manifests* -and used to deploy Fuel on all other nodes. -The only thing we need to do here is to add the *include profile* -to the end of the */etc/puppet/manifests/site.pp* file -on the already deployed master node -and to the *osnailyfacter/examples/site.pp* file inside the Fuel repository. - -Declaring a class outside of a node block -forces this class to be included everywhere. -If you want to include your module only on some nodes, -you can add its declaration -to the blocks associated with the role that is running on those nodes -inside the *cluster_simple* and *cluster_ha* classes. - -You can add some additional logic to allow this module to be disabled, -either from the Fuel UI or by passing Customer Attributes -to the Fuel configuration.:: - - if $::fuel_settings['enable_profile'] { - include 'profile' - } - -This block uses the *enable_profile* variable -to enable or disable inclusion of the profile module. -The variable should be passed from Nailgun and saved -to the */etc/astute.yaml* files on managed nodes. -You can do this either by downloading the settings files -and manually editing them before deployment -or by asking the Fuel UI developers to include additional options -in the settings panel. diff --git a/devdocs/develop/live_masternode.rst b/devdocs/develop/live_masternode.rst deleted file mode 100644 index 11395778a..000000000 --- a/devdocs/develop/live_masternode.rst +++ /dev/null @@ -1,9 +0,0 @@ -Fuel Development Environment on Live Master Node -================================================ - -If you need to deploy your own developer version of FUEL on live -Master Node, you can use the helper scripts, that are available -in the `fuel-dev-tools ` repository. - -Help information about fuel-dev-tools can be found by running it -with the '-h' parameter. diff --git a/devdocs/develop/modular-architecture.rst b/devdocs/develop/modular-architecture.rst deleted file mode 100644 index 1d63e8351..000000000 --- a/devdocs/develop/modular-architecture.rst +++ /dev/null @@ -1,394 +0,0 @@ -Modular Architecture -==================== - -The idea behind the modular architecture introduced in Fuel 6.1 is the separation of the legacy site.pp manifests to a group of small manifests. Each manifest can be designed to do only a limited part of the deployment process. These manifests can be applied by Puppet the same way as it was done in Fuel 6.0 or older. The deployment process in Fuel 6.1 consists of a sequential application of small manifests in a predefined order. - -Using smaller manifests instead of the monolithic ones has the following advantages: - -* **Independent development** - As a developer, you can work only with those Fuel components that you are interested in. A separate manifest - can be dedicated wholly to a single task without any interference from other components and developers. This - task may require the system to be in some state before the deployment can be started and the task may require - some input data be available. But other than that each task is on its own. - -* **Granular testing** - With granular deployment introduced in Fuel 6.1, any finished task can be tested independently. Testing can be - automated with autotests; you can snapshot and revert the environment to a previous state; or you can manually - run tests in your environment. With Fuel 6.0 or older, testing consumes a considerable amount of time as there - is no way to test only a part of the deployment -- each new change requires the whole deployment to be started - from scratch. See also the `granular deployment blueprint `_. - -* **Encapsulation** - Puppet deems all resources to be unique within the catalog and the way it works with dependencies and - ordering. Normally one cannot take a third party module and expect that it will work as designed within the - Puppet infrastructure. Modular manifests, introduced in Fuel 6.1, solve this by making every single task use - its own catalog without directly interfering with other tasks. - -* **Self-Testing** - Granular architecture allows making tests for every task. These tests can be run either after the task to - check if it is successful or before the task to check if the system is in the required state to start the - task. These tests can be used by the developer as acceptance tests, by the Continuous Integration (CI) to - determine if the changes can be merged, or during the real deployment to control the whole process and to - raise alarm if something goes wrong. - -* **Using multiple tools** - Sometimes you may use a tool other than Puppet (from shell scripts to Python or Ruby, and even binary - executables). Granular deployment allows using any tools you see fit for the task. Tasks, tests and pre/post - hooks can be implemented using anything the developer knows best. In Fuel 6.1 only pre/post hooks can use - non-Puppet tasks. - -Granular deployment process ---------------------------- - -Granular deployment is implemented using the Nailgun plugin system. Nailgun uses the deployment graph data to determine what tasks on which nodes should be run. This data graph is traversed and sent to Astute as an ordered list of tasks to be executed with the information on which nodes they should be run. - -Astute receives this data structure and starts running the tasks one by one in the following order: - - #. Pre-deploy actions - #. Main deployment tasks - #. Post-deploy actions - -Each tasks reports back if it is successful. Astute stops the deployment on any failed task. - -.. image:: _images/granularDeployment.png - -Task Graph ----------- - -A task graph is built by Nailgun from *tasks.yaml* files during Fuel Master node bootstrap: - - :: - - fuel rel --sync-deployment-tasks --dir /etc/puppet/ - -*tasks.yaml* files describe a group of tasks (or a single task). - - :: - - - id: netconfig - type: puppet - groups: [primary-controller, controller, cinder, compute, ceph-osd, zabbix-server, primary-mongo, mongo] - required_for: [deploy] - requires: [hiera] - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/netconfig.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - -where: - - * ``id`` - Each task must have the unique ID. - * ``type`` - Determines how the tasks should be executed. Currently there are Puppet and exec types. - * ``groups`` - Groups are used to determine on which nodes these tasks should be started and are mostly related to the node roles. - * ``required_for`` - The list of tasks that require this task to start. Can be empty. - * ``requires`` - The list of tasks that are required by this task to start. Can be empty. - * Both the ``requires`` and ``required_for`` fields are used to build the dependency graph and to determine the order of task execution. - * ``parameters`` - The actual payload of the task. For the Puppet task these can be paths to modules (puppet_modules) and the manifest (puppet_manifest) to apply; the exec type requires the actual command to run. - * ``timeout`` determines how long the orchestrator should wait (in seconds) for the task to complete before marking it as failed. - -Graph example -------------- - - :: - - - id: netconfig - type: puppet - groups: [primary-controller, controller, cinder, compute, ceph-osd, zabbix-server, primary-mongo, mongo] - required_for: [deploy_start] - requires: [hiera] - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/netconfig.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - - :: - - - id: tools - type: puppet - groups: [primary-controller, controller, cinder, compute, ceph-osd, zabbix-server, primary-mongo, mongo] - required_for: [deploy_start] - requires: [hiera] - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/tools.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - - - id: hosts - type: puppet - groups: [primary-controller, controller, cinder, compute, ceph-osd, zabbix-server, primary-mongo, mongo] - required_for: [deploy_start] - requires: [netconfig] - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/hosts.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - - - id: firewall - type: puppet - groups: [primary-controller, controller, cinder, compute, ceph-osd, zabbix-server, primary-mongo, mongo] - required_for: [deploy_start] - requires: [netconfig] - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/firewall.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - - - id: hiera - type: puppet - groups: [primary-controller, controller, cinder, compute, ceph-osd, zabbix-server, primary-mongo, mongo] - required_for: [deploy_start] - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/hiera.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - -This graph data will be processed to the following graph when imported to the Nailgun. Deploy task is an anchor used to start the graph traversal and is hidden from the image. - -.. image:: _images/graph.png - -Nailgun will run the hiera task first, then netconfig or tools, and then firewall or hosts. Astute will start each task on those nodes whose roles are present in the groups field of each task. - -Modular manifests ------------------ - - Starting with Fuel 6.1, granular deployment allows using a number of small manifests instead of the single monolithic one. These small manifests are placed in the ``deployment/puppet/osnailyfacter/modular`` folder and its subfolders. In Fuel 6.0 or older there was a single entry point manifest used -- located at ``deployment/puppet/osnailyfacter/examples/site.pp`` in the `fuel-library `_ repository. - -To write a modular manifest, you will need to take all the resources, classes and definitions you are using to deploy your component and place them into a single file. This manifest should be able to do everything that is required for your component. - -The system should be in some state before you will be able to start your task. For example, database, Pacemaker, or Keystone should be present. - -You should also satisfy the missing dependencies. Some of the manifests may have internal dependencies on other manifests and their parts. You will have to either remove these dependencies or make dummy classes to satisfy them. - -Modular example ---------------- - -Here is an example of a modular manifest that installs Apache and creates a basic site. - - :: - - >>> site.pp - - $fuel_settings = parseyaml($astute_settings_yaml) - - File { - owner => ‘root’, - group => ‘root’, - mode => ‘0644’, - } - - package { ‘apache’ : - ensure => ‘installed’, - } - - service { ‘apache’ : - ensure => ‘running’, - enable => ‘true’, - } - - file { ‘/etc/apache.conf’ : - ensure => present, - content => template(‘apache/config.erb’), - } - - $www_root = $fuel_settings[‘www_root’] - - file { “${www_root}/index.html” : - ensure => present, - content => ‘hello world’, - } - -As the first line of any granular Puppet manifest, add the following: - - :: - - notice("MODULAR: $$$TASK_ID_OR_NAME$$$") - -It will help you debug by finding a place in ``puppet.log`` where your task started. - -Now let's split the manifest into several tasks: - - :: - - >>> apache_install.pp - package { ‘apache’ : - ensure => ‘installed’, - } - - >>> apache_config.pp - File { - owner => ‘root’, - group => ‘root’, - mode => ‘0644’, - } - - $www_root = hiera(‘www_root’) - - file { ‘/etc/apache.conf’ : - ensure => present, - content => template(‘apache/config.erb’), - } - - >>> create_site.pp - File { - owner => ‘root’, - group => ‘root’, - mode => ‘0644’, - } - - $www_root = hiera(‘www_root’) - - file { “${www_root}/index.html” : - ensure => present, - content => ‘hello world’, - } - - >>> apache_start.pp - service { ‘apache’ : - ensure => ‘running’, - enable => ‘true’, - } - -We have just created several manifests. Each will do just its simple action. First we install an Apache package, then we create a configuration file, then create a sample site, and, finally, start the service. Each of these tasks now can be started separately together with any other task. We have also replaced ``$fuel_settings`` with hiera calls. - -Since there are some dependencies, we cannot start the Apache service without installing the package first, but we can start the service just after the package installation without the configuration and sample site creation. - -So there are the following tasks: - - * install - * config - * site - * start - * hiera (to enable the hiera function) - -A visual representation of the dependency graph will be the following: - -.. image:: _images/dependGraph.png - -**start**, **config**, and **site** require the package to be installed. **site** and **config** require the **hiera** function to work. Apache should be configured and **site** should be created to start. - -Now, let’s write a data yaml to describe this structure: - - :: - - - id: hiera - type: puppet - role: [test] - required_for: [deploy] - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/hiera.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - - - id: install - type: puppet - role: [test] - required_for: [deploy] - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/apache_install.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - - - id: config - type: puppet - role: [test] - required_for: [deploy] - requires: [hiera, install] - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/apache_config.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - - - id: site - type: puppet - role: [test] - required_for: [deploy] - requires: [install, hiera] - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/create_site.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - - - id: start - type: puppet - role: [test] - required_for: [deploy] - requires: [install, config, site] - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/apache_start.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - -Nailgun can process this data file and tell Astute to deploy all the tasks in the required order. Other nodes or other deployment modes may require more tasks or tasks run in different order. - -Now, let's say you have a new apache_proxy class, and want to add it to the setup: - - :: - - >>> apache_proxy/init.pp - - file { ‘/etc/apache.conf’ : - owner => ‘root’, - group => ‘root’, - mode => ‘0644’, - ensure => present, - source => puppet:///apache/proxy.conf, - } -> - - service { ‘apache’ : - ensure => running, - enable => true, - } - -This tasks updates the main Apache configuration as well, and it conflicts with the previous configuration tasks. It would not be possible to combine them in a single catalog. It also attempts to enable the Apache service, which produces a new duplicate error. - -Granular deployment solves this. You can still use them together without trying to do something with duplicates or dependency problems. - -.. image:: _images/dependGraph02.png - -We have just inserted a new proxy task between the **config** and **start** tasks. The proxy task will rewrite the configuration file created in the **config** task making the **config** task pointless. This setup will still work as expected and we will have a working Apache-based proxy. Apache will be started on the proxy task but the **start** task will not produce any errors due to Puppet's idempotency. - -There are also `granular noop tests `_ based on rspec-puppet. These CI tests will put -1 for any new Puppet task not covered with tests. - -Testing -------- - -Testing these manifests is easier than having a single monolithic manifest. - -After writing each file you can manually apply it to check if the task works as expected. - -If the task is complex enough, it can benefit from automated acceptance testing. These tests can be implemented using any tool you as a developer see fit. - -For example, let’s try using `http://serverspec.org `_. This is an rspec extension that is very convenient for server testing. - -The only thing the install task does is the package installation and it has no preconditions. The spec file for it may look like this: - - :: - - require 'spec_helper' - describe package(‘apache’) do - it { should be_installed } - end - -Running the spec should produce an output similar to the following: - - :: - - Package "nginx" - should be installed - - Finished in 0.17428 seconds - 1 example, 0 failures - -There are many different resource types *serverspec* can work with, and this can easily be extended. Other tasks can be tested with specs like the following: - - :: - - describe service('apache') do - it { should be_enabled } - it { should be_running } - end - - describe file(‘/etc/apache.conf’) do - it { should be_file } - its(:content) { should match %r{DocumentRoot /var/www/html} } - end diff --git a/devdocs/develop/module_structure.rst b/devdocs/develop/module_structure.rst deleted file mode 100644 index 23a6b98ba..000000000 --- a/devdocs/develop/module_structure.rst +++ /dev/null @@ -1,423 +0,0 @@ -Contributing to Fuel Library -============================ - -This chapter explains how to add a new module or project into the Fuel Library, -how to integrate with other components, -and how to avoid different problems and potential mistakes. -The Fuel Library is a very big project -and even experienced Puppet users may have problems -understanding its structure and internal workings. - -Adding new modules to fuel-library -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -*Case A. Pulling in an existing module* - -If you are adding a module that is the work of another project -and is already tracked in a separate repo: - -1. Create a review request with an unmodified copy - of the upstream module from which you are working - and *no* other related modifications. - - * This review should also contain the commit hash from the upstream repo - in the commit message. - * The review should be evaluated to determine its suitability - and either rejected - (for licensing, code quality, outdated version requested) - or accepted without requiring modifications. - * The review should not include code that calls this new module. - -2. Any changes necessary to make it work with Fuel - should then be proposed as a dependent change(s). - -*Case B. Adding a new module* - -If you are adding a new module that is a work purely for Fuel -and is not tracked in a separate repo, -submit incremental reviews that consist of -working implementations of features for your module. - -If you have features that are necessary but do not yet work fully, -then prevent them from running during the deployment. -Once your feature is complete, -submit a review to activate the module during deployment. - -Contributing to existing fuel-library modules -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -As developers of Puppet modules, we tend to collaborate with the Puppet -OpenStack community. As a result, we contribute to upstream modules all of the -improvements, fixes and customizations we make to improve Fuel as well. -That implies that every contributor must follow Puppet DSL basics, -`puppet-openstack dev docs -`_ -and `Puppet rspec tests -`_ -requirements. - -The most common and general rule is that upstream modules should be modified -only when bugfixes and improvements could benefit everyone in the community. -And appropriate patch should be proposed to the upstream project prior -to Fuel project. - -In other cases (like applying some very specific custom logic or settings) -contributor should submit patches to ``openstack::*`` `classes -`_ - -Fuel library includes custom modules as well as ones forked from upstream -sources. Note that ``Modulefile``, if any exists, should be used in order -to recognize either given module is forked upstream one or not. -In case there is no ``Modulefile`` in module's directory, the contributor may -submit a patch directly to this module in Fuel library. -Otherwise, he or she should submit patch to upstream module first, and once -merged or +2 recieved from a core reviewer, the patch should be backported to -Fuel library as well. Note that the patch submitted for Fuel library should -contain in commit message the upstream commit SHA or link to github pull-request -(if the module is not on git.openstack.org) or Change-Id of gerrit patch. - -The Puppet modules structure -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Code that is contributed into the Fuel Library -should be organized into a Puppet module. -A module is a self-contained set of Puppet code -that is usually made to perform a specific function. -For example, you could have a module for each service -you are going to configure or for every part of your project. -Usually it is a good idea to make a module independent -but sometimes it may require or be required by other modules. -You can think of a module as a sort of library. - -The most important part of every Puppet module is its **manifests** folder. -This folder contains Puppet classes and definitions -which also contain resources managed by this module. -Modules and classes also form namespaces. -Each class or definition should be placed into a single file -inside the manifests folder -and this file should have the same name as the class or definition. -The module should have a top level class -that serves as the module's entry point -and is named same as the module. -This class should be placed into the *init.pp* file. -This example module shows the standard structure -that every Puppet module should follow:: - - example - example/manifests/init.pp - example/manifests/params.pp - example/manifests/client.pp - example/manifests/server - example/manifests/server/vhost.pp - example/manifests/server/service.pp - example/templates - example/templates/server.conf.erb - example/files - example/files/client.data - -The first file in the *manifests* folder is named *init.pp* -and should contain the entry point class of this module. -This class should have the same name as the module:: - - class example { - - } - -The second file is *params.pp*. -This file is not mandatory but is often used -to store different configuration values and parameters -that are used by other classes of the module. -For example, it could contain the service name and package name -of our hypothetical example module. -Conditional statements might be included -if you need to change default values in different environments. -The *params* class should be named as a child -to the module's namespace as are all other classes of the module:: - - class example::params { - $service = 'example' - $server_package = 'example-server' - $client_package = 'example-client' - $server_port = '80' - } - -All other files inside the manifests folder -contain classes as well and can perform any action -you might want to identify as a separate piece of code. -This generally falls into sub-classes that do not require its users -to configure the parameters explicitly, -or may be optional classes that are not required in all cases. -In the following example, -we create a client class that defines a client package -that will be installed and placed into a file called *client.pp*:: - - class example::client { - include example::params - - package { $example::params::client_package : - ensure => installed, - } - - } - -As you can see, we have used the package name from params class. -Consolidating all values that might require editing into a single class, -as opposed to hardcoding them, -allows you to reduce the effort required -to maintain and develop the module further in the future. -If you are going to use any values from the params class, -you should include it first to force its code -to execute and create all required variables. - -You can add more levels into the namespace structure if you want. -Let's create server folder inside our manifests folder -and add the *service.pp* file there. -It would be responsible for installing and running -the server part of our imaginary software. -Placing the class inside the subfolder adds one level -into the name of the contained class.:: - - class example::server::service ( - $port = $example::params::server_port, - ) inherits example::params { - - $package = $example::params::server_package - $service = $example::params::service - - package { $package : - ensure => installed, - } - - service { $service : - ensure => running, - enabled => true, - hasstatus => true, - hasrestart => true, - } - - file { 'example_config' : - ensure => present, - path => '/etc/example.conf', - owner => 'root', - group => 'root', - mode => '0644', - content => template('example/server.conf.erb'), - } - - file { 'example_config_dir' : - ensure => directory, - path => '/etc/example.d', - owner => 'example', - group => 'example', - mode => '0755', - } - - Package[$package] -> File['example_config', 'example_config_dir'] ~> - Service['example_config'] - - } - -This example is a bit more complex. Let's see what it does. - -Class *example::server::service* is **parametrized** -and can accept one parameter: -the port to which the server process should bind. -It also uses a popular "smart defaults" hack. -This class inherits the params class and uses its default values -only if no port parameter is provided. -In this case, you cannot use *include params* -to load the default values -because it is called by the *inherits example::params* clause -of the class definition. - -Inside our class, we take several variables from the params class -and declare them as variables of the local scope. -This is a convenient practice to make their names shorter. - -Next we declare our resources. -These resources are package, service, config file and config dir. -The package resource installs the package -whose name is taken from the variable -if it is not already installed. -File resources create the config file and config dir; -the service resource starts the daemon process and enables its autostart. - -The final part of this class is the *dependency* declaration. -We have used a "chain" syntax to specify the order of evaluation -of these resources. -It is important to install the package first, -then install the configuration files -and only then start the service. -Trying to start the service before installing the package will definitely fail. -So we need to tell Puppet that there are dependencies between our resources. - -The arrow operator that has a tilde instead of a minus sign (~>) -means not only dependency relationship -but also *notifies* the object to the right of the arrow to refresh itself. -In our case, any changes in the configuration file -would make the service restart and load a new configuration file. -Service resources react to the notification event -by restating the managed service. -Other resources may instead perform other supported actions. - -The configuration file content is generated by the template function. -Templates are text files that use Ruby's erb language tags -and are used to generate a text file using pre-defined text -and some variables from the manifest. - -These template files are located inside the **templates** folder -of the module and usually have the *erb* extension. -When a template function is called -with the template name and module name prefix, -Fuel tries to load this template and compile it -using variables from the local scope of the class function -from which the template was called. -For example, the following template saved in -the templates folder as *server.conf.erb file* -is a setting to bind the port of our service:: - - bind_port = <%= @port %> - -The template function will replace the 'port' tag -with the value of the port variable from our class -during Puppet's catalog compilation. - -If the service needs several virtual hosts, -you need to define **definitions**, -which are similar to classes but, unlike classes, -they have titles like resources do -and can be used many times with different titles -to produce many instances of the managed resources. -Classes cannot be declared several times with different parameters. - -Definitions are placed in single files inside the manifests directories -just as classes are -and are named in a similar way, using the namespace hierarchy. -Let's create our vhost definition.:: - - define example::server::vhost ( - $path = '/var/data', - ) { - include example::params - - $config = “/etc/example.d/${title}.conf” - $service = $example::params::service - - file { $config : - ensure => present, - owner => 'example', - group => 'example', - mode => '0644', - content => template('example/vhost.conf.erb'), - } - - File[$config] ~> Service[$service] - } - -This defined type only creates a file resource -with its name populated by the title -that is used when it gets defined. -It sets the notification relationship with the service -to make it restart when the vhost file is changed. - -This defined type can be used by other classes -like a simple resource type to create as many vhost files as we need.:: - - example::server::vhost { 'mydata' : - path => '/path/to/my/data', - } - -Defined types can form relationships in the same way as resources do -but you need to capitalize all elements of the path to make the reference:: - - File['/path/to/my/data'] -> Example::Server::Vhost['mydata'] - -This is works for text files but binary files must be handled differently. -Binary files or text files that will always be same -can be placed into the **files** directory of the module -and then be taken by the file resource. - -To illustrate this, let's add a file resource for a file -that contains some binary data that must be distributed -in our client package. -The file resource is the *example::client* class:: - - file { 'example_data' : - path => '/var/lib/example.data', - owner => 'example', - group => 'example', - mode => '0644', - source => 'puppet:///modules/example/client.data', - } - -We have specified source as a special puppet URL scheme -with the module's and the file's name. -This file will be placed in the specified location when Puppet runs. -On each run, Puppet will check this file's checksum, -overwriting it if the checksum changes; -note that this method should not be used with mutable data. -Puppet's fileserving works in both client-server and masterless modes. - -We now have all classes and resources that are required -to manage our hypothetical example service. -Our example class defined inside *init.pp* is still empty -so we can use it to declare all other classes -to put everything together:: - - class example { - include example::params - include example::client - - class { 'example::server::service' : - port => '100', - } - - example::server::vhost { 'site1' : - path => '/data/site1', - } - - example::server::vhost { 'site2' : - path => '/data/site2', - } - - example::server::vhost { 'test' : - path => '/data/test', - } - - } - -Now we have entire module packed inside *example* class and we can just -include this class to any node where we want to see our service running. -Declaration of parametrized class also did override default port number from -params file and we have three separate virtual hosts for out service. Client -package is also included into this class. - -Adding Python code to fuel-library -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -All Python code that is added to fuel-library must pass style checks and have -tests written. - -Whole test suite is run by `python_run_tests.sh `_. -It uses a virtualenv in which all Python modules from -`python-tests-requirements.txt `_ -are installed. If tests need any third-party library, it should be added as a requirement into this file. - -Before starting any test for Python code, test suite runs style checks for any Python code -found in fuel-library. Those checks are performed by `flake8` (for more information, see the -`flake8 documentation `_) -with additional `hacking` checks installed. Those checks are a set of guidelines for Python code. -More information about those guidelines could be found in `hacking documentation `_ - -If, for some reason, you need to disable style checks in the given file you can add the following -line at the beginning of the file::: - - # flake8: noqa - -After style checks, test suite will execute Python tests by using `py.test `_ test runner. -`py.test` will look for Python files whose names begin with 'test\_' and will search for the tests in them. -Documentation on how to write tests could be found in -`the official Python documentation `_ and -`py.test documentation `_. - diff --git a/devdocs/develop/nailgun.rst b/devdocs/develop/nailgun.rst deleted file mode 100644 index 6f1ec4f8d..000000000 --- a/devdocs/develop/nailgun.rst +++ /dev/null @@ -1,7 +0,0 @@ -.. _nailgun: - -Nailgun -======= - -.. toctree:: - nailgun/tree \ No newline at end of file diff --git a/devdocs/develop/nailgun/customization/bonding_in_ui.rst b/devdocs/develop/nailgun/customization/bonding_in_ui.rst deleted file mode 100644 index 56ae8c0b4..000000000 --- a/devdocs/develop/nailgun/customization/bonding_in_ui.rst +++ /dev/null @@ -1,139 +0,0 @@ -Bonding in UI/Nailgun -===================== - -Abstract --------- - -The NIC bonding allows you to aggregate multiple physical links to one link -to increase speed and provide fault tolerance. - -Design docs ------------ - -https://etherpad.openstack.org/p/fuel-bonding-design - -Fuel Support ------------- - -The Puppet module L23network has support for OVS and native Linux bonding, -so we can use it for both NovaNetwork and Neutron deployments. Only Native -OVS bonding (Neutron only) is implemented in Nailgun now. Vlan splinters cannot -be used on bonds now. Three modes are supported now: 'active-backup', -'balance-slb', 'lacp-balance-tcp' (see nailgun.consts.OVS_BOND_MODES). - -Deployment serialization ------------------------- - -For details on deployment serialization for neutron, see: https://etherpad.openstack.org/p/neutron-orchestrator-serialization - -Changes related to bonding are in the “transformations” section: - -1. "add-bond" section -:: - - { - "action": "add-bond", - "name": "bond-xxx", # name is generated in UI - "interfaces": [], # list of NICs; ex: ["eth1", "eth2"] - "bridge": "br-xxx", - "properties": [] # info on bond's policy, mode; ex: ["bond_mode=active-backup"] - } - -2. Instead of creating separate OVS bridges for every bonded NIC we need to create one bridge for the bond itself -:: - - { - "action": "add-br", - "name": "br-xxx" - } - -REST API --------- - -NodeNICsHandler and NodeCollectionNICsHandler are used for bonds creation, -update and removal. Operations with bonds and networks assignment are done in -single request fashion. It means that creation of bond and appropriate networks -reassignment is done using one request. Request parameters must contain -sufficient and consistent data for construction of new interfaces topology and -proper assignment of all node's networks. - -Request/response data example:: - - [ - { - "name": "ovs-bond0", # only name is set for bond, not id - "type": "bond", - "mode": "balance-slb", # see nailgun.consts.OVS_BOND_MODES for modes list - "slaves": [ - {"name": "eth1"}, # only “name” must be in slaves list - {"name": "eth2"}], - "assigned_networks": [ - { - "id": 9, - "name": "public" - } - ] - }, - { - "name": "eth0", - "state": "up", - "mac": "52:54:00:78:55:68", - "max_speed": null, - "current_speed": null, - "assigned_networks": [ - { - "id": 1, - "name": "fuelweb_admin" - }, - { - "id": 10, - "name": "management" - }, - { - "id": 11, - "name": "storage" - } - ], - "type": "ether", - "id": 5 - }, - { - "name": "eth1", - "state": "up", - "mac": "52:54:00:88:c8:78", - "max_speed": null, - "current_speed": null, - "assigned_networks": [], # empty for bond slave interfaces - "type": "ether", - "id": 2 - }, - { - "name": "eth2", - "state": "up", - "mac": "52:54:00:03:d1:d2", - "max_speed": null, - "current_speed": null, - "assigned_networks": [], # empty for bond slave interfaces - "type": "ether", - "id": 1 - } - ] - -Following fields are required in request body for bond interface: -name, type, mode, slaves. -Following fields are required in request body for NIC: -id, type. - -Nailgun DB ----------- - -Now we have separate models for bond interfaces and NICs: NodeBondInterface and -NodeNICInterface. Node's interfaces can be accessed through Node.nic_interfaces -and Node.bond_interfaces separately or through Node.interfaces (property, -read-only) all together. -Relationship between them (bond:NIC ~ 1:M) is expressed in “slaves” field in -NodeBondInterface model. -Two more new fields in NodeBondInterface are: “flags” and “mode”. -Bond's “mode” can accept values from nailgun.consts.OVS_BOND_MODES. -Bond's “flags” are not in use now. “type” property (read-only) indicates whether -it is a bond or NIC (see nailgun.consts.NETWORK_INTERFACE_TYPES). diff --git a/devdocs/develop/nailgun/customization/extensions.rst b/devdocs/develop/nailgun/customization/extensions.rst deleted file mode 100644 index 8f46c2abb..000000000 --- a/devdocs/develop/nailgun/customization/extensions.rst +++ /dev/null @@ -1,327 +0,0 @@ -Nailgun Extensions -__________________ - - -Overview of extensions -====================== - -Nailgun extensions provide a capability for Fuel Developers to extend Fuel -features. Extensions were introduced to provide *pythonic way* for adding -integrations with external services, extending existing features, or adding -new features **without** changing the Nailgun source code. - -A Nailgun extension can execute its method on specific events -such as ``on_node_create`` or ``on_cluster_delete`` (more about event handlers -in the `Available Events`_ section) and also to change deployment and -provisioning data just before it is sent to orchestrator by the means of -Data Pipelines classes. - -.. note:: - The extensions mechanism does not provide a sufficient level - of isolation. Therefore, the extension may not work after you upgrade Fuel. - - On the contrary, Fuel plugins provide backward compatibility and a friendly - UI for the end user. Use plugins for all changes in the system performed - by the Fuel user. - - -Required properties -=================== - -All Nailgun extensions must populate the following class variables: - -* ``name`` - a string which will be used inside Nailgun to identify the - extension. It should consist only of lowercase letters with "_" (underscore) - separator and digits. - -* ``version`` - a string with version. It should follow semantic versioning: - http://semver.org/ - -* ``description`` - a short text which briefly describes the actions that the - extension performs. - - -Available events -================ - -Extension can execute event handlers on specific events. There is -a list of available handlers: - -.. list-table:: - :widths: 10 10 - :header-rows: 1 - - * - Method - - Event - * - ``on_node_create`` - - Node has been created - * - ``on_node_update`` - - Node has been updated - * - ``on_node_reset`` - - Node has been reseted - * - ``on_node_delete`` - - Node has been deleted - * - ``on_node_collection_delete`` - - Collection of nodes has been deleted - * - ``on_cluster_delete`` - - Cluster has been deleted - * - ``on_before_deployment_check`` - - Called right before running "before deployment check task" - - -REST API handlers -================= -Nailgun Extensions also provide a way to add additional API endpoints. -To add an extension-specific handler sub-class from:: - - nailgun.api.v1.handlers.base.BaseHandler - -The second step is to register the handler by providing the ``urls`` list in -Extension class: - -.. code-block:: python - - urls = [ - {'uri': r'/example_extension/(?P\d+)/?$', - 'handler': ExampleNodeHandler}, - {'uri': r'/example_extension/(?P\d+)/properties/', - 'handler': NodeDefaultsDisksHandler}, - ] - - -As you can see you need to provide a list of dicts with keys: - -.. list-table:: - :widths: 10 10 - :header-rows: 1 - - * - key - - value - * - ``uri`` - - a regular expression (string) for the URL path - * - ``handler`` - - handler class - - -Database interaction -==================== - -There is a possibility to use the Nailgun database to store the data needed by -a Nailgun extension. To use it you must provide alembic migration scripts which -should be placed in:: - - extension_module/alembic_migrations/migrations/ - -Where ``extension_module`` is the one where the file with your extension class -is placed. - -You can also change this directory by overriding the classmethod:: - - alembic_migrations_path - -It should return an absolute path (string) to alembic migrations -directory. - -Additionally, use a table name with an extension-specific prefix in models -classes and alembic migration scripts. We recommend that you use the -``table_prefix`` extension method to retrieve the prefix (string). - -.. note:: - Do not use the direct db calls to Nailgun core tables in the extension - class. Use the ``nailgun.objects`` module which ensures compatibility - between the Nailgun DB and the configuration implemented in your extension. - - There **must be no** relations between extension models and core models. - - -Extension Data Pipelines -======================== - -If you want to change the deployment or provisioning data just before it is -sent to an orchestrator use Extension Data Pipelines. - -Data Pipeline is a class which inherits from:: - - nailgun.extensions.BasePipeline - -BasePipeline provides two methods which you can override: - -* ``process_provisioning`` - -* ``process_deployment`` - -Both methods take the following parameters: - -* ``data`` - serialized data which will be sent to orchestrator. Data - **does not include** nodes data which was defined by User in - ``replaced_deployment_info`` or in ``replaced_provisioning_info``. - -* ``cluster`` - a cluster instance for which the data was serialized. - -* ``nodes`` - nodes instances for which the data was serialized. Nodes list - **does not include** node instances which were filtered out in ``data`` - parameter. - -* ``**kwargs`` - additional kwargs - must be in method definition to provide - backwards-compatibility for future (small) changes in extensions API. - -Both methods must return the ``data`` dict so it can be processed by other -pipelines. - -To enable pipelines, add the ``data_pipelines`` variable in your extensions -class: - -.. code-block:: python - - class ExamplePipelineOne(BasePipeline): - - @classmethod - def process_provisioning(cls, data, cluster, nodes, **kwargs): - data['new_field'] = 'example_value' - return data - - @classmethod - def process_deployment(cls, data, cluster, nodes, **kwargs): - data['new_field'] = 'example_value' - return data - - - class ExamplePipelineTwo(BasePipeline): - - @classmethod - def process_deployment(cls, data, cluster, nodes, **kwargs): - data['new_field2'] = 'example_value2' - return data - - - class ExampleExtension(BaseExtension): - ... - data_pipelines = [ - ExamplePipelineOne, - ExamplePipelineTwo, - ] - ... - - -Pipeline classes will be executed **in the order they are defined** in the -``data_pipelines`` variable. - -How to install and plug in extensions -===================================== - -To use extensions system in Nailgun, implement an extension class which will -be the subclass of:: - - nailgun.extensions.BaseExtension - -The class must be placed in a separate module which defines ``entry_points`` in -its ``setup.py`` file. - -Extension entry point should use Nailgun extensions namespace which is:: - - nailgun.extensions - -Example ``setup.py`` file with ``ExampleExtension`` may look like this: - -.. code-block:: python - - from setuptools import setup, find_packages - - setup( - name='example_package', - version='1.0', - description='Demonstration package for Nailgun Extensions', - author='Fuel Nailgman', - author_email='fuel@nailgman.com', - url='http://example.com', - classifiers=['Development Status :: 3 - Alpha', - 'License :: OSI Approved :: Apache Software License', - 'Programming Language :: Python', - 'Programming Language :: Python :: 2', - 'Environment :: Console', - ], - packages=find_packages(), - entry_points={ - 'nailgun.extensions': [ - 'ExampleExtension = example_package.nailgun_extensions.ExampleExtension', - ], - }, - ) - - -Now to enable the extension it is enough to run:: - - python setup.py install - -or:: - - pip install . - -Now extension will be discovered by Nailgun automatically after restart. - - -Example Extension with Pipeline - additional logging -==================================================== - -.. code-block:: python - - import datetime - import logging - - from nailgun.extensions import BaseExtension - from nailgun.extensions import BasePipeline - - logger = logging.getLogger(__name__) - - - class TimeStartedPipeline(BasePipeline): - - @classmethod - def process_provisioning(cls, data, cluster, nodes, **kwargs): - now = datetime.datetime.now() - data['time_started'] = 'provisioning started at {}'.format(now) - return data - - @classmethod - def process_deployment(cls, data, cluster, nodes, **kwargs): - now = datetime.datetime.now() - data['time_started'] = 'deployment started at {}'.format(now) - return data - - - class ExampleExtension(BaseExtension): - name = 'additional_logger' - version = '1.0.0' - description = 'Additional Logging Extension ' - - data_pipelines = [ - TimeStartedPipeline, - ] - - @classmethod - def on_node_create(cls, node): - logging.debug('Node %s has been created', node.id) - - @classmethod - def on_node_update(cls, node): - logging.debug('Node %s has been updated', node.id) - - @classmethod - def on_node_reset(cls, node): - logging.debug('Node %s has been reseted', node.id) - - @classmethod - def on_node_delete(cls, node): - logging.debug('Node %s has been deleted', node.id) - - @classmethod - def on_node_collection_delete(cls, node_ids): - logging.debug('Nodes %s have been deleted', ', '.join(node_ids)) - - @classmethod - def on_cluster_delete(cls, cluster): - logging.debug('Cluster %s has been deleted', cluster.id) - - @classmethod - def on_before_deployment_check(cls, cluster): - logging.debug('Cluster %s will be deployed soon', cluster.id) diff --git a/devdocs/develop/nailgun/customization/partitions.rst b/devdocs/develop/nailgun/customization/partitions.rst deleted file mode 100644 index d3bfc1489..000000000 --- a/devdocs/develop/nailgun/customization/partitions.rst +++ /dev/null @@ -1,179 +0,0 @@ -.. _dev-create-partition: - -Creating Partitions on Nodes -============================ - -Fuel generates Anaconda Kickstart scripts for Red Hat based systems and -preseed files for Ubuntu to partition block devices on new nodes. Most -of the work is done in the pmanager.py_ Cobbler script using the data -from the "ks_spaces" variable generated by the Nailgun VolumeManager_ -class based on the volumes metadata defined in the openstack.yaml_ -release fixture. - -.. _pmanager.py: https://github.com/openstack/fuel-library/blob/master/deployment/puppet/cobbler/templates/scripts/pmanager.py -.. _VolumeManager: https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/extensions/volume_manager/manager.py -.. _openstack.yaml: https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml - -Volumes are created following best practices for OpenStack and other -components. Following volume types are supported: - -vg - an LVM volume group that can contain one or more volumes with type set - to "lv" - -partition - plain non-LVM partition - -raid - a Linux software RAID-1 array of LVM volumes - -Typical slave node will always have an "os" volume group and one or more -volumes of other types, depending on the roles assigned to that node and -the role-to-volumes mapping defined in the "volumes_roles_mapping" -section of openstack.yaml. - -There are a few different ways to add another volume to a slave node: - -#. Add a new logical volume definition to one of the existing LVM volume - groups. -#. Create a new volume group containing your new logical volumes. -#. Create a new plain partition. - -Adding an LV to an Existing Volume Group ----------------------------------------- - -If you need to add a new volume to an existing volume group, for example -"os", your volume definition in openstack.yaml might look like this:: - - - id: "os" - type: "vg" - min_size: {generator: "calc_min_os_size"} - label: "Base System" - volumes: - - mount: "/" - type: "lv" - name: "root" - size: {generator: "calc_total_root_vg"} - file_system: "ext4" - - mount: "swap" - type: "lv" - name: "swap" - size: {generator: "calc_swap_size"} - file_system: "swap" - - mount: "/mnt/some/path" - type: "lv" - name: "LOGICAL_VOLUME_NAME" - size: - generator: "calc_LOGICAL_VOLUME_size" - generator_args: ["arg1", "arg2"] - file_system: "ext4" - -Make sure that your logical volume name ("LOGICAL_VOLUME_NAME" in the -example above) is not the same as the volume group name ("os"), and -refer to current version of openstack.yaml_ for up-to-date format. - -Adding Generators to Nailgun VolumeManager ------------------------------------------- - -The "size" field in a volume definition can be defined either directly -as an integer number in megabytes, or indirectly via a so called -generator. Generator is a Python lambda that can be called to calculate -logical volume size dynamically. In the json example above size is -defined as a dictionary with two keys: "generator" is the name of the -generator lambda and "generator_args" is the list of arguments that will -be passed to the generator lambda. - -There is the method in the VolumeManager class where generators are -defined. New volume generator 'NEW_GENERATOR_TO_CALCULATE_SIZ' needs to -be added in the generators dictionary inside this method. - -.. code-block:: python - - class VolumeManager(object): - ... - def call_generator(self, generator, *args): - generators = { - ... - 'NEW_GENERATOR_TO_CALCULATE_SIZE': lambda: 1000, - ... - } - - -Creating a New Volume Group ---------------------------- - -Another way to add new volume to slave nodes is to create new volume -group and to define one or more logical volume inside the volume group -definition:: - - - - id: "NEW_VOLUME_GROUP_NAME" - type: "vg" - min_size: {generator: "calc_NEW_VOLUME_NAME_size"} - label: "Label for NEW VOLUME GROUP as it will be shown on UI" - volumes: - - mount: "/path/to/mount/point" - type: "lv" - name: "LOGICAL_VOLUME_NAME" - size: - generator: "another_generator_to_calc_LOGICAL_VOLUME_size" - generator_args: ["arg"] - file_system: "xfs" - -Creating a New Plain Partition ------------------------------- - -Some node roles may be incompatible with LVM and would require plain -partitions. If that's the case, you may have to define a standalone -volume with type "partition" instead of "vg":: - - - id: "NEW_PARTITION_NAME" - type: "partition" - min_size: {generator: "calc_NEW_PARTITION_NAME_size"} - label: "Label for NEW PARTITION as it will be shown on UI" - mount: "none" - disk_label: "LABEL" - file_system: "xfs" - -Note how you can set mount point to "none" and define a disk label to -identify the partition instead. Its only possible to set a disk label on -a formatted portition, so you have to set "file_system" parameter to use -disk labels. - -Updating the Node Role to Volumes Mapping ------------------------------------------ - -Unlike a new logical volume added to a pre-existing logical volume -group, a new logical volume group or partition will not be allocated on -the node unless it is included in the role-to-volumes mapping -corresponding to one of the node's roles, like this:: - - volumes_roles_mapping: - controller: - - {allocate_size: "min", id: "os"} - - {allocate_size: "all", id: "image"} - compute: - ... - -* *controller* - is a role for which partitioning information is given -* *id* - is id of volume group or plain partition -* *allocate_size* - can be "min" or "all" - * *min* - allocate volume with minimal size - * *all* - allocate all free space for - volume, if several volumes have this key - then free space will be allocated equally - -Setting Volume Parameters from Nailgun Settings ------------------------------------------------ - -In addition to VolumeManager generators, it is also possible to define -sizes or whatever you want in the nailgun configuration file -(/etc/nailgun/settings.yaml). All fixture files are templated using -Jinja2 templating engine just before being loaded into nailgun database. -For example, we can define mount point for a new volume as follows:: - - "mount": "{{settings.NEW_LOGICAL_VOLUME_MOUNT_POINT}}" - -Of course, *NEW_LOGICAL_VOLUME_MOUNT_POINT* must be defined in the -settings file. - diff --git a/devdocs/develop/nailgun/customization/reliability.rst b/devdocs/develop/nailgun/customization/reliability.rst deleted file mode 100644 index 67fceea66..000000000 --- a/devdocs/develop/nailgun/customization/reliability.rst +++ /dev/null @@ -1,66 +0,0 @@ -Nailgun is the core of FuelWeb. -To allow an enterprise features be easily connected, -and open source commity to extend it as well, Nailgun must -have simple, very well defined and documented core, -with the great pluggable capabilities. - -Reliability -___________ - -All software contains bugs and may fail, and Nailgun is not an exception of this rule. -In reality, it is not possible to cover all failure scenarios, -even to come close to 100%. -The question is how we can design the system to avoid bugs in one module causing the damage -of the whole system. - -Example from the Nailgun's past: -Agent collected hardware information, include current_speed param on the interfaces. -One of the interfaces had current_speed=0. At the registration attempt, Nailgun's validator -checked that current_speed > 0, and validator raised an exception InvalidData, -which declined node discovery. -current_speed is one of the attibutes which we can easily skip, it is not even -used for deployment in any way at the moment and used only for the information provided to the user. -But it prevented node discovery, and it made the server unusable. - -Another example. Due to the coincedence of bug and wrong metadata of one of the nodes, -GET request on that node would return 500 Internal Server Error. -Looks like it should affect the only one node, and logically we could remove such -failing node from the environment to get it discovered again. -However, UI + API handlers were written in the following way: - -* UI calls /api/nodes to fetch info about all nodes to just show how many nodes are allocated, and how many are not - -* NodesCollectionHandler would return 500 if any of nodes raise an exception - -It is simple to guess, that the whole UI was completely destroyed by just one -failed node. It was impossible to do any action on UI. - -These two examples give us the starting point to rethink on how to avoid -Nailgun crash just if one of the meta attr is wrong. - -First, we must divide the meta attributes discovered by agent on two categories: - -* absolutely required for node discovering (i.e. MAC address) - -* non-required for discovering - - * required for deployment (i.e. disks) - - * non-required for deployment (i.e. current_speed) - -Second, we must have UI refactored to fetch only the information required, -not the whole DB to just show two numbers. To be more specific, -we have to make sure that issues in one environment must not -affect the other environment. Such a refactoring will require additional -handlers in Nailgun, as well as some additions, such as pagination and etc. -From Nailgun side, it is bad idea to fail the whole CollectionHandler if one -of the objects fail to calculate some attribute. My(mihgen) idea is to simply set -attribute to Null if failed to calculate, and program UI to handle it properly. -Unit tests must help in testing of this. - -Another idea is to limit the /api/nodes, -/api/networks and other calls -to work only if cluster_id param provided, whether set to None or some of cluster Ids. -In such a way we can be sure that one env will not be able to break the whole UI. - - diff --git a/devdocs/develop/nailgun/customization/roles.rst b/devdocs/develop/nailgun/customization/roles.rst deleted file mode 100644 index a22043f49..000000000 --- a/devdocs/develop/nailgun/customization/roles.rst +++ /dev/null @@ -1,121 +0,0 @@ -Creating roles -============== - -Each release has its own role list which can be customized. A plain list of -roles is stored in the "roles" section of each release in the openstack.yaml_:: - - roles: - - controller - - compute - - cinder - -The order in which the roles are listed here determines the order in which -they are displayed on the UI. - -For each role in this list there should also be entry in "roles_metadata" -section. It defines role name, description and conflicts with other roles:: - - roles_metadata: - controller: - name: "Controller" - description: "..." - conflicts: - - compute - compute: - name: "Compute" - description: "..." - conflicts: - - controller - cinder: - name: "Storage - Cinder LVM" - description: "..." - -"conflicts" section should contain a list of other roles that cannot be placed -on the same node. In this example, "controller" and "compute" roles cannot be -combined. - -Roles restrictions ------------------- - -You should take the following restrictions for the role into consideration: - -#. Controller - - * There should be at least one controller. The `Not enough deployed - controllers` error occurs when you have 1 Controller installed - and want to redeploy that controller. During redeployment, it will - be taken off, so for some time the cluster will not have any - operating controller, which is wrong. - - * If we are using simple multinode mode, then we cannot add more - than one controller. - - * In HA mode, we can add as much as possible controllers, though - it is recommended to add at least 3. - - * Controller role cannot be combined with compute. - - -#. Compute - - * It is recommended to have at least one compute in non-vCenter env - (https://bugs.launchpad.net/fuel/+bug/1381613: note that this is a - bug in UI and not yaml-specific). Beginning - with Fuel 6.1, no vCenter-related limitations are longer present. - - * Computes cannot be combined with controllers. - - * Computes cannot be added if vCenter is chosen as a hypervisor. - -#. Cinder - - * It is impossible to add Cinder nodes to an environment with Ceph RBD. - - * At least one Cinder node is recommended - - * Cinder LVM needs to be enabled on the *Settings* tab of the Fuel web UI. - - -#. MongoDB - - * Cannot be added to already deployed environment. - - * Can be added only if Ceilometer is enabled. - - * Cannot be combined with Ceph OSD and Compute. - - * For a simple mode there has to be 1 Mongo node, for HA at least 3. - - * It is not allowed to choose MongoDB role for a node if external - MongoDB setup is used. - - -#. Zabbix - - * Only available in experimental ISO. - - * Cannot be combined with any other roles. - - * Only one Zabbix node can be assigned in an environment. - - -#. Ceph - - * Cannot be used with Mongo and Zabbix. - - * Minimal number of Ceph nodes is equal to - the `Ceph object replication factor` value from the *Settings* tab - of the Fuel web UI. - - * Ceph cannot be added if vCenter is chosen as a hypervisor - and `volumes_ceph`, `images_ceph` and `ephemeral_ceph` settings - are all False. - - -#. Ceilometer - - * Either a node with MongoDB role or external MongoDB turned on is - required. - - -.. _openstack.yaml: https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml diff --git a/devdocs/develop/nailgun/customization/settings.rst b/devdocs/develop/nailgun/customization/settings.rst deleted file mode 100644 index 0b4ba5723..000000000 --- a/devdocs/develop/nailgun/customization/settings.rst +++ /dev/null @@ -1,186 +0,0 @@ -Extending OpenStack Settings -============================ - -Each release has a list of OpenStack settings that can be customized. -The settings configuration is stored in the ``attributes_metadata.editable`` -release section in the openstack.yaml_ file. - -Settings are divided into groups. Each group should have a ``metadata`` section -with the following attributes:: - - metadata: - toggleable: true - enabled: false - weight: 40 - group: "security" - -* ``toggleable`` defines an ability to enable/disable the whole setting group - on UI (checkbox control is presented near a setting group label). -* ``enabled`` indicates whether the group is checked on the UI. -* ``weight`` defines the order in which this group is displayed on the tab. -* ``restrictions``: see restrictions_. -* ``group`` identifies which subtab on the UI this group of settings will be - displayed on. - -Other sections of a setting group represent separate settings. A setting -structure includes the following attributes:: - - syslog_transport: - value: "tcp" - label: "Syslog transport protocol" - description: "" - weight: 30 - type: "radio" - values: - - data: "udp" - label: "UDP" - description: "" - restrictions: - - "cluster:net_provider != 'neutron'" - - data: "tcp" - label: "TCP" - description: "" - regex: - source: "^[A-z0-9]+$" - error: "Invalid data" - min: 1 - max: 3 - group: "logging" - -* ``label`` is a setting title that is displayed on UI. -* ``weight`` defines the order in which this setting is displayed in its group. - This attribute is desirable. -* ``type`` defines the type of UI control to use for the setting. - The following types are supported: - - * ``text`` - single line input - * ``number`` - number input - * ``password`` - password input - * ``textarea`` - multiline input - * ``checkbox`` - multiple-options selector - * ``radio`` - single-option selector - * ``select`` - drop-down list - * ``hidden`` - invisible input - * ``file`` - file contents input - * ``text_list`` - multiple sigle-line text inputs - * ``textarea_list`` - multiple multi-line text inputs - -* ``regex`` section is applicable for settings of "text" type. ``regex.source`` - is used when validating with a regular expression. ``regex.error`` contains - a warning displayed near invalid field. -* ``restrictions``: see restrictions_. -* ``description`` section should also contain information about setting - restrictions (dependencies, conflicts). -* ``values`` list is needed for settings of "radio" or "select" type to declare - its possible values. Options from ``values`` list also support dependencies - and conflcits declaration. -* ``min`` is used for setting the "number", "text_list" or "textarea_list" type. - For the "number" type, "min" declares the minimum input number value. - For the "text_list" and "textarea_list" types, it declares the minimum list length for the - setting. -* ``max`` is used for setting the "number", "text_list", or "textarea_list" type. - For the "number" type, "max" declares the maximum input number value. - For the "text_list" and "textarea_list" types, it declares the maximum list length for the - setting. -* ``group`` specifies which subtab on the UI settings/networks page this setting will be - displayed on. Inherited from the ``metadata`` section if not provided. - The following values are supported by UI: - - * ``general`` - main cluster settings - * ``security`` - security settings - * ``compute`` - common compute settings - * ``network`` - network settings (are collected on the separate :guilabel:`Networks` tab) - * ``storage`` - storage settings - * ``logging`` - logging settings - * ``openstack_services`` - OpenStack services settings (:guilabel:`Additional Components` - subtab) - * ``other`` - other settings (everything out of the above list) - -.. _restrictions: - -Restrictions ------------- - -Restrictions define when settings and setting groups should be available. -Each restriction is defined as a ``condition`` with optional ``action``, ``message``, -and ``strict``:: - - restrictions: - - condition: "settings:common.libvirt_type.value != 'kvm'" - message: "KVM only is supported" - - condition: "not ('experimental' in version:feature_groups)" - action: hide - -* ``condition`` is an expression written in `Expression DSL`_. If returned value - is true, then ``action`` is performed and ``message`` is shown (if specified). - -* ``action`` defines what to do if ``condition`` is satisfied. Supported values - are ``disable``, ``hide`` and ``none``.``none`` can be used just to display - ``message``. This field is optional (default value is ``disable``). - -* ``message`` is a message that is shown if ``condition`` is satisfied. This field - is optional. - -* ``strict`` is a boolean flag which specifies how to handle non-existent keys - in expressions. If it is set to ``true`` (default value), exception is thrown in - case of non-existent key. Otherwise, values of such keys have a ``null`` value. - Setting this flag to ``false`` is useful for conditions which rely on settings - provided by plugins:: - - restrictions: - - condition: "settings:other_plugin == null or settings:other_plugin.metadata.enabled != true" - strict: false - message: "Other plugin must be installed and enabled" - -There are also short forms of restrictions:: - - restrictions: - - "settings:common.libvirt_type.value != 'kvm'": "KVM only is supported" - - "settings:storage.volumes_ceph.value == true" - -.. _Expression DSL: - -Expression Syntax ------------------ - -Expression DSL can describe arbitrarily complex conditions that compare fields -of models and scalar values. - -Supported types are: - -* Number (123, 5.67) - -* String ("qwe", 'zxc') - -* Boolean (true, false) - -* Null value (null) - -* ModelPath (settings:common.libvirt_type.value, cluster:net_provider) - - ModelPaths consist of a model name and a field name separated by ":". Nested - fields (like in settings) are supported, separated by ".". Models available for - usage are "cluster", "settings", "networking_parameters" and "version". - -Supported operators are: - -* ``==``. Returns true if operands are equal:: - - settings:common.libvirt_type.value == 'qemu' - -* ``!=``. Returns true if operands are not equal:: - - cluster:net_provider != 'neutron' - -* ``in``. Returns true if the right operand (Array or String) contains the left - operand:: - - 'ceph-osd' in release:roles - -* Boolean operators: ``and``, ``or``, ``not``:: - - cluster:mode == "ha_compact" and not (settings:common.libvirt_type.value == 'kvm' or 'experimental' in version:feature_groups) - -* Parentheses can be used to override the order of precedence. - -.. _openstack.yaml: https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml diff --git a/devdocs/develop/nailgun/development/code_testing.rst b/devdocs/develop/nailgun/development/code_testing.rst deleted file mode 100644 index 43ee555b9..000000000 --- a/devdocs/develop/nailgun/development/code_testing.rst +++ /dev/null @@ -1,56 +0,0 @@ -Code testing policy -=================== - -When writing tests, please note the following rules: - -#. Each code change MUST be covered with tests. The test for specific code - change must fail if that change to code is reverted, i.e. the test must - really cover the code change and not the general case. Bug fixes should - have tests for failing case. - -#. The tests MUST be in the same patchset with the code changes. - -#. It's permitted not to write tests in extreme cases. The extreme cases are: - - * hot-fix / bug-fix with *Critical* status. - * patching during Feature Freeze (FF_) or Hard Code Freeze (HCF_). - - In this case, request for writing tests should be reported as a bug with - *technical-debt* tag. It has to be related to the bug which was fixed with - a patchset that didn't have the tests included. - - .. _FF: https://wiki.openstack.org/wiki/FeatureFreeze - .. _HCF: https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze - -#. Before writing tests please consider which type(s) of testing is suitable - for the unit/module you're covering. - -#. Test coverage should not be decreased. - -#. Nailgun application can be sliced up to tree layers (Presentation, Object, - Model). Consider usage of the unit testing if it is performed within one of - the layers or implementing mock objects is not complicated. - -#. The tests have to be isolated. The order and count of executions must not - influence test results. - -#. Tests must be repetitive and must always pass regardless of how many times - they are run. - -#. Parametrize tests to avoid testing many times the same behaviour but with - different data. This gives an additional flexibility in the methods' usage. - -#. Follow DRY principle in tests code. If common code parts are present, please - extract them to a separate method/class. - -#. Unit tests are grouped by namespaces as corresponding unit. For instance, - the unit is located at: ``nailgun/db/dl_detector.py``, corresponding test - would be placed in ``nailgun/test/unit/nailgun.db/test_dl_detector.py`` - -#. Integration tests are grouped at the discretion of the developer. - -#. Consider implementing performance tests for the cases: - - * new handler is added which depends on number of resources in the database. - * new logic is added which parses/operates on elements like nodes. - diff --git a/devdocs/develop/nailgun/development/db_migrations.rst b/devdocs/develop/nailgun/development/db_migrations.rst deleted file mode 100644 index cc435017a..000000000 --- a/devdocs/develop/nailgun/development/db_migrations.rst +++ /dev/null @@ -1,43 +0,0 @@ -Nailgun database migrations -=========================== - -Nailgun uses Alembic (http://alembic.readthedocs.org/en/latest/) for database -migrations, allowing access to all common Alembic commands through "python -manage.py migrate" - -This command creates DB tables for Nailgun service:: - - python manage.py syncdb - -This is done by applying one by one a number of database migration files, -which are located in nailgun/nailgun/db/migration/alembic_migrations/versions. -This command does not create corresponding DB tables unless you created another -migration file or updated an existing one, even if you're making some changes -in SQLAlchemy models or creating the new ones. -A new migration file can be generated by running:: - - python manage.py migrate revision -m "Revision message" --autogenerate - -There are two important points here: - - 1) This command always creates a "diff" between the current database state - and the one described by your SQLAlchemy models, so you should always - run "python manage.py syncdb" before this command. This prevents running - the migrate command with an empty database, which would cause it to - create all tables from scratch. - 2) Some modifications may not be detected by "--autogenerate", which - require manual addition to the migration file. For example, adding a new - value to ENUM field is not detected. - -After creating a migration file, you can upgrade the database to a new state -by using this command:: - - python manage.py migrate upgrade +1 - -To merge your migration with an existing migration file, you can just move -lines of code from the "upgrade()" and "downgrade()" methods to the bottom of corresponding methods in previous migration file. As of this writing, -the migration file is called "current.py". - -For all additional features and needs, you may refer to Alembic documentation: -http://alembic.readthedocs.org/en/latest/tutorial.html - diff --git a/devdocs/develop/nailgun/development/env.rst b/devdocs/develop/nailgun/development/env.rst deleted file mode 100644 index c70199f23..000000000 --- a/devdocs/develop/nailgun/development/env.rst +++ /dev/null @@ -1,256 +0,0 @@ -Setting up Environment -====================== - -For information on how to get source code see :ref:`getting-source`. - -.. _nailgun_dependencies: - -Preparing Development Environment ---------------------------------- - -.. warning:: Nailgun requires Python 2.7. Please check - installed Python version using ``python --version``. - -#. Nailgun can be found in fuel-web/nailgun - -#. Install and configure PostgreSQL database. Please note that - Ubuntu 12.04 requires postgresql-server-dev-9.1 while - Ubuntu 14.04 requires postgresql-server-dev-9.3:: - - sudo apt-get install --yes postgresql postgresql-server-dev-all - - sudo sed -ir 's/peer/trust/' /etc/postgresql/9.*/main/pg_hba.conf - sudo service postgresql restart - - sudo -u postgres psql -c "CREATE ROLE nailgun WITH LOGIN PASSWORD 'nailgun'" - sudo -u postgres createdb nailgun - - If required, you can specify Unix-domain - socket in 'host' settings to connect to PostgreSQL database: - - .. code-block:: yaml - - DATABASE: - engine: "postgresql" - name: "nailgun" - host: "/var/run/postgresql" - port: "" - user: "nailgun" - passwd: "nailgun" - -#. Install pip and development tools:: - - sudo apt-get install --yes python-dev python-pip - -#. Install virtualenv. This step increases flexibility - when dealing with environment settings and package installation:: - - sudo pip install virtualenv virtualenvwrapper - . /usr/local/bin/virtualenvwrapper.sh # you can save this to .bashrc - mkvirtualenv fuel # you can use any name instead of 'fuel' - workon fuel # command selects the particular environment - -#. Install Python dependencies. This section assumes that you use virtual environment. - Otherwise, you must install all packages globally. - You can install pip and use it to require all the other packages at once:: - - sudo apt-get install --yes git - git clone https://github.com/openstack/fuel-web.git - cd fuel-web - pip install -r nailgun/test-requirements.txt - -#. Install Nailgun in the developers mode by running the command below in the - `nailgun` folder. Thanks to that, Nailgun extensions will be discovered:: - - python setup.py develop - - Or if you are using pip:: - - pip install -e . - -#. Create required folder for log files:: - - sudo mkdir /var/log/nailgun - sudo chown -R `whoami`.`whoami` /var/log/nailgun - sudo chmod -R a+w /var/log/nailgun - -Setup for Nailgun Unit Tests ----------------------------- - -#. Nailgun unit tests use `Tox `_ for generating test - environments. This means that you don't need to install all Python packages required - for the project to run them, because Tox does this by itself. - -#. First, create a virtualenv the way it's described in previous section. Then, install - the Tox package:: - - workon fuel #activate virtual environment created in the previous section - pip install tox - -#. Run the Nailgun backend unit tests and flake8 test:: - - sudo apt-get install puppet-common #install missing package required by tasklib tests - ./run_tests.sh - -#. You can also run the same tests by hand, using tox itself:: - - cd nailgun - tox -epy26 -- -vv nailgun/test - tox -epep8 - -#. Tox reuses the previously created environment. After making some changes with package - dependencies, tox should be run with **-r** option to recreate existing virtualenvs:: - - tox -r -epy26 -- -vv nailgun/test - tox -r -epep8 - -Running Nailgun Performance Tests -+++++++++++++++++++++++++++++++++ - -Now you can run performance tests using -x option: - -:: - - ./run_tests.sh -x - - -If -x is not specified, run_tests.sh will not run performance tests. - -The -n or -N option works exactly as before: it states whether -tests should be launched or not. - -For example: - -* run_tests.sh -n -x - run both regular and performance Nailgun tests. - -* run_tests.sh -x - run nailgun performance tests only, do not run - regular Nailgun tests. - -* run_tests.sh -n - run regular Naigun tests only. - -* run_tests.sh -N - run all tests except for Nailgun regular and - performance tests. - - -.. _running-parallel-tests-py: - -Running parallel tests with py.test ------------------------------------ - -Now tests can be run over several processes -in a distributed manner; each test is executed -within an isolated database. - -Prerequisites -+++++++++++++ - -- Nailgun user requires createdb permission. - -- Postgres database is used for initial connection. - -- If createdb cannot be granted for the environment, - then several databases should be created. The number of - databases should be equal to *TEST_WORKERS* variable. - The *createdb* permission - should have the following format: *nailgun0*, *nailgun1*. - -- If no *TEST_WORKERS* variable is provided, then a default - database name will be used. Often it is nailgun, - but you can overwrite it with *TEST_NAILGUN_DB* - environment variable. - -- To execute parallel tests on your local environment, - run the following command from *fuel-web/nailgun*: - - :: - - py.test -n 4 nailgun/test - - - - You can also run the it from *fuel-web*: - - :: - - - py.test -n 4 nailgun/nailgun/test - - - -.. _running-nailgun-in-fake-mode: - -Running Nailgun in Fake Mode ----------------------------- - -#. Switch to virtual environment:: - - workon fuel - -#. Populate the database from fixtures:: - - cd nailgun - ./manage.py syncdb - ./manage.py loaddefault # It loads all basic fixtures listed in settings.yaml - ./manage.py loaddata nailgun/fixtures/sample_environment.json # Loads fake nodes - -#. Start application in "fake" mode, when no real calls to orchestrator - are performed:: - - python manage.py run -p 8000 --fake-tasks | egrep --line-buffered -v '^$|HTTP' >> /var/log/nailgun.log 2>&1 & - -#. (optional) You can also use --fake-tasks-amqp option if you want to - make fake environment use real RabbitMQ instead of fake one:: - - python manage.py run -p 8000 --fake-tasks-amqp | egrep --line-buffered -v '^$|HTTP' >> /var/log/nailgun.log 2>&1 & - -Nailgun in fake mode is usually used for Fuel UI development and Fuel UI -functional tests. For more information, please check out README file in -the fuel-ui repo. - -Note: Diagnostic Snapshot is not available in a Fake mode. - -Running the Fuel System Tests ------------------------------ - -For fuel-devops configuration info please refer to -:doc:`Devops Guide ` article. - -#. Run the integration test:: - - cd fuel-main - make test-integration - -#. To save time, you can execute individual test cases from the - integration test suite like this (nice thing about TestAdminNode - is that it takes you from nothing to a Fuel master with 9 blank nodes - connected to 3 virtual networks):: - - cd fuel-main - export PYTHONPATH=$(pwd) - export ENV_NAME=fuelweb - export PUBLIC_FORWARD=nat - export ISO_PATH=`pwd`/build/iso/fuelweb-centos-6.5-x86_64.iso - ./fuelweb_tests/run_tests.py --group=test_cobbler_alive - -#. The test harness creates a snapshot of all nodes called 'empty' - before starting the tests, and creates a new snapshot if a test - fails. You can revert to a specific snapshot with this command:: - - dos.py revert --snapshot-name - -#. To fully reset your test environment, tell the Devops toolkit to erase it:: - - dos.py list - dos.py erase - - -Flushing database before/after running tests --------------------------------------------- - -The database should be cleaned after running tests; -before parallel tests were enabled, -you could only run dropdb with *./run_tests.sh* script. - -Now you need to run dropdb for each slave node: -the *py.test --cleandb * command is introduced for this -purpose. diff --git a/devdocs/develop/nailgun/development/i18n.rst b/devdocs/develop/nailgun/development/i18n.rst deleted file mode 100644 index bd95c7033..000000000 --- a/devdocs/develop/nailgun/development/i18n.rst +++ /dev/null @@ -1,35 +0,0 @@ -Fuel UI Internationalization Guidelines -======================================= -Fuel UI internationalization is done using `i18next `_ -library. Please read `i18next documentation -`_ first. - -All translations are stored in nailgun/static/translations/core.json - -If you want to add new strings to the translations file, follow these rules: - -#. Use words describing placement of strings like "button", "title", "summary", - "description", "label" and place them at the end of the key - (like "apply_button", "cluster_description", etc.). One-word strings may - look better without any of these suffixes. -#. Do NOT use shortcuts ("bt" instead of "button", "descr" instead of - "description", etc.) -#. Nest keys if it makes sense, for example, if there are a few values - for statuses, etc. -#. If some keys are used in a few places (for example, in utils), move them to - "common.*" namespace. -#. Use defaultValue ONLY with dynamically generated keys. - -Validating translations -========================================= -To search for absent and unnecessary translation keys you can perform the following steps: - -#. Open terminal and cd to fuel-web/nailgun directory. -#. Run "gulp i18n:validate" to start the validation. - If there are any mismatches, you'll see the list of mismatching keys. - -Gulp task "i18n:validate" has one optional argument - a comma-separated list of -languages to compare with base English en-US translations. Run -"gulp i18n:validate --locales=zh-CN" to perform comparison only between English -and Chinese keys. You can also run "grunt i18n:validate --locales=zh-CN,ru-RU" -to perform comparison between English-Chinese and English-Russian keys. diff --git a/devdocs/develop/nailgun/development/shell_doc.rst b/devdocs/develop/nailgun/development/shell_doc.rst deleted file mode 100644 index b18babe86..000000000 --- a/devdocs/develop/nailgun/development/shell_doc.rst +++ /dev/null @@ -1,120 +0,0 @@ -Interacting with Nailgun using Shell -==================================== - -.. contents:: :local: - - -Launching shell ---------------- - -Development shell for Nailgun can only be accessed inside its virtualenv, -which can be activated by launching the following command:: - - source /opt/nailgun/bin/activate - -After that, the shell is accessible through this command:: - - python /opt/nailgun/bin/manage.py shell - -Its appearance depends on availability of ipython on current system. This -package is not available by default on the master node but you can use the -command above to run a default Python shell inside the Nailgun environment:: - - Python 2.7.3 (default, Feb 27 2014, 19:58:35) - [GCC 4.6.3] on linux2 - Type "help", "copyright", "credits" or "license" for more information. - (InteractiveConsole) - >>> - - -.. note:: If you want to quickly access the database, - use *manage.py dbshell* command. - - -Interaction ------------ - -There are two ways user may interact with Nailgun object instances -through shell: - - * Using Nailgun objects abstraction - * Using raw SQLAlchemy queries - -**IMPORTANT NOTE:** Second way (which is equal to straightforward modifying -objects in DB) should only be used if nothing else works. - -.. _shell-objects: - -Objects approach -**************** - -Importing objects may look like this:: - - >>> from nailgun import objects - >>> objects.Release - - >>> objects.Cluster - - >>> objects.Node - - -These are common abstractions around basic items Nailgun is dealing with. - -These objects allow user to interact with items in DB on higher level, which -includes all necessary business logic which is not executed then values in DB -are changed by hands. For working examples continue to :ref:`shell-faq`. - -SQLAlchemy approach -******************* - -Using raw SQLAlchemy models and queries allows user to modify objects through -ORM, almost the same way it can be done through SQL CLI. - -First, you need to get a DB session and import models:: - - >>> from nailgun.db import db - >>> from nailgun.db.sqlalchemy import models - >>> models.Release - - >>> models.Cluster - - >>> models.Node - - -and then get necessary instances from DB, modify them and commit current -transaction:: - - >>> node = db().query(models.Node).get(1) # getting object by ID - >>> node - - >>> node.status = 'error' - >>> db().commit() - -You may refer to `SQLAlchemy documentation `_ -to find some more info on how to do queries. - -.. _shell-faq: - -Frequently Asked Questions --------------------------- - -As a first step in any case objects should be imported as is -described here: :ref:`shell-objects`. - -**Q:** How can I change status for particular node? - -**A:** Just retrieve node by its ID and update it:: - - >>> node = objects.Node.get_by_uid(1) - >>> objects.Node.update(node, {"status": "ready"}) - >>> objects.Node.save(node) - - -**Q:** How can I remove node from cluster by hands? - -**A:** Get node by ID and call its method:: - - >>> node = objects.Node.get_by_uid(1) - >>> objects.Node.remove_from_cluster(node) - >>> objects.Node.save(node) - diff --git a/devdocs/develop/nailgun/development/ui_dependencies.rst b/devdocs/develop/nailgun/development/ui_dependencies.rst deleted file mode 100644 index 07627ae2b..000000000 --- a/devdocs/develop/nailgun/development/ui_dependencies.rst +++ /dev/null @@ -1,41 +0,0 @@ -Managing UI Dependencies -======================== - -The dependencies of Fuel UI are managed by NPM_. - -Used NPM packages are listed in *dependencies* and *devDependencies* sections -of a package.json file. To install all required packages, run:: - - npm install - -To use gulp_ you also need to install the gulp package globally:: - - sudo npm install -g gulp - -To add a new package, it is not enough just to add a new entry to a -package.json file because npm-shrinkwrap_ is used to lock down package -versions. First you need to install the clingwrap package globally: - - sudo npm install -g clingwrap - -Then install required package:: - - npm install --save some-package - -Then run:: - - clingwrap some-package - -to update npm-shrinkwrap.json. - -Alternatively, you can completely regenerate npm-shrinkwrap.json by running:: - - rm npm-shrinkwrap.json - rm -rf node_modules - npm install - npm shrinkwrap --dev - clingwrap npmbegone - -.. _npm: https://www.npmjs.org/ -.. _gulp: http://gulpjs.com/ -.. _npm-shrinkwrap: https://www.npmjs.org/doc/cli/npm-shrinkwrap.html diff --git a/devdocs/develop/nailgun/tree.rst b/devdocs/develop/nailgun/tree.rst deleted file mode 100644 index 5bfc42496..000000000 --- a/devdocs/develop/nailgun/tree.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _nailgun-development: - -Nailgun Development Instructions -================================ - -.. toctree:: - development/env - development/i18n - development/db_migrations - development/shell_doc - development/ui_dependencies - development/code_testing - - -Nailgun Customization Instructions -================================== - -.. _nailgun-customization: - -.. toctree:: - customization/partitions - customization/reliability - customization/roles - customization/settings - customization/bonding_in_ui - customization/extensions diff --git a/devdocs/develop/ostf_contributors_guide.rst b/devdocs/develop/ostf_contributors_guide.rst deleted file mode 100644 index 6f0e2e759..000000000 --- a/devdocs/develop/ostf_contributors_guide.rst +++ /dev/null @@ -1,519 +0,0 @@ -Health Check (OSTF) Contributor's Guide -======================================= - -Health Check or OSTF? -^^^^^^^^^^^^^^^^^^^^^ -Fuel UI has a tab which is called Health Check. In development team though, -there is an established acronym OSTF, which stands for OpenStack Testing Framework. -This is all about the same. For simplicity, this document will use the widely -accepted term OSTF. - -Main goal of OSTF -^^^^^^^^^^^^^^^^^ -After OpenStack installation via Fuel, it`s very important to understand whether it was successful and if it`s ready for work. -OSTF provides a set of health checks - sanity, smoke, HA and additional components tests that check the proper operation of all system components in typical conditions. -There are tests for OpenStack scenarios validation and other specific tests useful in validating an OpenStack deployment. - -Main rules of code contributions -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -There are a few rules you need to follow to successfully pass the code review and contribute high-quality code. - -How to setup my environment? ----------------------------- - -OSTF repository is located at git.openstack.org or GitHub mirror: https://github.com/openstack/fuel-ostf. You also have to install and hook-up gerrit, because otherwise you will not be able to contribute code. To do that you need to follow registration and installation instructions in the document https://wiki.openstack.org/wiki/CLA#Contributors_License_Agreement -After you've completed the instructions, you're all set to begin editing/creating code. - -How should my modules look like? --------------------------------- - -The rules are quite simple: - - follow Python coding rules - - follow OpenStack contributor's rules - - watch out for mistakes in docstrings - - follow correct test structure - - always execute your tests after you wrote them before sending them to review - -Speaking of following Python coding standards, you can find the style guide here: http://www.python.org/dev/peps/pep-0008/. You should read it carefully once and after implementing scripts you need to run some checks that will ensure that your code corresponds the standards. Without correcting issues with coding stadards your scripts will not be merged to master. - -You should always follow the following implementation rules: - - name the test module, test class and test method beginning with the word "test" - - if you have some tests that should be ran in a specific order, add a number to test method name, for example: test_001_create_keypair - - use verify(), verify_response_body_content() and other methods from mixins (see OSTF package architecture fuel_health/common/test_mixins.py section) with giving them failed step parameter - - always list all steps you are checking using test_mixins methods in the docstring in Scenario section in correct order - - always use verify() method when you want to check an operation that can go to an infinite loop - -The test docstrings are another important piece and you should always stick to the following docstring structure: - - test title - test description that will be always shown on UI (the remaining part of docstring will only be shown in cases when test failed) - - target component (optional) - component name that is tested (e.g. Nova, Keystone) - - blank line - - test scenario, example:: - - Scenario: - 1. Create a new small-size volume. - 2. Wait for volume status to become "available". - 3. Check volume has correct name. - 4. Create new instance. - 5. Wait for "Active" status. - 6. Attach volume to an instance. - 7. Check volume status is "in use". - 8. Get information on the created volume by its id. - 9. Detach volume from the instance. - 10. Check volume has "available" status. - 11. Delete volume. - - - test duration - an estimate of how much a test will take - -deployment tags (optional) - gives information about what kind of environment the test will be run, possible values are CENTOS, Ubuntu, RHEL nova_network, Heat, Sahara) - -Here's a test example which confirms the above explanations: - -.. image:: _images/test_docstring_structure.png - -Test run ordering and profiles ------------------------------- - -Each test set (sanity, smoke, HA and platform_tests) contains a special -variable in __init__.py module which is called __profile__. -The profile variable makes it possible to set different rules, such as test run -order, set up deployment tags, information gathering on cleanup and expected -time estimate for running a test set. - -If you are to develop a new set of tests, you need to create __init__.py module -and place __profile__ dict in it. It is important that your profile matches -the following structure:: - - __profile__ = { - "test_runs_ordering_priority": 4, - "id": "platform_tests", - "driver": "nose", - "test_path": "fuel_health/tests/platform_tests", - "description": ("Platform services functional tests." - " Duration 3 min - 60 min"), - "cleanup_path": "fuel_health.cleanup", - "deployment_tags": ['additional_components'], - "exclusive_testsets": [], - "available_since_release": "2015.2-6.1", - } - -Take note of each field in the profile, along with acceptable values. - - - test_runs_ordering_priority is a field responsible for setting the priority - in which the test set will be displayed. For example, if you set "6" for - sanity tests and "3" for smoke tests, smoke test set will be displayed - first on the HealthCheck tab; - - id is just the unique id of a test set; - - driver field is used for setting the test runner; - - test_path is the field representing path where test set is located starting - from fuel_health directory; - - description is the field which contains the value to be shown on the UI - as the tests duration; - - cleanup_path is the field that specifies path to module responsible for - cleanup mechanism (if you do not specify this value, cleanup will not be - started after your test set); - - deployment_tags field is used for defining when these tests should be - available depending on cluster settings; - - exclusive_testsets field gives you an opportunity to specify test sets that - will be run successively. For example, you can specify "smoke_sanity" for - smoke and sanity test set profiles, then these tests will be run not - simultaneously, but successively. - - available_since_release field is responsible for the release version - starting from which a particular test set can be run. This means that - the test will run only on the specified or newer version of Fuel. - -It is necessary to specify a value for each of the attributes. The optional -attribute is "deployment_tags", meaning optionally you may not specify it -in your profile at all. You can leave the "exclusive_testsets" empty ([]) to -run your testset simultaneously with other ones. - - -How to execute my tests? ------------------------- - -Simplest way is to install Fuel, and OSTF will be installed as part of it. - - install virtualbox - - build Fuel ISO: :ref:`building-fuel-iso` - - use `virtualbox scripts to run an ISO `_ - - once the installation is finished, go to Fuel UI (usually it's 10.20.0.2:8000) and create a new cluster with necessary configuration - - execute:: - - rsync -avz / root@10.20.0.2:/opt/fuel_plugins/ostf/lib/python2.6/site-packages/fuel_health/ - - execute:: - - ssh root@10.20.0.2 - service ostf restart - - go to Fuel UI and run your new tests - -Now I'm done, what's next? --------------------------- - - - don't forget to run pep8 on modified part of code - - commit your changes - - execute git review - - ask to review in IRC - -From this part you'll only need to fix and commit review comments (if there are any) by doing the same steps. If there are no review comments left, the reviewers will accept your code and it will be automatically merged to master. - -General OSTF architecture -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Tests are included to Fuel, so they will be accessible as soon as you install Fuel on your lab. OSTF architecture is quite simple, it consists of two main packages: - - fuel_health which contains the test set itself and related modules - - fuel_plugin which contains OSTF-adapter that forms necessary test list in context of cluster deployment options and transfers them to UI using REST_API - -On the other hand, there is some information necessary for test execution itself. There are several modules that gather information and parse them into objects which will be used in the tests themselves. All information is gathered from Nailgun component. - -OSTF REST api interface ------------------------ - -Fuel OSTF module provides not only testing, but also RESTful -interface, a means for interaction with the components. - -In terms of REST, all types of OSTF entities are managed by three HTTP verbs: -GET, POST and PUT. - -The following basic URL is used to make requests to OSTF:: - - {ostf_host}:{ostf_port}/v1/{requested_entity}/{cluster_id} - -Currently, you can get information about testsets, tests and testruns -via GET request on corresponding URLs for ostf_plugin. - -To get information about testsets, make the following GET request on:: - - {ostf_host}:{ostf_port}/v1/testsets/{cluster_id} - -To get information about tests, make GET request on:: - - {ostf_host}:{ostf_port}/v1/tests/{cluster_id} - -To get information about executed tests, make the following GET -requests: - -- for the whole set of testruns:: - - {ostf_host}:{ostf_port}/v1/testruns/ - -- for the particular testrun:: - - {ostf_host}:{ostf_port}/v1/testruns/{testrun_id} - -- for the list of testruns executed on the particular cluster:: - - {ostf_host}:{ostf_port}/v1/testruns/last/{cluster_id} - -To start test execution, make the following POST request on this URL:: - - {ostf_host}:{ostf_port}/v1/testruns/ - -The body must consist of JSON data structure with testsets and the list -of tests belonging to it that must be executed. It should also have -metadata with the information about the cluster -(the key with the "cluster_id" name is used to store the parameter's value):: - - [ - { - "testset": "test_set_name", - "tests": ["module.path.to.test.1", ..., "module.path.to.test.n"], - "metadata": {"cluster_id": id} - }, - - ..., - - {...}, # info for another testrun - {...}, - - ..., - - {...} - ] - -If succeeded, OSTF adapter returns attributes of created testrun entities -in JSON format. If you want to launch only one test, put its id -into the list. To launch all tests, leave the list empty (by default). -Example of the response:: - - [ - { - "status": "running", - "testset": "sanity", - "meta": null, - "ended_at": "2014-12-12 15:31:54.528773", - "started_at": "2014-12-12 15:31:41.481071", - "cluster_id": 1, - "id": 1, - "tests": [.....info on tests.....] - }, - - .... - ] - -You can also stop and restart testruns. To do that, make a PUT request on -testruns. The request body must contain the list of the testruns and -tests to be stopped or restarted. Example:: - - [ - { - "id": test_run_id, - "status": ("stopped" | "restarted"), - "tests": ["module.path.to.test.1", ..., "module.path.to.test.n"] - }, - - ..., - - {...}, # info for another testrun - {...}, - - ..., - - {...} - ] - -If succeeded, OSTF adapter returns attributes of the processed testruns -in JSON format. Its structure is the same as for POST request, described -above. - -OSTF package architecture -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The main modules used in fuel_health package are: - - **config** module is responsible of getting data which is necessary for tests. All data is gathered from Nailgun component or a text config. - Nailgun provides us with the following data: - - OpenStack admin user name - - OpenStack admin user password - - OpenStack admin user tenant - - ip of controllers node - - ip of compute node - easily get data from nailgun by parsing role key in response json - - deployment mode (HA /non-HA) - - deployment os (RHEL/CENTOS) - - keystone / horizon urls - - tiny proxy address - -All other information we need is stored in config.py itself and remains default in this case. In case you are using data from Nailgun (OpenStack installation using Fuel) you should to the following: -initialize NailgunConfig() class. - -Nailgun is running on Fuel master node, so you can easily get data for each cluster by invoking curl http:/localhost:8000/api/. Cluster id can be get from OS environment (provided by Fuel) - -If you want run OSTF for non Fuel installation, change the initialization of NailgunConfig() to FileConfig() and set parameters marked with green color in config - see Appendix 1 (default config file path fuel_health/etc/test.conf) - - **cleanup.py** - invoked by OSTF adapter in case if user stops test execution in Web UI. This module is responsible for deleting all test resources created during test suite run. It simply finds all resources whose name starts with ‘ost1_test-’ and destroys each of them using _delete_it method. - - *Important: if you decide to add additional cleanup for this resource, you have to keep in mind: - All resources depend on each other, that's why deleting a resource that is still in use will give you an exception; - Don't forget that deleting several resources requires an ID for each resource, but not its name. You'll need to specify delete_type optional argument in _delete_it method to ‘id’* - - **nmanager.py** contains base classes for tests. Each base class contains setup, teardown and methods that act as an interlayer between tests and OpenStack python clients (see nmanager architecture diagram). - - .. image:: _images/nmanager.png - - **fuel_health/common/test_mixins.py** - provides mixins to pack response verification into a human-readable message. For assertion failure cases, the method requires a step on which we failed and a descriptive - message to be provided. The verify() method also requires a timeout value to be set. This method should be used when checking OpenStack operations (such as instance creation). Sometimes a cluster - operation taking too long may be a sign of a problem, so this will secure the tests from such a situation or even from going into infinite loop. - - **fuel_health/common/ssh.py** - provides an easy way to ssh to nodes or instances. This module uses the paramiko library and contains some useful wrappers that make some routine tasks for you - (such as ssh key authentication, starting transport threads, etc). Also, it contains a rather useful method exec_command_on_vm(), which makes an ssh to an instance through a controller and then executes - the necessary command on it. - -OSTF Adapter architecture -^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. image:: _images/plugin_structure.png - -The important thing to remember about OSTF Adapter is that just like when writing tests, all code should follow pep8 standard. - -Appendix 1 ----------- - -:: - - IdentityGroup = [ - cfg.StrOpt('catalog_type', - default='identity', may be changes on keystone - help="Catalog type of the Identity service."), - cfg.BoolOpt('disable_ssl_certificate_validation', - default=False, - help="Set to True if using self-signed SSL certificates."), - cfg.StrOpt('uri', - default='http://localhost/' (If you are using FileConfig set here appropriate address) - help="Full URI of the OpenStack Identity API (Keystone), v2"), - cfg.StrOpt('url', - default='http://localhost:5000/v2.0/', (If you are using FileConfig set here appropriate address to horizon) - help="Dashboard Openstack url, v2"), - cfg.StrOpt('uri_v3', - help='Full URI of the OpenStack Identity API (Keystone), v3'), - cfg.StrOpt('strategy', - default='keystone', - help="Which auth method does the environment use? " - "(basic|keystone)"), - cfg.StrOpt('region', - default='RegionOne', - help="The identity region name to use."), - cfg.StrOpt('admin_username', - default='nova' , (If you are using FileConfig set appropriate value here) - help="Administrative Username to use for" - "Keystone API requests."), - cfg.StrOpt('admin_tenant_name', (If you are using FileConfig set appropriate value here) - default='service', - help="Administrative Tenant name to use for Keystone API " - "requests."), - cfg.StrOpt('admin_password', (If you are using FileConfig set appropriate value here) - default='nova', - help="API key to use when authenticating as admin.", - secret=True), - ] - - ComputeGroup = [ - cfg.BoolOpt('allow_tenant_isolation', - default=False, - help="Allows test cases to create/destroy tenants and " - "users. This option enables isolated test cases and " - "better parallel execution, but also requires that " - "OpenStack Identity API admin credentials are known."), - cfg.BoolOpt('allow_tenant_reuse', - default=True, - help="If allow_tenant_isolation is True and a tenant that " - "would be created for a given test already exists (such " - "as from a previously-failed run), re-use that tenant " - "instead of failing because of the conflict. Note that " - "this would result in the tenant being deleted at the " - "end of a subsequent successful run."), - cfg.StrOpt('image_ssh_user', - default="root", (If you are using FileConfig set appropriate value here) - help="User name used to authenticate to an instance."), - cfg.StrOpt('image_alt_ssh_user', - default="root", (If you are using FileConfig set appropriate value here) - help="User name used to authenticate to an instance using " - "the alternate image."), - cfg.BoolOpt('create_image_enabled', - default=True, - help="Does the test environment support snapshots?"), - cfg.IntOpt('build_interval', - default=10, - help="Time in seconds between build status checks."), - cfg.IntOpt('build_timeout', - default=160, - help="Timeout in seconds to wait for an instance to build."), - cfg.BoolOpt('run_ssh', - default=False, - help="Does the test environment support snapshots?"), - cfg.StrOpt('ssh_user', - default='root', (If you are using FileConfig set appropriate value here) - help="User name used to authenticate to an instance."), - cfg.IntOpt('ssh_timeout', - default=50, - help="Timeout in seconds to wait for authentication to " - "succeed."), - cfg.IntOpt('ssh_channel_timeout', - default=20, - help="Timeout in seconds to wait for output from ssh " - "channel."), - cfg.IntOpt('ip_version_for_ssh', - default=4, - help="IP version used for SSH connections."), - cfg.StrOpt('catalog_type', - default='compute', - help="Catalog type of the Compute service."), - cfg.StrOpt('path_to_private_key', - default='/root/.ssh/id_rsa', (If you are using FileConfig set appropriate value here) - help="Path to a private key file for SSH access to remote " - "hosts"), - cfg.ListOpt('controller_nodes', - default=[], (If you are using FileConfig set appropriate value here) - help="IP addresses of controller nodes"), - cfg.ListOpt('compute_nodes', - default=[], (If you are using FileConfig set appropriate value here) - help="IP addresses of compute nodes"), - cfg.StrOpt('controller_node_ssh_user', - default='root', (If you are using FileConfig set appropriate value here) - help="ssh user of one of the controller nodes"), - cfg.StrOpt('controller_node_ssh_password', - default='r00tme', (If you are using FileConfig set appropriate value here) - help="ssh user pass of one of the controller nodes"), - cfg.StrOpt('image_name', - default="TestVM", (If you are using FileConfig set appropriate value here) - help="Valid secondary image reference to be used in tests."), - cfg.StrOpt('deployment_mode', - default="ha", (If you are using FileConfig set appropriate value here) - help="Deployments mode"), - cfg.StrOpt('deployment_os', - default="RHEL", (If you are using FileConfig set appropriate value here) - help="Deployments os"), - cfg.IntOpt('flavor_ref', - default=42, - help="Valid primary flavor to use in tests."), - ] - - - ImageGroup = [ - cfg.StrOpt('api_version', - default='1', - help="Version of the API"), - cfg.StrOpt('catalog_type', - default='image', - help='Catalog type of the Image service.'), - cfg.StrOpt('http_image', - default='http://download.cirros-cloud.net/0.3.1/' - 'cirros-0.3.1-x86_64-uec.tar.gz', - help='http accessable image') - ] - - NetworkGroup = [ - cfg.StrOpt('catalog_type', - default='network', - help='Catalog type of the Network service.'), - cfg.StrOpt('tenant_network_cidr', - default="10.100.0.0/16", - help="The cidr block to allocate tenant networks from"), - cfg.IntOpt('tenant_network_mask_bits', - default=29, - help="The mask bits for tenant networks"), - cfg.BoolOpt('tenant_networks_reachable', - default=True, - help="Whether tenant network connectivity should be " - "evaluated directly"), - cfg.BoolOpt('neutron_available', - default=False, - help="Whether or not neutron is expected to be available"), - ] - - VolumeGroup = [ - cfg.IntOpt('build_interval', - default=10, - help='Time in seconds between volume availability checks.'), - cfg.IntOpt('build_timeout', - default=180, - help='Timeout in seconds to wait for a volume to become' - 'available.'), - cfg.StrOpt('catalog_type', - default='volume', - help="Catalog type of the Volume Service"), - cfg.BoolOpt('cinder_node_exist', - default=True, - help="Allow to run tests if cinder exist"), - cfg.BoolOpt('multi_backend_enabled', - default=False, - help="Runs Cinder multi-backend test (requires 2 backends)"), - cfg.StrOpt('backend1_name', - default='BACKEND_1', - help="Name of the backend1 (must be declared in cinder.conf)"), - cfg.StrOpt('backend2_name', - default='BACKEND_2', - help="Name of the backend2 (must be declared in cinder.conf)"), - ] - - ObjectStoreConfig = [ - cfg.StrOpt('catalog_type', - default='object-store', - help="Catalog type of the Object-Storage service."), - cfg.StrOpt('container_sync_timeout', - default=120, - help="Number of seconds to time on waiting for a container" - "to container synchronization complete."), - cfg.StrOpt('container_sync_interval', - default=5, - help="Number of seconds to wait while looping to check the" - "status of a container to container synchronization"), - ] - - diff --git a/devdocs/develop/puppet_tips.rst b/devdocs/develop/puppet_tips.rst deleted file mode 100644 index 8f1b6f8ce..000000000 --- a/devdocs/develop/puppet_tips.rst +++ /dev/null @@ -1,315 +0,0 @@ -Resource duplication and file conflicts -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If you have been developing your module that somehow uses services which are -already in use by other components of OpenStack, most likely you will try to -declare some of the same resources that have already been declared. -Puppet architecture doesn't allow declaration of resources that have same -type and title even if they do have same attributes. - -For example, your module could be using Apache and has Service['apache'] -declared. When you are running your module outside Fuel nothing else tries to -control this service to and everything work fine. But when you will try to add -this module to Fuel you will get resource duplication error because Apache is -already managed by Horizon module. - -There is pretty much nothing you can do about this problem because uniqueness -of Puppet resources is one on its core principles. But you can try to solve -the problem by one of following ways. - -The best thing you can do is to try to use an already declared resource by -settings dependencies to the other class that does use it. This will not work -in many cases and you may have to modify both modules or move conflicting -resource elsewhere to avoid conflicts. - -Puppet does provide a good solution to this problem - **virtual resources**. -The idea behind it is that you move resource declaration to separate class and -make them virtual. Virtual resources will not be evaluated until you realize -them and you can do it in all modules that do require this resources. -The trouble starts when these resources have different attributes and complex -dependencies. Most current Puppet modules doesn't use virtual resources and -will require major refactoring to add them. - -Puppet style guidelines advise to move all classes related with the same -service inside a single module instead of using many modules to work with -same service to minimize conflicts, but in many cases this approach -doesn't work. - -There are also some hacks such are defining resource inside *if ! -defined(Service['apache']) { ... }* block or using **ensure_resource** -function from Puppet's stdlib. - -Similar problems often arise then working with configuration files. -Even using templates doesn't allow several modules to directly edit same -file. There are a number of solutions to this starting from using -configurations directories and snippets if service supports them to -representing lines or configuration options as resources and managing -them instead of entire files. - -Many services does support configuration directories where you can place -configuration files snippets. Daemon will read them all, concatenate and -use like it was a single file. Such services are the most convenient to -manage with Puppet. You can just separate you configuration and manage -its pieces as templates. If your service doesn't know how to work with -snippets you still can use them. You only need to create parts of your -configuration file in some directory and then just combine them all -using simple exec with *cat* command. There is also a special *concat* -resource type to make this approach easier. - -Some configuration files could have standard structure and can be managed -by custom resource types. For example, there is the *ini_file* resource -type to manage values in compatible configuration as single resources. -There is also *augeas* resource type that can manage many popular -configuration file formats. - -Each approach has its own limitations and editing single file from -many modules is still non-trivial task in most cases. - -Both resource duplication and file editing problems doesn't have a good -solution for every possible case and significantly limit possibility -of code reuse. - -The last approach to solving this problem you can try is to modify files -by scripts and sed patches ran by exec resources. This can have unexpected -results because you can't be sure of what other operations are performed -on this configuration file, what text patterns exist there, and if your -script breaks another exec. - -Puppet module containment -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Fuel Library consists of many modules with a complex structure and -several dependencies defined between the provided modules. -There is a known Puppet problem related to dependencies between -resources contained inside classes declared from other classes. -If you declare resources inside a class or definition they will be -contained inside it and entire container will not be finished until all -of its contents have been evaluated. - -For example, we have two classes with one notify resource each.:: - - class a { - notify { 'a' :} - } - - class b { - notify { 'b' :} - } - - Class['a'] -> Class['b'] - - include a - include b - -Dependencies between classes will force contained resources to be executed in -declared order. -But if we add another layer of containers dependencies between them will not -affect resources declared in first two classes.:: - - class a { - notify { 'a' :} - } - - class b { - notify { 'b' :} - } - - class l1 { - include a - } - - class l2 { - include b - } - - Class['l1'] -> Class['l2'] - - include 'l1' - include 'l2' - -This problem can lead to unexpected and in most cases unwanted behaviour -when some resources 'fall out' from their classes and can break the logic -of the deployment process. - -The most common solution to this issue is **Anchor Pattern**. Anchors are -special 'do-nothing' resources found in Puppetlab's stdlib module. -Anchors can be declared inside top level class and be contained -inside as any normal resource. If two anchors was declared they can be -named as *start* and *end* anchor. All classes, that should be contained -inside the top-level class can have dependencies with both anchors. -If a class should go after the start anchor and before the end anchor -it will be locked between them and will be correctly contained inside -the parent class.:: - - class a { - notify { 'a' :} - } - - class b { - notify { 'b' :} - } - - class l1 { - anchor { 'l1-start' :} - include a - anchor { 'l1-end' :} - - Anchor['l1-start'] -> Class['a'] -> Anchor['l1-end'] - } - - class l2 { - anchor { 'l2-start' :} - include b - anchor { 'l2-end' :} - - Anchor['l2-start'] -> Class['b'] -> Anchor['l2-end'] - } - - Class['l1'] -> Class['l2'] - - include 'l1' - include 'l2' - -This hack does help to prevent resources from randomly floating out of their -places, but look very ugly and is hard to understand. We have to use this -technique in many of Fuel modules which are rather complex and require such -containment. -If your module is going to work with dependency scheme like this, you could -find anchors useful too. - -There is also another solution found in the most recent versions of Puppet. -*Contain* function can force declared class to be locked within its -container.:: - - class l1 { - contain 'a' - } - - class l2 { - contain 'b' - } - -Puppet scope and variables -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The way Puppet looks for values of variables from inside classes can be -confusing too. There are several levels of scope in Puppet. -**Top scope** contains all facts and built-in variables and goes from the -start of *site.pp* file before any class or node declaration. There is also a -**node scope**. It can be different for every node block. Each class and -definition start their own **local scopes** and their variables and resource -defaults are available their. **They can also have parent scopes**. - -Reference to a variable can consist of two parts -**$(class_name)::(variable_name)** for example *$apache::docroot*. Class name -can also be empty and such record will explicitly reference top level scope -for example *$::ipaddress*. - -If you are going to use value of a fact or top-scope variable it's usually a -good idea to add two colons to the start of its name to ensure that you -will get the value you are looking for. - -If you want to reference variable found in another class and use fully -qualified name like this *$apache::docroot*. But you should remember that -referenced class should be already declared. Just having it inside your -modules folder is not enough for it. Using *include apache* before referencing -*$apache::docroot* will help. This technique is commonly used to make -**params** classes inside every module and are included to every other class -that use their values. - -And finally if you reference a local variable you can write just *$myvar*. -Puppet will first look inside local scope of current class of defined type, -then inside parent scope, then node scope and finally top scope. If variable -is found on any of this scopes you get the first match value. - -Definition of what the parent scope is varies between Puppet 2.* and Puppet -3.*. Puppet 2.* thinks about parent scope as a class from where current class -was declared and all of its parents too. If current class was inherited -from another class base class also is parent scope allowing to do popular -*Smart Defaults* trick.:: - - class a { - $var = ‘a’ - } - - class b( - $a = $a::var, - ) inherits a { - - } - -Puppet 3.* thinks about parent scope only as a class from which current class -was inherited if any and doesn't take declaration into account. - -For example:: - - $msg = 'top' - - class a { - $msg = "a" - } - - class a_child inherits a { - notify { $msg :} - } - -Will say 'a' in puppet 2.* and 3.* both. But.:: - - $msg = 'top' - - class n1 { - $msg = 'n1' - include 'n2' - } - - class n2 { - notify { $msg :} - } - - include 'n1' - -Will say 'n1' in puppet 2.6, will say 'n1' and issue *deprecation warning* in -2.7, and will say 'top' in puppet 3.* - -Finding such variable references replacing them with fully qualified names is -very important part Fuel of migration to Puppet 3.* - -Where to find more information -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The best place to start learning Puppet is Puppetlabs' official learning -course (http://docs.puppetlabs.com/learning/). There is also a special virtual -machine image you can use to safely play with Puppet manifests. - -Then you can continue to read Puppet reference and other pages of Puppetlabs -documentation. - -You can also find a number of printed book about Puppet and how to use it to -manage your IT infrastructure. - -Pro Puppet -http://www.apress.com/9781430230571 - -Pro Puppet. 2nd Edition -http://www.apress.com/9781430260400 - -Puppet 2.7 Cookbook -https://www.packtpub.com/networking-and-servers/puppet-27-cookbook - -Puppet 3 Cookbook -https://www.packtpub.com/networking-and-servers/puppet-3-cookbook - -Puppet 3: Beginners Guide -https://www.packtpub.com/networking-and-servers/puppet-3-beginner%E2%80%99s-guide - -Instant Puppet 3 Starter -https://www.packtpub.com/networking-and-servers/instant-puppet-3-starter-instant - -Pulling Strings with Puppet Configuration Management Made Easy -http://www.apress.com/9781590599785 - -Puppet Types and Providers Extending Puppet with Ruby -http://shop.oreilly.com/product/0636920026860.do - -Managing Infrastructure with Puppet. Configuration Management at Scale -http://shop.oreilly.com/product/0636920020875.do diff --git a/devdocs/develop/pxe_deployment.rst b/devdocs/develop/pxe_deployment.rst deleted file mode 100644 index ef3cbb9ce..000000000 --- a/devdocs/develop/pxe_deployment.rst +++ /dev/null @@ -1,304 +0,0 @@ -Fuel Master Node Deployment over PXE -==================================== - -Tech Explanation of the process -------------------------------- -In some cases (such as no installed CD-ROM or no physical access to the -servers) we need to install Fuel Master node somehow other way from CD or USB -Flash drive. Starting from Fuel 4.0 it's possible to deploy Master node with PXE - -The process of deployment of Fuel master node over network consists of booting -linux kernel by DHCP and PXE. Then anaconda installer will download -configuration file and all packages needed to complete the installation. - - * PXE firmware of the network card makes DHCP query and gets IP address and - boot image name. - * Firmware downloads boot image file using TFTP protocol and starts it. - * This bootloader downloads configuration file with kernel boot option, - kernel and initramfs and starts the installer. - * Installer downloads kickstart configuration file by mounting contents of - Fuel ISO file over NFS. - * Installer partitions hard drive, installs the system by downloading packages - over NFS, copies all additional files, installs the bootloader and reboots - into new system. - -So we need: - * Working system to serve as network installer. - * DHCP server - * TFTP server - * NFS server - * PXE bootloader and its configuration file - * Extracted or mounted Fuel ISO file - -In our test we will use 10.20.0.0/24 network. -10.20.0.1/24 will be IP address of our host system. - -Installing packages -------------------- -We will be using Ubuntu or Debian system as an installation server. Other linux -or even BSD-based systems could be used too, but paths to configuration files -and init scripts may differ. - -First we need to install the software:: - - # TFTP server and client - apt-get install tftp-hpa tftpd-hpa - # DHCP server - apt-get install isc-dhcp-server - # network bootloader - apt-get install syslinux syslinux-common - # nfs server - apt-get install nfs-server - -Setting up DHCP server --------------------------- -Standalone ISC DHCPD -~~~~~~~~~~~~~~~~~~~~ -First we are going to create configuration file located at /etc/dhcp/dhcpd.conf:: - - ddns-update-style none; - default-lease-time 600; - max-lease-time 7200; - authoritative; - log-facility local7; - - subnet 10.20.0.0 netmask 255.255.255.0 { - range 10.20.0.2 10.20.0.2; - option routers 10.20.0.1; - option domain-name-servers 10.20.0.1; - } - - host fuel { - hardware ethernet 52:54:00:31:38:5a; - fixed-address 10.20.0.2; - filename "pxelinux.0"; - } - -We have declared a subnet with only one IP address available that we are going -to give to our master node. We are not going to serve entire range of IP -addresses because it will disrupt Fuel’s own DHCP service. There is also a host -definition with a custom configuration that matches a specific MAC address. This -address should be set to the MAC address of the system that you are going to -make Fuel master node. Other systems on this subnet will not receive any IP -addresses and will load bootstrap from master node when it starts serving DHCP -requests. -We also give a filename that will be used to boot the Fuel master node. - - -Using 10.20.0.0/24 subnet requires you to set 10.20.0.1 on the network -interface connected to this network. You may also need to set the interface -manually using the INTERFACES variable in /etc/default/isc-dhcp-server file. - -Start DHCP server:: - - /etc/init.d/isc-dhcp-server restart - -Simple with dnsmasq:: - - sudo dnsmasq -d --enable-tftp --tftp-root=/var/lib/tftpboot \ - --dhcp-range=10.20.0.2,10.20.0.2 \ - --port=0 -z -i eth2 \ - --dhcp-boot='pxelinux.0' - -Libvirt with dnsmasq -~~~~~~~~~~~~~~~~~~~~ -If you are using libvirt virtual network to install your master node, then you -can use its own DHCP service. Use virsh net-edit default to modify network -configuration:: - - - default - - - - - - - - - - - - -This configuration includes TFTP server and DHCP server with only one IP -address set to your master node’s MAC address. You don't need to install -neither external DHCP server nor TFTP server. -Don’t forget to restart the network after making edits:: - - virsh net-destroy default - virsh net-start default - -Dnsmasq without libvirt -~~~~~~~~~~~~~~~~~~~~~~~ -You can also use dnsmasq as a DHCP and TFTP server without libvirt:: - - strict-order - domain-needed - user=libvirt-dnsmasq - local=// - pid-file=/var/run/dnsmasq.pid - except-interface=lo - bind-dynamic - interface=virbr0 - dhcp-range=10.20.0.2,10.20.0.2 - dhcp-no-override - enable-tftp - tftp-root=/var/lib/tftpboot - dhcp-boot=pxelinux.0 - dhcp-leasefile=/var/lib/dnsmasq/leases - dhcp-lease-max=1 - dhcp-hostsfile=/etc/dnsmasq/hostsfile - -In /etc/dnsmasq/hostsfile you can specify hosts and their mac addresses:: - - 52:54:00:31:38:5a,10.20.0.2 - -Dnsmasq provides both DHCP, TFTP, as well as acts as a DNS caching server, so -you don't need to install additional external services. - -Setting our TFTP server ------------------------ -If you are not using a libvirt virtual network, then you need to install tftp -server. On Debian or Ubuntu system its configuration file will be located here -/etc/default/tftpd-hpa. -Checking if all we want are there:: - - TFTP_USERNAME="tftp" - TFTP_DIRECTORY="/var/lib/tftpboot" - TFTP_ADDRESS="10.20.0.1:69" - TFTP_OPTIONS="--secure --blocksize 512" - -Don’t forget to set blocksize here. Some hardware switches have problems with -larger block sizes. -And star it:: - - /etc/init.d/tftpd-hpa restart - -Setting up NFS server ---------------------- -You will also need to setup NFS server on your install system. Edit the NFS -exports file:: - - vim /etc/exports - -Add the following line:: - - /var/lib/tftpboot 10.20.0.2(ro,async,no_subtree_check,no_root_squash,crossmnt) - -And start it:: - - /etc/init.d/nfs-kernel-server restart - - -Set up tftp root ----------------- -Our tftp root will be located here: /var/lib/tftpboot -Let’s create a folder called "fuel" to store ISO image contents and syslinux -folder for bootloader files. If you have installed syslinux package you can find -them in /usr/lib/syslinux folder. -Copy this files from /usr/lib/syslinux to /var/lib/tftpboot:: - - memdisk menu.c32 poweroff.com pxelinux.0 reboot.c32 - -Now we need to write the pxelinux configuration file. It will be located here -/var/lib/tftpboot/pxelinux.cfg/default:: - - DEFAULT menu.c32 - prompt 0 - MENU TITLE My Distro Installer - - TIMEOUT 600 - - LABEL localboot - MENU LABEL ^Local Boot - MENU DEFAULT - LOCALBOOT 0 - - LABEL fuel - MENU LABEL Install ^FUEL - KERNEL /fuel/isolinux/vmlinuz - INITRD /fuel/isolinux/initrd.img - APPEND biosdevname=0 ks=nfs:10.20.0.1:/var/lib/tftpboot/fuel/ks.cfg repo=nfs:10.20.0.1:/var/lib/tftpboot/fuel ip=10.20.0.2 netmask=255.255.255.0 gw=10.20.0.1 dns1=10.20.0.1 hostname=fuel.example.com showmenu=no - - LABEL reboot - MENU LABEL ^Reboot - KERNEL reboot.c32 - - LABEL poweroff - MENU LABEL ^Poweroff - KERNEL poweroff.com - -You can ensure silent installation without any Anaconda prompts by adding the following APPEND directives: - -* ksdevice=INTERFACE -* installdrive=DEVICENAME -* forceformat=yes - -For example: - - installdrive=sda ksdevice=eth0 forceformat=yes - -Now we need to unpack the Fuel ISO file we have downloaded:: - - mkdir -p /var/lib/tftpboot/fuel /mnt/fueliso - mount -o loop /path/to/your/fuel.iso /mnt/fueliso - rsync -a /mnt/fueliso/ /var/lib/tftpboot/fuel/ - umount /mnt/fueliso && rmdir /mnt/fueliso - -So that's it! We can boot over the network from this PXE server. - -Troubleshooting ---------------- - -After implementing one of the described configuration you should see something -like that in your /var/log/syslog file:: - - dnsmasq-dhcp[16886]: DHCP, IP range 10.20.0.2 -- 10.20.0.2, lease time 1h - dnsmasq-tftp[16886]: TFTP root is /var/lib/tftpboot - -To make sure all of daemon listening sockets as they should:: - - # netstat -upln | egrep ':(67|69|2049) ' - udp 0 0 0.0.0.0:67 0.0.0.0:* 30791/dnsmasq - udp 0 0 10.20.0.1:69 0.0.0.0:* 30791/dnsmasq - udp 0 0 0.0.0.0:2049 0.0.0.0:* - - -* NFS - udp/2049 -* DHCP - udp/67 -* TFTP - udp/69 - -So all of daemons listening as they should. - -To test DHCP server does provide an IP address you can do something like that -on the node in the defined PXE network. Please note, it should have Linux -system installed or any other OS to test configuration properly:: - - # dhclient -v eth0 - Internet Systems Consortium DHCP Client 4.1.1-P1 - Copyright 2004-2010 Internet Systems Consortium. - All rights reserved. - For info, please visit https://www.isc.org/software/dhcp/ - - Listening on LPF/eth0/00:25:90:c4:7a:64 - Sending on LPF/eth0/00:25:90:c4:7a:64 - Sending on Socket/fallback - DHCPREQUEST on eth0 to 255.255.255.255 port 67 (xid=0x7b6e25dc) - DHCPACK from 10.20.0.1 (xid=0x7b6e25dc) - bound to 10.20.0.2 -- renewal in 1659 seconds. - -After running dhclient you should see how it asks one or few times DHCP server -with DHCPDISCOVER and then get 10.20.0.2. If you have more than one NIC you -should run dhclient on every one to determine where our network in connected -to. - -TFTP server can be tested with tftp console client:: - - # tftp - (to) 10.20.0.1 - tftp> get /pxelinux.0 - -NFS could be tested with mounting it:: - - mkdir /mnt/nfsroot - mount -t nfs 10.20.0.1:/var/lib/tftpboot /mnt/nfsroot - diff --git a/devdocs/develop/quick_start.rst b/devdocs/develop/quick_start.rst deleted file mode 100644 index be35e7865..000000000 --- a/devdocs/develop/quick_start.rst +++ /dev/null @@ -1,109 +0,0 @@ -Fuel Development Quick-Start -============================ - -If you are interested in contributing to Fuel or modifying Fuel -for your own purposes, this short guide should get you pointed -to all the information you need to get started. - -If you are new to contributing to OpenStack, read -through the “How To Contribute” page on the OpenStack wiki. -See: `How to contribute -`_. - -For this walk-through, let’s use the example of modifying an -option to the “new environment wizard” in Fuel (example here: -`https://review.openstack.org/#/c/90687/1 -`_). This -enhancement required modification to three files in the fuel-web -repository:: - - fuel-web/nailgun/static/translations/core.json - fuel-web/nailgun/static/js/views/dialogs.jsx - fuel-web/nailgun/static/templates/dialogs/create_cluster_wizard/storage.html - -In order to add, test and commit the code necessary to -implement this feature, these steps were followed: - -#. Create a Fuel development environment by following the - instructions found here: - :doc:`Fuel Development Environment `. - -#. In your development environment, prepare your environment - for Nailgun unit tests and Web UI tests by following - the instructions found here: - :doc:`Nailgun Dev Environment `. - Be sure to run the tests noted in each section to ensure - your environment confirms to a known good baseline. - -#. Branch your fuel-web checkout (see `Gerrit Workflow - `_ for - more information on the gerrit workflow):: - - cd fuel-web - git fetch --all;git checkout -b vcenter-wizard-fix origin/master - -#. Modify the necessary files (refer to :doc:`Fuel Architecture - ` to understand how the components - of Fuel work together). - -#. Test your Nailgun changes:: - - cd fuel-web - ./run_tests.sh --no-webui - ./run_tests.sh --flake8 - ./run_tests.sh --webui - -#. You should also test Nailgun in fake UI mode by following - the steps found here: :ref:`running-nailgun-in-fake-mode` - -#. When all tests pass you should commit your code, which - will subject it to further testing via Jenkins and Fuel CI. - Be sure to include a good commit message, guidelines can be - found here: `Git Commit Messages `_.:: - - git commit -a - git review - -#. Frequently, the review process will suggest changes be - made before your code can be merged. In that case, make - your changes locally, test the changes, and then re-submit - for review by following these steps:: - - git commit -a --amend - git review - -#. Now that your code has been committed, you should change - your Fuel ISO makefile to point to your specific commit. - As noted in the :doc:`Fuel Development documentation `, - when you build a Fuel ISO it pulls down the additional - repositories rather than using your local repos. Even - though you have a local clone of fuel-web holding the branch - you just worked on, the build script will be pulling code - from git for the sub-components (Nailgun, Astute, OSTF) - based on the repository and commit specified in environment - variables when calling “make iso”, or as found in config.mk. - You will need to know the gerrit commit ID and patch number. - For this example we are looking at - https://review.openstack.org/#/c/90687/1 - with the gerrit ID 90687, patch 1. In this instance, you - would build the ISO with:: - - cd fuel-main - NAILGUN_GERRIT_COMMIT=refs/changes/32/90687/1 make iso - -#. Once your ISO build is complete, you can test it. If - you have access to hardware that can run the KVM - hypervisor, you can follow the instructions found in the - :doc:`Devops Guide ` to create a robust testing - environment. Otherwise, you can test the ISO with - Virtualbox (https://github.com/openstack/fuel-virtualbox/). - -#. Once your code has been merged, you can return your local - repo to the master branch so you can start fresh on your - next commit by following these steps:: - - cd fuel-web - git remote update - git checkout master - git pull - diff --git a/devdocs/develop/sequence.rst b/devdocs/develop/sequence.rst deleted file mode 100644 index 8b3425b32..000000000 --- a/devdocs/develop/sequence.rst +++ /dev/null @@ -1,41 +0,0 @@ -Sequence Diagrams -================= - -OS Provisioning ---------------- -.. image:: _images/uml/nodes_provisioning.png - :width: 100% - -Networks Verification ---------------------- -.. image:: _images/uml/network_verification.png - :width: 100% - -Details on Cluster Provisioning & Deployment (via Facter extension) -------------------------------------------------------------------- -.. image:: _images/uml/cluster_deployment.png - :width: 100% - -Once deploy and provisioning messages are accepted by Astute, provisioning -method is called. Provisioning part creates system in Cobbler and -calls reboot over Cobbler. Then Astute uses `MCollective direct addressing -mode -`_ -to check if all required nodes are available, include puppet agent on them. If -some nodes are not yet ready, Astute waits for a few seconds and tries to -request again. When nodes are booted in target OS, Astute uses upload_file -MCollective plugin to push data to a special file */etc/astute.yaml* on the -target system. -Data include role and all other variables needed for deployment. Then, Astute -calls puppetd MCollective plugin to start deployment. Puppet is started on -nodes. - -Accordingly, puppet agent starts its run. Modules contain facter extension, -which runs before deployment. Extension reads data from */etc/astute.yaml* -placed by mcollective, and extends Facter data with it as a single fact, which -is then parsed by *parseyaml* function to create *$::fuel_settings* data -structure. This structure contains all variables as a single hash and -supports embedding of other rich structures such as nodes hash or arrays. -Case structure in running class chooses appropriate class to import, -based on *role* and *deployment_mode* variables found in */etc/astute.yaml*. diff --git a/devdocs/develop/system_tests/tree.rst b/devdocs/develop/system_tests/tree.rst deleted file mode 100644 index 293f57e0e..000000000 --- a/devdocs/develop/system_tests/tree.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. _system-tests: - -System Tests -============ - -To include documentation on system tests, **SYSTEM_TESTS_PATH** -environment variable should be set before running *sphinx-build* or -*make*. - diff --git a/devdocs/devops.rst b/devdocs/devops.rst deleted file mode 100644 index c7a2211d7..000000000 --- a/devdocs/devops.rst +++ /dev/null @@ -1,523 +0,0 @@ -DevOps Guide -============ - -Introduction ------------- - -Fuel-Devops is a sublayer between application and target environment (currently -only supported under libvirt). - - -This application is used for testing purposes like grouping virtual machines to -environments, booting KVM VMs locally from the ISO image and over the network -via PXE, creating, snapshotting and resuming back the whole environment in -single action, create virtual machines with multiple NICs, multiple hard drives -and many other customizations with a few lines of code in system tests. - -After 6.0 release, fuel-devops was divided into 2.5.x and 2.9.x versions. Two -separate versions of fuel-devops provide backward compatibility for system -tests which have been refactored since the last major release. Look here -`how to migrate`_ from older devops. - -For sources please refer to -`fuel-devops repository on github `_. - -.. _install system dependencies: - -Installation -------------- - -The installation procedure can be implemented via PyPI in Python virtual -environment (suppose you are using *Ubuntu 12.04* or *Ubuntu 14.04*): - -Before using it, please install the following required dependencies: - -.. code-block:: bash - - sudo apt-get install --yes \ - git \ - libyaml-dev \ - libffi-dev \ - python-dev \ - python-pip \ - qemu \ - libvirt-bin \ - libvirt-dev \ - vlan \ - bridge-utils \ - genisoimage - - sudo apt-get update && sudo apt-get upgrade -y - -.. _DevOpsPyPIvenv: - -Devops installation in `virtualenv `_ -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -#. Install packages needed for building the Python ``eggs``: - - .. code-block:: bash - - sudo apt-get install --yes python-virtualenv libpq-dev libgmp-dev pkg-config - -#. If you use Ubuntu 12.04, update ``pip`` and ``virtualenv``; - otherwise, you can skip this step: - - .. code-block:: bash - - sudo pip install pip virtualenv --upgrade - hash -r - -#. To store the path where your Python virtualenv will be located, - create your working directory and use the following environment variable. - If not specified, it will use the current working directory: - - .. code-block:: bash - - export WORKING_DIR=$HOME/working_dir - mkdir $HOME/working_dir - -#. Create virtualenv for the *devops* project (for example, - ``fuel-devops-venv``). The related directory will be used for the - ``VENV_PATH`` variable: - - .. code-block:: bash - - cd $WORKING_DIR - sudo apt-get install --yes python-virtualenv - virtualenv --no-site-packages fuel-devops-venv - - .. note:: If you want to use different devops versions at the same time, - create several different folders for each version and activate - the required virtual environment for each version. - - For example:: - - virtualenv --no-site-packages fuel-devops-venv # For fuel-devops 2.5.x - virtualenv --no-site-packages fuel-devops-venv-2.9 # For fuel-devops 2.9.x - -#. Activate virtualenv and install ``devops`` package using PyPI. - To identify the latest available versions to install, visit the - `fuel-devops `_ repository. - For Fuel 6.0 and earlier, take the latest ``fuel-devops`` 2.5.x (for - example, ``fuel-devops.git@2.5.6``). For Fuel 6.1 and later, use version - 3.0.x or newer (for example, ``fuel-devops.git@3.0.3``): - - .. code-block:: bash - - . fuel-devops-venv/bin/activate - pip install git+https://github.com/openstack/fuel-devops.git@ --upgrade - - The ``setup.py`` in the ``fuel-devops`` repository installs and configures - the ``devops`` package. - - .. hint:: You can also use `virtualenvwrapper `_ - that manages virtual environments. - -#. Follow the instructions in the :ref:`DevOpsConf` section. - -.. _DevOpsConf: - -Configuration --------------- - -Basically *devops* requires that the following system-wide settings are -configured: - -* Default libvirt storage pool is active (called 'default') -* Current user has a permission to run KVM VMs with libvirt -* PostgreSQL server running with appropriate grants and schema for *devops* -* (Optional) Nested Paging is enabled - -Configuring libvirt pool -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Create libvirt's pool - -.. code-block:: bash - - sudo virsh pool-define-as --type=dir --name=default --target=/var/lib/libvirt/images - sudo virsh pool-autostart default - sudo virsh pool-start default - -Permissions to run KVM VMs with libvirt with current user -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Give current user permissions to use libvirt: do not forget to log out and log -back in. - -.. code-block:: bash - - sudo usermod $(whoami) -a -G libvirtd,sudo - -Configuring database -~~~~~~~~~~~~~~~~~~~~~ - -You can configure PostgreSQL database or as an alternative SQLite. - -Configuring PostgreSQL -+++++++++++++++++++++++ - -Install postgresql package: - -.. code-block:: bash - - sudo apt-get install --yes postgresql - -Set local peers to be trusted by default, create user and db and load fixtures. - -.. code-block:: bash - - pg_version=$(dpkg-query --show --showformat='${version;3}' postgresql) - pg_createcluster $pg_version main --start - sudo sed -ir 's/peer/trust/' /etc/postgresql/9.*/main/pg_hba.conf - sudo service postgresql restart - -* in **2.9.x version**, default and are **fuel_devops** - - .. code-block:: bash - - sudo -u postgres createuser -P fuel_devops - sudo -u postgres psql -c "CREATE ROLE fuel_devops WITH LOGIN PASSWORD 'fuel_devops'" - sudo -u postgres createdb fuel_devops -O fuel_devops - -* in **2.5.x version**, default and are **devops** - - .. code-block:: bash - - sudo -u postgres createuser -P devops - sudo -u postgres psql -c "CREATE ROLE devops WITH LOGIN PASSWORD 'devops'" - sudo -u postgres createdb devops -O devops - -Configuring SQLite3 database -+++++++++++++++++++++++++++++ - -Install SQLite3 library: - -.. code-block:: bash - - sudo apt-get install --yes libsqlite3-0 - -Export the path to the SQLite3 database as the database name: - -.. code-block:: bash - - export DEVOPS_DB_NAME=$WORKING_DIR/fuel-devops - export DEVOPS_DB_ENGINE="django.db.backends.sqlite3 - -Configuring Django -~~~~~~~~~~~~~~~~~~~ - -After the database setup, we can install the django tables and data: - -.. code-block:: bash - - django-admin.py syncdb --settings=devops.settings - django-admin.py migrate devops --settings=devops.settings - -.. note:: Depending on your Linux distribution, - `django-admin `_ may refer - to system-wide django installed from package. If this happens you could get - an exception that says that devops.settings module is not resolvable. - To fix this, run django-admin.py (or django-admin) with a relative path :: - - ./bin/django-admin syncdb --settings=devops.settings - ./bin/django-admin migrate devops --settings=devops.settings - - -[Optional] Enabling `Nested Paging `_ -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The following section covers only Intel platform. This option is enabled by -default in the KVM kernel module. If the file ``qemu-system-x86.conf`` does not -exist, you have to create it. - -.. code-block:: bash - - cat /etc/modprobe.d/qemu-system-x86.conf - options kvm_intel nested=1 - -In order to be sure that this feature is enabled on your system, -please run: - -.. code-block:: bash - - sudo apt-get install --yes cpu-checker - sudo modprobe kvm_intel - sudo kvm-ok && cat /sys/module/kvm_intel/parameters/nested - -The result should be: - -.. code-block:: bash - - INFO: /dev/kvm exists - KVM acceleration can be used - Y - - -Environment creation via Devops + Fuel_QA or Fuel_main -------------------------------------------------------- - -Depending on the Fuel release, you may need a different repository. - -1. Clone GIT repository - -For 6.1 and later, the *fuel-qa* is required: - -.. code-block:: bash - - git clone https://github.com/openstack/fuel-qa - cd fuel-qa/ - -.. note:: It is recommended to use the stable branch related to the ISO version. - For instance, with FUEL v7.0 ISO: - - .. code-block:: bash - - git clone https://github.com/openstack/fuel-qa -b stable/7.0 - -In case of 6.0 or earlier, please use *fuel-main* repository: - -.. code-block:: bash - - git clone https://github.com/openstack/fuel-main -b stable/6.0 - cd fuel-main/ - - -2. Install requirements (follow :ref:`DevOpsPyPIvenv` section for the -WORKING_DIR variable) - -.. code-block:: bash - - . $WORKING_DIR/fuel-devops-venv/bin/activate - pip install -r ./fuelweb_test/requirements.txt --upgrade - -.. note:: A certain version of fuel-devops is specified in the - ./fuelweb_test/requirements.txt , so it will overwrite the already installed - fuel-devops. For example, for fuel-master branch stable/6.0, there is: - - .. code-block:: bash - - git+git://github.com/stackforge/fuel-devops.git@2.5.6 - - It is recommended to install the django tables and data after installing - fuel-qa requiremets: - - .. code-block:: bash - - django-admin.py syncdb --settings=devops.settings - django-admin.py migrate devops --settings=devops.settings - -3. Check :ref:`DevOpsConf` section - -4. Prepare environment - -Download Fuel ISO from -`Nightly builds `_ -or build it yourself (please, refer to :ref:`building-fuel-iso`) - -Next, you need to define several variables for the future environment: - * the path where is located your iso (e.g. $WORKING_DIR/fuel-community-7.0.iso) - * the number of nodes instantiated for the environment (e.g. 5) - -.. code-block:: bash - - export ISO_PATH=$WORKING_DIR/fuel-community-7.0.iso - export NODES_COUNT=5 - -Optionally you can specify the name of your test environment (it will -be used as a prefix for the domains and networks names created by -libvirt, defaults is ``fuel_system_test``). - -.. code-block:: bash - - export ENV_NAME=fuel_system_test - export VENV_PATH=$WORKING_DIR/fuel-devops-venv - -If you want to use separated files for snapshots you need to set env variable -and use the following required versions: - - * fuel-devops >= 2.9.17 - * libvirtd >= 1.2.12 - -This change will switch snapshots created by libvirt from internal to external -mode. - -.. code-block:: bash - - export SNAPSHOTS_EXTERNAL=true - -.. note:: External snapshots by default uses ~/.devops/snap directory to store - memory dumps. If you want to use other directory you can set - SNAPSHOTS_EXTERNAL_DIR variable. - - .. code-block:: bash - - export SNAPSHOTS_EXTERNAL_DIR=~/.devops/snap - -Alternatively, you can edit this file to set them as a default values - -.. code-block:: bash - - fuelweb_test/settings.py - -Start tests by running this command - -.. code-block:: bash - - ./utils/jenkins/system_tests.sh -t test -w $(pwd) -j fuelweb_test -i $ISO_PATH -o --group=setup - -For more information about how tests work, read the usage information - -.. code-block:: bash - - ./utils/jenkins/system_tests.sh -h - -Important notes for Sahara tests --------------------------------- - * It is not recommended to start tests without KVM. - * For the best performance Put Sahara image - `savanna-0.3-vanilla-1.2.1-ubuntu-13.04.qcow2 `_ - (md5: 9ab37ec9a13bb005639331c4275a308d) in /tmp/ before start, otherwise - (If Internet access is available) the image will download automatically. - -Important notes for Murano tests --------------------------------- - * Murano is deprecated in Fuel 9.0. - * Put Murano image `ubuntu-murano-agent.qcow2 `_ - (md5: b0a0fdc0b4a8833f79701eb25e6807a3) in /tmp before start. - * Running Murano tests on instances without an Internet connection will fail. - * For Murano tests execute 'export SLAVE_NODE_MEMORY=5120' before starting. - * If you need an image For Heat autoscale tests check - `prebuilt-jeos-images `_. - -Run single OSTF tests several times ------------------------------------ - * Export environment variable OSTF_TEST_NAME. Example: export OSTF_TEST_NAME='Request list of networks' - * Export environment variable OSTF_TEST_RETRIES_COUNT. Example: export OSTF_TEST_RETRIES_COUNT=120 - * Execute test_ostf_repetable_tests from tests_strength package - -Run tests :: - - sh "utils/jenkins/system_tests.sh" -t test \ - -w $(pwd) \ - -j "fuelweb_test" \ - -i "$ISO_PATH" \ - -V $(pwd)/venv/fuelweb_test \ - -o \ - --group=create_delete_ip_n_times_nova_flat - -.. _How to migrate: - -Upgrade from system-wide devops to devops in Python virtual environment ------------------------------------------------------------------------- - -To migrate from older devops, follow these steps: - -1. Remove system-wide fuel-devops (e.g. python-devops) - -You must remove system-wide fuel-devops and switch to separate venvs with -different versions of fuel-devops, for Fuel 6.0.x (and older) and 6.1 release. - -Repositories 'fuel-main' and 'fuel-qa', that contain system tests, must use -different Python virtual environments, for example: - -* ~/venv-nailgun-tests - used for 6.0.x and older releases. Contains version 2.5.x of fuel-devops -* ~/venv-nailgun-tests-2.9 - used for 6.1 and above. Contains version 2.9.x of fuel-devops - -If you have scripts which use system fuel-devops, fix them, and activate Python -venv before you start working in your devops environment. - -By default, the network pool is configured as follows: - -* 10.108.0.0/16 for devops 2.5.x -* 10.109.0.0/16 for 2.9.x - -Please check other settings in *devops.settings*, especially the connection -settings to the database. - -Before using devops in Python venv, you need to `install system dependencies`_ - -2. Update fuel-devops and Python venv on CI servers - -To update fuel-devops, you can use the following examples: - -.. code-block:: bash - - # DevOps 2.5.x for system tests from 'fuel-main' repository - if [ -f ~/venv-nailgun-tests/bin/activate ]; then - echo "Python virtual env exist" - else - rm -rf ~/venv-nailgun-tests - virtualenv --no-site-packages ~/venv-nailgun-tests - fi - source ~/venv-nailgun-tests/bin/activate - pip install -r https://raw.githubusercontent.com/openstack/fuel-main/master/fuelweb_test/requirements.txt --upgrade - django-admin.py syncdb --settings=devops.settings --noinput - django-admin.py migrate devops --settings=devops.settings --noinput - deactivate - - # DevOps 2.9.x for system tests from 'fuel-qa' repository - if [ -f ~/venv-nailgun-tests-2.9/bin/activate ]; then - echo "Python virtual env exist" - else - rm -rf ~/venv-nailgun-tests-2.9 - virtualenv --no-site-packages ~/venv-nailgun-tests-2.9 - fi - source ~/venv-nailgun-tests-2.9/bin/activate - pip install -r https://raw.githubusercontent.com/openstack/fuel-qa/master/fuelweb_test/requirements.txt --upgrade - django-admin.py syncdb --settings=devops.settings --noinput - django-admin.py migrate devops --settings=devops.settings --noinput - deactivate - -3. Setup new repository of system tests for 6.1 release - -All system tests for 6.1 and higher were moved to -`fuel-qa `_ repo. - -To upgrade 6.1 jobs, follow these steps: - -* make a separate Python venv, for example in ~/venv-nailgun-tests-2.9 -* install `requirements `_ of system tests -* if you are using system tests on CI, please configure your CI to use new - Python venv, or export path to the new Python venv in the variable - ``VENV_PATH`` (follow :ref:`DevOpsPyPIvenv` section for the WORKING_DIR - variable): - - .. code-block:: bash - - export VENV_PATH=$WORKING_DIR/fuel-devops-venv-2.9 - - -Known issues ------------- - -* Some versions of libvirt contain a bug that breaks QEMU virtual machine - XML. You can see this when tests crush with a *libvirt: QEMU Driver error: - unsupported configuration: host doesn't support invariant TSC*. See: - `Bug 1133155 `_. - - Workaround: upgrade libvirt to the latest version. - -* If the same version of fuel-devops is used with several different databases - (for example, with multiple sqlite3 databases, or with a separated database for - each devops in different python virtual environments), there will be a - collision between Libvirt bridge names and interfaces. - - Workaround: use the same database for the same version of the fuel-devops. - - - for **2.9.x**, export the following env variables: - - .. code-block:: bash - - export DEVOPS_DB_NAME=fuel_devops - export DEVOPS_DB_USER=fuel_devops - export DEVOPS_DB_PASSWORD=fuel_devops - - - for **2.5.x**, edit the dict for variable ``DATABASES``: - - .. code-block:: bash - - vim $WORKING_DIR/fuel-devops-venv/lib/python2.7/site-packages/devops/settings.py - - diff --git a/devdocs/infra.rst b/devdocs/infra.rst deleted file mode 100644 index 1e2dcbf4a..000000000 --- a/devdocs/infra.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _infra: - -Fuel Infra configuration -======================== - -.. toctree:: - :maxdepth: 2 - - infra/overview - infra/jenkins_master_deployment - infra/jenkins_slave_deployment - infra/puppet_master_deployment - infra/zabbix_server_deployment - infra/seed_server_deployment diff --git a/devdocs/infra/jenkins_master_deployment.rst b/devdocs/infra/jenkins_master_deployment.rst deleted file mode 100644 index 20ee03dee..000000000 --- a/devdocs/infra/jenkins_master_deployment.rst +++ /dev/null @@ -1,83 +0,0 @@ -Jenkins Master -============== - -Jenkins master as a head of CI systems handles all tasks related to the build -system being responsible for its slaves connectivity, users authentication, and -job launches. - -Deployment ----------- - -Before you deploy the Jenkins master, perform the following tasks: - -#. Verify that the Puppet Master is deployed and DNS solution is working. -#. Consider using the Hiera role. As an example, see the ``jenkins_master`` role - included in the ``fuel-infra/puppet-manifests`` repository. -#. Set the following parameters for the Hiera role on the Jenkins Master: - - .. code-block:: ini - - --- - classes: - - '::fuel_project::jenkins::master' - - jenkins::master::jenkins_ssh_private_key_contents: | - -----BEGIN RSA PRIVATE KEY----- - MIIEogIBAAKCAQEAzVoDH+iIrEmNBytJqR5IFYUcR7A6JvNTyelt4wIHEgVmNSs/ - 9ry/fEivdaaYGJpw2tri23IWNl5PXInnzKZu0KuRDuqEjyiSYQA8gmAF/+2KJmSM - OCj+QIRutLnHbUyg9MvExSveWrXqZYHKvSS0SJ4a3YP75yS2yp1e5T9YOXX2Na5u - ... - LJnYPGIQsEziRtqpClCz9O6qyzPagom13y+s/uYrk9IKzSzjNvHKqzAFIF57paGo - 3TWXEjB/RazdPB0PWfc3kjruz8IhDsLKQYPX+h8JuLO8ZL20Mxo7o3bs/GQnDrw1 - g/PCKBJscu0RQxsa16tt5aX/IM82cJR6At3tTUyUpiwqNsVClJs= - -----END RSA PRIVATE KEY----- - - jenkins::master::jenkins_ssh_public_key_contents: | - 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNWgMf6IisSY0HK0mpHkgVhRxHs - Dom81PJ6W3jAgcSBWY1Kz/2vL98SK91ppgYmnDa2uLbchY2Xk9ciefMpm7Qq5EO6oS \ - ... - KnV7lP1g5dfY1rm6bum7P+Jwf2tdTOa0b5ucK/+iWVbyPO4Z2afPpblh4Vynfe2wMz \ - zpGAp3n5MwtH2EZmSXm/B6/CkgOFROsmWH8MzQEvNBGHhw+ONR9' - -#. Set proper service FQDN of the Jenkins Master instance: - - .. code-block:: ini - - fuel_project::jenkins::master::service_fqdn: 'jenkins-master.test.local' - -#. Adjust the security model of the Jenkins after the deployment: - - .. code-block:: ini - - jenkins::master::security_model: 'unsecured' || 'password' || 'ldap' - - .. note:: - The ``password`` is the most basic one, when Jenkins has no access to - the LDAP and you still require some authorization to be enabled in the - Jenkins. - -To deploy the Jenkins Master, complete the following steps: - -#. Install base Ubuntu 14.04 with SSH service and set appropriate FQDN. - -#. Install puppet agent package: - - .. code-block:: console - - apt-get update; apt-get install -y puppet - -#. Enable puppet agent: - - .. code-block:: console - - puppet agent --enable - -#. Run the Jenkins Master deployment: - - .. code-block:: console - - FACTER_ROLE=jenkins_master FACTER_LOCATION=us1 puppet agent -tvd \ - --server puppet-master.test.local --waitforcert 60 - -The last action requests the client's certificate. To continue the puppet run, -the certificate should be signed from the Puppet Master. \ No newline at end of file diff --git a/devdocs/infra/jenkins_slave_deployment.rst b/devdocs/infra/jenkins_slave_deployment.rst deleted file mode 100644 index 2a54c333c..000000000 --- a/devdocs/infra/jenkins_slave_deployment.rst +++ /dev/null @@ -1,101 +0,0 @@ -Jenkins Slave -~~~~~~~~~~~~~ - -The Jenkins Slave is a machine that is set up to run build projects scheduled -from the master. Slave runs a dedicated program called a ``slave agent`` -spawned from the master, thus there is no need to install Jenkins itself -on a slave. - -Deployment ----------- - -There are few ways to setup Jenkins master-slave connection, however in our -infra currently we use only one of them. -In general, the Jenkins master SSH-key is to be placed in authorized_keys file -for the jenkins user on a slave machine. Then via the Jenkins Master's WebUI -create a node manually by specifying slave's node FQDN. After, the Jenkins -master will connect to the slave via SSH to the jenkins user, upload -``slave.jar`` file and spawn it on slave using jenkins user. - -In order to deploy Jenkins Slave please look at already existing hiera -role for an example of jenkins slave instance. Check if ssh public key -authentication is properly configured. - -#. Ensure that in jenkins master hiera role the following two parameters are - set: - - .. code-block:: ini - - --- - classes: - - '::fuel_project::jenkins::master' - - jenkins::master::jenkins_ssh_private_key_contents: | - -----BEGIN RSA PRIVATE KEY----- - MIIEogIBAAKCAQEAzVoDH+iIrEmNBytJqR5IFYUcR7A6JvNTyelt4wIHEgVmNSs/ - 9ry/fEivdaaYGJpw2tri23IWNl5PXInnzKZu0KuRDuqEjyiSYQA8gmAF/+2KJmSM - ... - 3TWXEjB/RazdPB0PWfc3kjruz8IhDsLKQYPX+h8JuLO8ZL20Mxo7o3bs/GQnDrw1 - g/PCKBJscu0RQxsa16tt5aX/IM82cJR6At3tTUyUpiwqNsVClJs= - -----END RSA PRIVATE KEY----- - - jenkins::master::jenkins_ssh_public_key_contents: | - 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNWgMf6IisSY0HK0mpHkgVhRxHs \ - Dom81PJ6W3jAgcSBWY1Kz/2vL98SK91ppgYmnDa2uLbchY2Xk9ciefMpm7Qq5EO6oS \ - ... - KnV7lP1g5dfY1rm6bum7P+Jwf2tdTOa0b5ucK/+iWVbyPO4Z2afPpblh4Vynfe2wMz \ - zpGAp3n5MwtH2EZmSXm/B6/CkgOFROsmWH8MzQEvNBGHhw+ONR9' - - -#. In the jenkins slave role ensure to set proper 'authorized_keys' parameter - - .. code-block:: ini - - --- - classes: - - fuel_project::jenkins::slave - - jenkins::slave::authorized_keys: - 'jenkins@jenkins-master.test.local': - type: ssh-rsa - key: 'AAAAB3NzaC1yc2EAAAADAQABAAABAQDNWgMf6IisSY...BGHhw+ONR9' - - # optional - if you wish to use also password authentication, set to true: - ssh::sshd::password_authentication: true - -The above configuration is mandatory to be set in order to get proper -master-to-slave connection. - -Other case, if the slaves running the particular hiera role are suppose to be -able to buid the ISO, it is required to enable 'build_fuel_iso' parameter in -the 'slave' class. - - .. code-block:: ini - - fuel_project::jenkins::slave::build_fuel_iso: true - -To deploy Jenkins slave, complete the following steps: - -#. Install base Ubuntu 14.04 with SSH service and set appropriate FQDN. - -#. Install puppet agent package: - - .. code-block:: console - - apt-get update; apt-get install -y puppet - -#. Enable puppet agent: - - .. code-block:: console - - puppet agent --enable - -#. Run the Jenkins Master deployment. - - .. code-block:: console - - FACTER_ROLE=jenkins_slave FACTER_LOCATION=us1 puppet agent -tvd \ - --server puppet-master.test.local --waitforcert 60 - -The last action requests the client's certificate. To continue the puppet run, -the certificate should be signed from the Puppet Master. diff --git a/devdocs/infra/overview.rst b/devdocs/infra/overview.rst deleted file mode 100644 index f77acbd2d..000000000 --- a/devdocs/infra/overview.rst +++ /dev/null @@ -1,311 +0,0 @@ -Fuel Infrastructure -=================== - -Overview --------- - -Fuel Infrastructure is the set of systems (servers and services) which provide -the following functionality: - -* Automatic tests for every patchset committed to Fuel Gerrit repositories -* Fuel nightly builds -* Regular integration tests -* Custom builds and custom tests -* Release management and publishing -* Centralized log storage for gathering logs from infra's servers -* Internal and external mirrors, used by our infra and partners -* DNS service -* Server's monitoring service -* Docker's registry for managing custom docker images -* Small helper subsystems like status pages and so on - -Fuel Infrastructure servers are managed by Puppet from one Puppet Master node. - -To add new server to the infrastructure you can either take any server with base -Ubuntu 14.04 installed and connect it to the Puppet Master via puppet agent, or -you can first set up the PXE-server with PXETool and then run -server provisioning in automated way. - -Your infrastructure must have a DNS service running in order to resolve the -mandatory hosts like puppet-master.test.local or pxetool.test.local. There are -at least two possible scenarios of using DNS in infra. -Using DHCP service in your infra is optional, but can be more elastic and -comfortable than static IP configuration. - -#. Create own DNS service provided by dnsmasq in your infra. - - #. Install base Ubuntu 14.04 with SSH service and set an appropriate FQDN - such as ``dns01.test.local`` and configure the Dnsmasq service: - - .. code-block:: console - - apt-get update; apt-get install -y dnsmasq - echo "addn-hosts=/etc/dnsmasq.d/hosts" >> /etc/dnsmasq.conf - echo "192.168.50.2 puppet-master.test.local puppet-master" > /etc/dnsmasq.d/hosts - echo "192.168.50.3 pxetool.test.local puppet-master" > /etc/dnsmasq.d/hosts - service dnsmasq restart - - #. If you use a static IP, verify that the ``/etc/resolv.conf`` file points - to your DNS. - #. If you use a dynamic IP, verify that the DHCP service is updated - correspondingly. - -#. Add a new zone to your current DNS setup or use an external, online DNS service. - - #. Add a zone named ``test.local``. - #. Add an appropriate A and its coresponding PTR record for the - ``puppet-master`` name (mandatory for deployment) at least. - #. If you use a static IP, verify that the ``/etc/resolv.conf`` file points - to your DNS, - #. If you use a dynamic IP, verify that the DHCP service is updated - correspondingly. - -Jenkins Jobs ------------- - -Our CI requires many jobs and configuration, it is not convenient to configure -everything with jenkins GUI. We use dedicated -`repository `_ and -`JJB `_ -to store and manage our jobs. - -Install Jenkins Job Builder -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To begin work with jenkins job builder we need to install it and configure. - -#. Install packages required to work with JJB - - .. code-block:: console - - apt-get install -y git python-tox - # or - yum install git python-tox - -#. Download git repository and install JJB - - .. code-block:: console - - git clone https://github.com/fuel-infra/jenkins-jobs.git - cd jenkins-jobs - tox - -#. Enable python environment, please replace with server name, for - example fuel-ci - - .. code-block:: console - - source .tox//bin/activate - -#. Create file jenkins_jobs.ini with JJB configuration. It could be created - at any place, for this documentation we assume that it will be placed in - conf/ directory, inside local copy of jenkins-jobs repository. - - .. code-block:: console - - [jenkins] - user= - password= - url=https:/// - - [job_builder] - ignore_cache=True - keep_descriptions=False - recursive=True - include_path=.:scripts - - .. note:: is the user already defined in Jenkins with an - appropriate permissions set: - - * Read - under the Global group of permissions - * Create, Delete, Configure and Read - under the Job group of permissions - -Upload jobs to Jenkins -~~~~~~~~~~~~~~~~~~~~~~ - -When JJB is installed and configured you can upload jobs to jenkins master. - -.. note:: We assume that you are in main directory of jenkins-jobs repository - and you have enabled python environment. - -Upload all jobs configured for one specified server, for example upload of -fule-ci can be done in this way: - - .. code-block:: console - - jenkins-jobs --conf conf/jenkins_jobs.ini update servers/fuel-ci:common - - -Upload only one job - - .. code-block:: console - - jenkins-jobs --conf conf/jenkins_jobs.ini update servers/fuel-ci:common 8.0-community.all - -Building ISO with Jenkins -------------------------- - -Requirements -~~~~~~~~~~~~ - -For minimal environment we need 3 systems: - -* Jenkins master -* Jenkins slave with enabled slave function for ISO building and deployment - testing. This can be done in different ways. For instance, you can create - hiera role for such server with the values provided below. Please keep in - mind that you have to explicitely set run_test and build_fuel_iso variables - to true, as ones are not enabled by default. - - .. code-block:: ini - - --- - classes: - - '::fuel_project::jenkins::slave' - - fuel_project::jenkins::slave::run_test: true - fuel_project::jenkins::slave::build_fuel_iso: true - - .. note:: Every slave which will be used for ISO deployment testing, like - BVT, requires additional preparation. - - Once puppet is applied, and slave is configured in Jenkins master, you need - to run the prepare_env job on it. Job will setup the python virtual - environment with fuel-devops installed (:doc:`../devops`). - - If you build ISO newer than 6.1 there is no need to change default job - parameters. For older versions you need to run build with - update_devops_2_5_x option checked. - -* Seed server - it is the server where you plan to store built ISO - - -Create Jenkins jobs -~~~~~~~~~~~~~~~~~~~ - -To build your own ISO you need to create job configurations for it, it requires -a few steps: - -#. Create your own jobs repository, for start we will use fuel-ci jobs - - .. code-block:: console - - cd jenkins-jobs/servers - cp -pr fuel-ci test-ci - -#. To build and test ISO we will use files: - - * servers/test-ci/8.0/community.all.yaml - * servers/test-ci/8.0/fuel_community_publish_iso.yaml - * servers/test-ci/8.0/fuel_community.centos.bvt_2.yaml - * servers/test-ci/8.0/fuel_community.ubuntu.bvt_2.yaml - -#. In all files you need to make changes: - - * Change email alert@example.com to your own - - * If you don't need reporting jobs you should delete triggering of - fuel_community_build_reports in all jobs or disable reporting job - - .. code-block:: ini - - - job: - ... - publishers: - ... - - trigger-parameterized-builds: - ... - - project: fuel_community_build_reports - - * Update seed name server in file - servers/test-ci/8.0/fuel_community_publish_iso.yaml - - .. code-block:: ini - - - job: - ... - publishers: - ... - - trigger-parameterized-builds: - ... - - project: 8.0.fuel_community.centos.bvt_2, 8.0.fuel_community.ubuntu.bvt_2 - ... - predefined-parameters: | - ISO_TORRENT=http://seed.fuel-infra.org/fuelweb-iso/fuel-community-$ISO_ID.iso.torrent - - * Update seed name server in file - servers/test-ci/8.0/builders/publish_fuel_community_iso.sh - - .. code-block:: console - - sed -i 's/seed-us1.fuel-infra.org/seed.test.local/g' servers/test-ci/8.0/builders/publish_fuel_community_iso.sh - sed -i 's/seed-cz1.fuel-infra.org/seed.test.local/g' servers/test-ci/8.0/builders/publish_fuel_community_iso.sh - -#. Create jobs on jenkins master - - .. note:: Please remember to: - - * change current directory to the root directory of cloned jenkins-jobs repository - * enable python environment - * use correct jenkins_jobs.ini file (with correct jenkins master server) - - .. code-block:: console - - jenkins-jobs --conf conf/jenkins_jobs.ini update servers/test-ci:common 8.0-community.all - jenkins-jobs --conf conf/jenkins_jobs.ini update servers/test-ci:common 8.0.publish_fuel_community_iso - jenkins-jobs --conf conf/jenkins_jobs.ini update servers/test-ci:common 8.0.fuel_community.centos.bvt_2 - jenkins-jobs --conf conf/jenkins_jobs.ini update servers/test-ci:common 8.0.fuel_community.ubuntu.bvt_2 - - -Start ISO building -~~~~~~~~~~~~~~~~~~ - -When you finish setting jobs up on jenkins master you will see project with -name 8.0-community.all there, to start ISO build and test procedure you need -to run mentioned project. - -Build and test procedure have 3 steps: - -* ISO building (8.0-community.all) -* when ISO is successfully created it will be uploaded to the seed server - (by triggering 8.0.publish_fuel_community_iso) -* successful upload will start BVT test (8.0.fuel_community.centos.bvt_2 and - 8.0.fuel_community.ubuntu.bvt_2) - - -Gerrit ------- - -Although fuel-* repositories are hosted by the `OpenStack Gerrit `_, -we use additional Gerrit instance to host OpenStack packages, internal projects and all the code -related to Infrastructure itself. - -Our Gerrit instance is installed and configured by Puppet, including specifying -the exact Java WAR file that is used(link). To manage Gerrit instance we use -`Jeepyb `_ - the tool written by Openstack Infra -team, which allows to store projects configuration in YAML format. - -To use Jeepyb with gerrit you need to create "projects.yaml" configuration file, -where for each project you add the following information: - -* project name -* project description -* project ACL -* project upstream - -If "upstream" option is specified, Jeepyb will automaticaly import the upstream -repository to this new project. To apply the configuration, use "manage-projects" command. - -Every project has ACL file. One ACL file can be reused in several projects. In -ACL file, access rights are defined based on the Gerrit user groups. -For example, in this file you can allow certain group to use the Code-Review -+/-2 marks. - -In our gerrit, we have some global projects - /. The Core Reviewers -for these projects are . - -Contributing -~~~~~~~~~~~~ - -Feedback -~~~~~~~~ \ No newline at end of file diff --git a/devdocs/infra/puppet_master_deployment.rst b/devdocs/infra/puppet_master_deployment.rst deleted file mode 100644 index 1500424c4..000000000 --- a/devdocs/infra/puppet_master_deployment.rst +++ /dev/null @@ -1,133 +0,0 @@ -.. _puppet_master: - -Puppet Master -~~~~~~~~~~~~~ - -Puppet is a tool which provides ability to manage configuration of systems in an -automatic way using the declarative language. The so called 'manifests' are -used for describing particular system configuration. - -Deployment ----------- - -In order to install Puppet Master on the brand new server running Ubuntu please -proceed with the following steps: - -#. Install Ubuntu 14.04 with SSH service and set FQDN to puppet-master.test.local - -#. Install git and clone Puppet Manifests repository into /etc/puppet directory: - - .. code-block:: console - - apt-get install -y git - git clone https://github.com/fuel-infra/puppet-manifests.git /etc/puppet - cd /etc/puppet - git submodule init - git submodule update - -#. Execute the Puppet Master's install script: - - .. code-block:: console - - /etc/puppet/bin/install_puppet_master.sh - -The script does the following: - -* upgrades all packages on the system -* installs required puppet modules -* installs Puppet Master packages -* runs puppet apply to setup Puppet Master -* runs puppet agent to do a second pass and verify if installation is usable - -When script finishes successfully, the Puppet Master installation is completed. - - -Using Hiera -~~~~~~~~~~~ - -Puppet can use Hiera to look for data. Hiera allows to override manifest -parameter values during the deployment, thus it is possible to create -a specific data configuration for easier code re-use and easier management of -data that needs to differ across nodes. -All related Hiera structure is placed under the ``/var/lib/hiera`` directory. - -The Hiera hierarchy -------------------- - - #. common.yaml - the most general, - #. locations/%{::location}.yaml - can override common's data, - #. roles/%{::role}.yaml - can override location's and common's data - #. nodes/%{::clientcert}.yaml - can override data specified in common, - location and role. - -The ``common`` and ``nodes`` are used within every deployment when exist. But in -contrast, the ``location`` and ``role`` needs to be passed explicitly as a -variable within ``puppet agent`` run, in order to use them. An example: - - .. code-block:: console - - FACTER_ROLE=websrv FACTER_LOCATION=us1 puppet agent -tvd - -To include puppet's class in a role, it is required to use the ``classes`` -keyword on the role's beginning. An example: - - .. code-block:: ini - - --- - classes: - - '::class1::class2' - -.. note:: - avoid including classes in more than one place since this will lead to - duplicate class declaration error. - -Other example - create a role's stub for 'docker_registry' module and make -sure that each of the nodes running that role have its own, custom, service's -FQDN set in Nginx's Vhost. - -#. File 'roles/docker_registry.yaml' - - .. code-block:: ini - - --- - classes: - - '::docker_registry' - - '::fuel_project::nginx' - - '::fuel_project::apps::firewall' - - '::fuel_project::common' - - docker_registry::service_fqdn: '%{::fqdn}' - -#. File 'nodes/srv01-us.infra.test.local.yaml' - - .. code-block:: ini - - --- - - docker_registry::service_fqdn: 'registry-us1.infra.test.local' - -#. File 'nodes/srv01-cz.infra.test.local.yaml' - - .. code-block:: ini - - --- - - docker_registry::service_fqdn: 'registry-cz1.infra.test.local' - -On a ``srv01-us.infra.test.local`` node, during the deployment of a -``docker_registry`` role, a default value for ``service_fqdn`` class parameter -has been overridden. - -After the deployment using FACTER variable a facter file is created containing -the used FACTERs variables. For instance: - - .. code-block:: console - - cat /etc/facter/facts.d/facts.sh - #!/bin/bash - - echo "location=us1" - echo "role=docker_registry" - -Having these, now every next puppet agent run will not require ``FACTER`` variables -to be passed (if no role nor location is to be changed). diff --git a/devdocs/infra/seed_server_deployment.rst b/devdocs/infra/seed_server_deployment.rst deleted file mode 100644 index 61ac85e56..000000000 --- a/devdocs/infra/seed_server_deployment.rst +++ /dev/null @@ -1,91 +0,0 @@ -Seed server -=========== - -Seed server serves the files, such as ISO and disk images that were uploaded -from other servers or clients. Seed can host the content by the rsync, http, -or torrent protocol, depending on the Hiera's role configuration. - -Deployment ----------- - -Before you deploy Seed server, verify that you have completed the following tasks: - -#. Deploy the Puppet Master -#. Verify that the DNS solution works. -#. On the Puppet Master, create ``seed``, a dedicated Hiera role from which all - necessary services as opentracker will install. - - .. note:: - For torrent download, do not include the ``fuel_project::apps::mirror`` - -#. On the Jenkins Master, verify that the ``seed`` Hiera role exists: - - .. code-block:: ini - - --- - classes: - - 'fuel_project::common' - - 'fuel_project::apps::seed' - - 'fuel_project::apps::firewall' - - 'opentracker' - - fuel_project::apps::seed::vhost_acl_allow: - - 10.0.0.2/32 # IP's slave example on which ISO is build - - fuel_project::apps::seed::service_fqdn: 'seed.test.local' - - fuel_project::apps::seed::seed_cleanup_dirs: - - dir: '/var/www/seed/fuelweb-iso' - ttl: 11 - pattern: 'fuel-*' - - fuel_project::apps::firewall::rules: - '1000 - allow ssh connections from 0.0.0.0/0': - source: 0.0.0.0/0 - dport: 22 - proto: tcp - action: accept - - '1000 - allow data upload connections from temp build1.test.local': - source: 10.0.0.2/32 - dport: 17333 - proto: tcp - action: accept - - '1000 - allow zabbix-agent connections from 10.0.0.200/32': - source: 10.0.0.200/32 - dport: 10050 - proto: tcp - action: accept - - '1000 - allow torrent traffic within 10.0.0.0/8 network': - source: 10.0.0.0/8 - dport: 8080 - proto: tcp - action: accept - -To deploy Seed server, complete the following steps: - -#. Install base Ubuntu 14.04 with SSH service and set appropriate FQDN. - -#. Install puppet agent package: - - .. code-block:: console - - apt-get update; apt-get install -y puppet - -#. Enable puppet agent: - - .. code-block:: console - - puppet agent --enable - -#. Run the deployment of the ``seed`` role: - - .. code-block:: console - - FACTER_ROLE=seed FACTER_LOCATION=us1 puppet agent -tvd \ - --server puppet-master.test.local --waitforcert 60 - -The last action requests the client's certificate. To continue the puppet run, -the certificate should be signed from the Puppet Master. diff --git a/devdocs/infra/zabbix_server_deployment.rst b/devdocs/infra/zabbix_server_deployment.rst deleted file mode 100644 index 777ce2505..000000000 --- a/devdocs/infra/zabbix_server_deployment.rst +++ /dev/null @@ -1,58 +0,0 @@ -Zabbix server -============= - -Zabbix is an open source tool designed for servers, services, and network -monitoring. - -Deployment ----------- - -Zabbix can be deployed on a virtual machine with at least 1 GB RAM and 1 CPU. -The HW requirements vary and depend on the potential Zabbix's server load and -place of the database engine, for example, MySQL, regardless of whether it is -located on the same host or on a dedicated one. - -The puppet-manifests repository contains an example ``zbxserver`` role -that can be used as a starting point for Zabbix server deployment. - -To deploy Zabbix, perform the following tasks: - -#. Install base Ubuntu 14.04 with SSH service and set appropriate FQDN. - -#. Install puppet agent package: - - .. code-block:: console - - apt-get update; apt-get install -y puppet - -#. Enable puppet agent: - - .. code-block:: console - - puppet agent --enable - -#. Run the Jenkins Master deployment: - - .. code-block:: console - - FACTER_ROLE=zbxserver FACTER_LOCATION=us1 puppet agent -tvd \ - --server puppet-master.test.local --waitforcert 60 - -The last action requests the client's certificate. To continue the puppet run, -the certificate should be signed from the Puppet Master. - -Import templates ----------------- - -You can import templates and related items, such as triggers, that comes from -Fuel's Zabbix production server. To do this, complete the following tasks: - -#. Clone the ``tools/zabbix-maintenance`` repository: - - .. code-block:: console - - git clone https://review.fuel-infra.org/tools/zabbix-maintenance - -#. In the Zabbix server web UI, navigate to :guilabel:`Configuration -> - Templates`. Import the required template file using the :guilabel:`Import` - button. diff --git a/devdocs/packaging.rst b/devdocs/packaging.rst deleted file mode 100644 index 74df9d07c..000000000 --- a/devdocs/packaging.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. _packaging: - -Packaging -========= - -.. toctree:: - :maxdepth: 3 - - packaging/package_versions - packaging/perestroika diff --git a/devdocs/packaging/package_versions.rst b/devdocs/packaging/package_versions.rst deleted file mode 100644 index c15782195..000000000 --- a/devdocs/packaging/package_versions.rst +++ /dev/null @@ -1,90 +0,0 @@ -Package version problems -======================== - -The introduction of OpenStack updates brought up one non-obvious problem with -package versions. In order to update a package the new version should be -considered higher than the previous one. Package versions are compared between -the old and the new packages and a package manager then decides if the new -package installation is an upgrade or a downgrade. The algorithm used to -compare version numbers is different for rpm and deb packages and Puppet uses -its own implementation. - -Previously we have never tried to update our OSCI packages from the previous -version and did not think about version number comparison and many packages -were named badly. - -For example: -2014.1.fuel5.0-mira4 2014.1.1.fuel5.1-mira0 -In this case most of version comparison algorithms would find 5.0 version -to be larger than 5.1. - -:: - - * Native Puppet - 2014.1.fuel5.0-mira4 > 2014.1.1.fuel5.1-mira0 - * Puppet RPMVERCMP - 2014.1.fuel5.0-mira4 < 2014.1.1.fuel5.1-mira0 - * Native RPM - 0:2014.1.fuel5.0-mira4 < 0:2014.1.1.fuel5.1-mira0 - * Native DEB - 2014.1.fuel5.0-mira4 > 2014.1.1.fuel5.1-mira0 - -This is because we have not been using correct separation between package -version and revision and these packages should have been named like this: - -:: - - 2014.1-fuel5.0.mira4 2014.1.1-fuel5.1.mira0 - * Native Puppet - 2014.1-fuel5.0.mira4 < 2014.1.1-fuel5.1.mira0 - * Puppet RPMVERCMP - 2014.1-fuel5.0.mira4 < 2014.1.1-fuel5.1.mira0 - * Native RPM - 0:2014.1-fuel5.0.mira4 < 0:2014.1.1-fuel5.1.mira0 - * Native DEB - 2014.1-fuel5.0.mira4 < 2014.1.1-fuel5.1.mira0 - -This also affect other packages not only OpenStack ones. - -:: - - 1.0.8.fuel5.0-mira0 1.0.8-fuel5.0.2.mira1 - * Native Puppet - 1.0.8.fuel5.0-mira0 > 1.0.8-fuel5.0.2.mira1 - * Puppet RPMVERCMP - 1.0.8.fuel5.0-mira0 < 1.0.8-fuel5.0.2.mira1 - * Native RPM - 0:1.0.8.fuel5.0-mira0 > 0:1.0.8-fuel5.0.2.mira1 - * Native DEB - 1.0.8.fuel5.0-mira0 > 1.0.8-fuel5.0.2.mira1 - -The most complex part of this problem is that even if we change our current -package naming to be correct one we cannot change packages already installed -and used in production. So we have raised epoch for many 5.0.2 packages to make -it possible to upgrade them from incorrectly named 5.0 packages and move to the -correct naming scheme. In Fuel 5.1 and higher we will be using only correct -naming and epoch can be removed. - -:: - - 0:1.0.8.fuel5.0-mira0 1:1.0.8-fuel5.0.2.mira1 - * Native Puppet - 0:1.0.8.fuel5.0-mira0 < 1:1.0.8-fuel5.0.2.mira1 - * Puppet RPMVERCMP - 0:1.0.8.fuel5.0-mira0 < 1:1.0.8-fuel5.0.2.mira1 - * Native RPM - 0:1.0.8.fuel5.0-mira0 < 1:1.0.8-fuel5.0.2.mira1 - * Native DEB - 0:1.0.8.fuel5.0-mira0 < 1:1.0.8-fuel5.0.2.mira1 - -As you can see, raising epoch allows us to set which version is higher -regardless its actual value. -Removing epoch from 5.1 packages makes it impossible to seamlessly upgrade -5.0 or 5.0.2 packages to 5.1 ones. It’s not really a problem because we -don’t support such upgrades anyway but if you do try to make such upgrade -manually you should remove old packages manually before installing new packages. - -* My version checkers for all algorithms: https://github.com/dmitryilyin/vercmp -* RPM naming guidelines: http://fedoraproject.org/wiki/Packaging:NamingGuidelines -* RPM comparison: http://fedoraproject.org/wiki/Archive:Tools/RPM/VersionComparison -* DEB naming guidelines and version comparison: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version diff --git a/devdocs/packaging/perestroika.rst b/devdocs/packaging/perestroika.rst deleted file mode 100644 index 3d7e1fb58..000000000 --- a/devdocs/packaging/perestroika.rst +++ /dev/null @@ -1,131 +0,0 @@ -Perestroika build system -======================== - -Introduction ------------- - -Fuel 7.0 introduces a new build system called Perestroika. It uses -standard upstream Linux distribution tools in order to: - -* build packages (SBuild/Mock) -* publish packages to repositories -* manage package repositories (using reprepro/createrepo tools). - -Every package is built in a clean and up-to-date buildroot. Packages, -their dependencies, and build dependencies are fully self-contained -for each OpenStack release. Any package included in any release can be rebuilt -at any point in time using only the packages from that release. - -The package build CI is reproducible and can be recreated from scratch -in a repeatable way. - -Perestroika is based on Docker which provides an easy distribution. -Each supported Linux distribution contains proper Docker images with -necessary tools and scripts. - -For the advantages of Perestroika over OBS build system, see -`Replace OBS with another build system `_. - -Perestroika structure ---------------------- - -Scheduler -~~~~~~~~~ - -This part is based on Jenkins CI tool. All jobs are configured using -``jenkins-job-builder``. Jenkins has a separate set of jobs for each -*[customer name]+[fuel version]* case. Gerrit-trigger is configured -to track events from the *{version}* branch of all the *[customer-name]* -Gerrit projects. - -Each set of jobs contains: - -* jobs for OpenStack packages for a cluster (``.rpm`` and ``.deb``) -* jobs for Linux packages for a cluster (``.rpm`` and ``.deb``) -* jobs for OpenStack packages for Fuel Master node (``.rpm``). In case - of using cluster packages, they are optional. -* jobs for non-OpenStack Fuel Master node packages (``.rpm``) -* jobs for Fuel packages (``.rpm`` and ``.deb``) -* a job for package publishing - -Build workers -~~~~~~~~~~~~~ - -These are hardware nodes with preconfigured build tools for all the -supported distributions. They are configured as Jenkins slaves. - -Each worker contains: - -* preconfigured Docker images with native build tools for each - distribution type: - - - ``mockbuild`` builds packages using Mock (CentOS 6 and 7 target - distributions are supported). - - ``sbuild`` builds packages using SBuild tool (Ubuntu Trusty - Tahr target distribution is supported only). - -* prepared minimal build chroots for all the supported distributions: - - - These chroots are updated on a daily basis in order to be up-to-date - against the upstream state. - - Chroot updating is performed by a separate Jenkins job. - - No build jobs can run on a build host while the updating Jenkins job - is running on it. - -**Building stage flow**: - -#. Checking out sources from Gerrit. -#. Preparing sources to build (creating tarball files, updating - changelogs). -#. Building sources (performed in an isolated environment inside a - Docker container). -#. Getting the build stage exit status, build logs, and built - packages. -#. Parsing and archiving build logs for Jenkins artifacts. - -Packaging CI uses short-lived Docker containers to perform package -building. Docker images contain preconfigured build tools only. There -are no chroots inside images. Build chroots are mounted to a Docker -container at start in a read-only mode. Additionally *tmpfs* partition -is mounted over a read-only chroot folder with AUFS overlays inside -a Docker container. The container is destroyed once the build stage is -completed. - -**Goals of this scheme**: - -* It can run a number of containers with the only chroot simultaneously - on the same build host. -* There is no need to perform clean-up operations after the build (all - changes matter inside the container only and will be purged after the - container is destroyed). -* *tmpfs* works much faster than disk FS/LVM snapshots. - -Publisher node -~~~~~~~~~~~~~~ - -If the build stage finishes successfully, Jenkins runs a publishing -job. The Publisher node contains all repositories for all customer -projects. It is configured as a Jenkins slave. The repositories are -maintained by native tools of their respective distribution -(reprepro or createrepo). - -The Publisher slave is fully private and available from Jenkins Master -node only because of containing a GPG key. All the packages and -repositories are signed in terms of their respective distribution by -GPG keys that are stored on the Publisher node. - -**Publishing stage**: - -#. Getting built packages from the build host (over ``scp``). -#. Checking if packages can be added to a repository (version checking - against existing packages in order to prevent downgrading). -#. Signing new packages (all ``.rpm`` and source ``.deb``) with GPG keys. -#. Removing existing and adding new packages to a repository. -#. Resigning the repository metadata. -#. Syncing new repository state to a Mirror host (over ``rsync``). - -Mirror node -~~~~~~~~~~~ - -All repositories are available through http or rsync protocols and are -synced by a Publisher to a Mirror host. \ No newline at end of file diff --git a/examples/network_templates.html b/examples/network_templates.html deleted file mode 100644 index f6773337c..000000000 --- a/examples/network_templates.html +++ /dev/null @@ -1,12 +0,0 @@ - - -network_templates - - -

network_templates

-default.yaml
-one_network.yaml
-two_networks.yaml
- - - diff --git a/examples/network_templates/default.yaml b/examples/network_templates/default.yaml deleted file mode 100644 index ea58ff9b7..000000000 --- a/examples/network_templates/default.yaml +++ /dev/null @@ -1,199 +0,0 @@ -adv_net_template: -# default - is the name of the node network group. If you have additional -# node network groups, add descriptions with all parameters for all node -# network group. -# If parameters of additional node network groups are not described in this -# template, parameters of the default node network group apply. - default: - nic_mapping: -# NIC mapping for nodes in this node network group. The default section will -# be used for all nodes unless they are specifically configured. You can -# specify mapping for every node by the node name - default: -# Specify aliases for network interfaces, such as eth0, and -# sub-interfaces (VLANs), such as eth0.101 to -# later use them in the transformation section. - adm: eth0 - pub: eth1 - man: eth4 - priv: eth2 - stor: eth3 - templates_for_node_role: -# Specify templates for each type of node (node role), such as controller, -# compute, storage, and so on. The order of templates -# is important. For example, if you create a bond in one template and later -# use it in the other template, you must place the template in which you -# created the bond before the other template, so that the bond is created -# before it is referenced in the other template. - controller: - - public - - private - - storage - - common - compute: - - common - - private - - storage - cinder: - - common - - storage - ceph-osd: - - common - - storage - network_assignments: -# Specify an endpoint for each network, if you add additional custom networks, -# add endpoints for these networks as well. - storage: - ep: br-storage - private: - ep: br-prv - public: - ep: br-ex - management: - ep: br-mgmt - fuelweb_admin: - ep: br-fw-admin - network_scheme: -# Describe the network scheme for all node roles. -# - transformations - describe actions required to create a network. -# For service networks, such as Storage, Management, and Admin, -# create a Linux bridge. For workload networks that -# communicated with the OpenStack Networking service, such as -# Private and Public service, create an Open vSwitch (OVS), -# a Linux Bridge, a patch that connects the OVS with the Linux -# bridge, and a port. -# Available commands: -# -# * ``add-br`` - creates a bridge. By default, creates a Linux -# bridge. -# -# * ``add-port`` - creates a port that connects a Linux bridge with a -# physical network interface. -# -# * ``add-patch`` - connects two network bridges. All networks that -# serve traffic to the control plane must have a patch that connects -# the OVS bridge and the Linux bridge. -# -# * ``add-bond`` - add a network interface bonding for high workload -# networks to increase performance and provide high availability. -# -# For more information about the properties that you can specify, see -# the Fuel User Guide: http://docs.openstack.org/developer/fuel-docs.html. -# -# - endpoints - specify the list of logical endpoints for the networks -# that you have defined in the network_assignments section. -# -# - roles - map network traffic (network roles) to logical endpoints in the -# : format. The list of network roles is -# available in the nailgun/nailgun/fixtures/openstack.yaml file. -# Any type of traffic must be mentioned in the whole node network -# group just once, therefore, do not repeat any type of traffic in multiple -# entries. Otherwise, a network -# conflict may occur. The roles section cannot be empty. If you do not -# want to specify any type of traffic, create a fake mapping. For example: -# roles: -# fake/ext: br-pub-ext -# -# Plugins may have additional types of traffic. For more information, see -# plugin documentation. -# - storage: - transformations: - - action: add-br - name: br-storage - - action: add-port - bridge: br-storage - name: <% stor %>.1001 - endpoints: - - br-storage - roles: - cinder/iscsi: br-storage - swift/replication: br-storage - ceph/replication: br-storage - storage: br-storage - private: - transformations: - - action: add-br - name: br-prv - provider: ovs - - action: add-br - name: br-aux - - action: add-patch - bridges: - - br-prv - - br-aux - provider: ovs - mtu: 65000 - - action: add-port - bridge: br-aux - name: <% priv %> - endpoints: - - br-prv - roles: - neutron/private: br-prv - public: - transformations: - - action: add-br - name: br-ex - - action: add-br - name: br-floating - provider: ovs - - action: add-patch - bridges: - - br-floating - - br-ex - provider: ovs - mtu: 65000 - - action: add-port - bridge: br-ex - name: <% pub %> - endpoints: - - br-ex - roles: - public/vip: br-ex - neutron/floating: br-floating - ceph/radosgw: br-ex - ex: br-ex - common: -# In this example, the common template is created for Management and -# Admin networks. - transformations: - - action: add-br - name: br-fw-admin - - action: add-port - bridge: br-fw-admin - name: <% adm %> - - action: add-br - name: br-mgmt - - action: add-port - bridge: br-mgmt - name: <% man %> - endpoints: - - br-fw-admin - - br-mgmt - roles: - admin/pxe: br-fw-admin - fw-admin: br-fw-admin - mongo/db: br-mgmt - management: br-mgmt - keystone/api: br-mgmt - neutron/api: br-mgmt - neutron/mesh: br-mgmt - swift/api: br-mgmt - sahara/api: br-mgmt - ceilometer/api: br-mgmt - cinder/api: br-mgmt - glance/api: br-mgmt - heat/api: br-mgmt - nova/api: br-mgmt - nova/migration: br-mgmt - murano/api: br-mgmt - horizon: br-mgmt - mgmt/api: br-mgmt - mgmt/memcache: br-mgmt - mgmt/database: br-mgmt - mgmt/messaging: br-mgmt - mgmt/corosync: br-mgmt - mgmt/vip: br-mgmt - mgmt/api: br-mgmt - ceph/public: br-mgmt diff --git a/examples/network_templates/one_network.yaml b/examples/network_templates/one_network.yaml deleted file mode 100644 index 289c83314..000000000 --- a/examples/network_templates/one_network.yaml +++ /dev/null @@ -1,85 +0,0 @@ -adv_net_template: - default: - network_assignments: - fuelweb_admin: - ep: br-fw-admin - network_scheme: - common: - endpoints: - - br-fw-admin - roles: - admin/pxe: br-fw-admin - ceilometer/api: br-fw-admin - ceph/public: br-fw-admin - cinder/api: br-fw-admin - fw-admin: br-fw-admin - glance/api: br-fw-admin - heat/api: br-fw-admin - horizon: br-fw-admin - keystone/api: br-fw-admin - management: br-fw-admin - mgmt/corosync: br-fw-admin - mgmt/database: br-fw-admin - mgmt/memcache: br-fw-admin - mgmt/messaging: br-fw-admin - mgmt/vip: br-fw-admin - mongo/db: br-fw-admin - murano/api: br-fw-admin - neutron/api: br-fw-admin - neutron/mesh: br-fw-admin - nova/api: br-fw-admin - nova/migration: br-fw-admin - sahara/api: br-fw-admin - swift/api: br-fw-admin - neutron/private: br-fw-admin - ceph/radosgw: br-fw-admin - ex: br-fw-admin - neutron/floating: br-floating - public/vip: br-fw-admin - ceph/replication: br-fw-admin - cinder/iscsi: br-fw-admin - storage: br-fw-admin - swift/replication: br-fw-admin - swift/public: br-fw-admin - transformations: - - action: add-br - name: br-fw-admin - - action: add-port - bridge: br-fw-admin - name: <% if1 %> - - action: add-br - name: br-aux - - action: add-br - name: br-prv - provider: ovs - - action: add-patch - bridges: - - br-prv - - br-fw-admin - mtu: 65000 - provider: ovs - - action: add-br - name: br-floating - provider: ovs - - action: add-patch - bridges: - - br-floating - - br-fw-admin - mtu: 65000 - provider: ovs - nic_mapping: - default: - if1: eth0 - templates_for_node_role: - cinder: - - common - compute: - - common - controller: - - common - ceph-osd: - - common - mongo: - - common - - diff --git a/examples/network_templates/two_networks.yaml b/examples/network_templates/two_networks.yaml deleted file mode 100644 index fd379836a..000000000 --- a/examples/network_templates/two_networks.yaml +++ /dev/null @@ -1,93 +0,0 @@ -adv_net_template: - default: - network_assignments: - fuelweb_admin: - ep: br-fw-admin - everything: - ep: br-all - network_scheme: - common: - endpoints: - - br-all - - br-fw-admin - roles: - admin/pxe: br-fw-admin - ceilometer/api: br-all - ceph/public: br-all - cinder/api: br-all - fw-admin: br-fw-admin - glance/api: br-all - heat/api: br-all - horizon: br-all - keystone/api: br-all - management: br-all - mgmt/corosync: br-all - mgmt/database: br-all - mgmt/memcache: br-all - mgmt/messaging: br-all - mgmt/vip: br-all - mongo/db: br-all - murano/api: br-all - neutron/api: br-all - neutron/mesh: br-all - nova/api: br-all - nova/migration: br-all - sahara/api: br-all - swift/api: br-all - neutron/private: br-all - ceph/radosgw: br-all - ex: br-all - neutron/floating: br-floating - public/vip: br-all - ceph/replication: br-all - cinder/iscsi: br-all - storage: br-all - swift/replication: br-all - swift/public: br-all - transformations: - - action: add-br - name: br-fw-admin - - action: add-port - bridge: br-fw-admin - name: <% if1 %> - - action: add-br - name: br-all - - action: add-port - bridge: br-all - name: <% if2 %> - - action: add-br - name: br-aux - - action: add-br - name: br-prv - provider: ovs - - action: add-patch - bridges: - - br-prv - - br-all - mtu: 65000 - provider: ovs - - action: add-br - name: br-floating - provider: ovs - - action: add-patch - bridges: - - br-floating - - br-all - mtu: 65000 - provider: ovs - nic_mapping: - default: - if1: eth0 - if2: eth1 - templates_for_node_role: - cinder: - - common - compute: - - common - controller: - - common - ceph-osd: - - common - mongo: - - common - diff --git a/glossary/d.rst b/glossary/d.rst deleted file mode 100644 index 25762902b..000000000 --- a/glossary/d.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. _d: - -= -D -= - -.. toctree:: - :maxdepth: 3 - - d/deployment-graph.rst - d/deployment-graph-hierarchy.rst - d/deployment-graph-rendering.rst - d/deployment-group.rst - d/deployment-group-fault-tolerance.rst - d/deployment-pipeline.rst - d/deployment-role.rst - d/deployment-task.rst - d/discovery.rst \ No newline at end of file diff --git a/glossary/d/deployment-graph-hierarchy.rst b/glossary/d/deployment-graph-hierarchy.rst deleted file mode 100644 index 954a0e370..000000000 --- a/glossary/d/deployment-graph-hierarchy.rst +++ /dev/null @@ -1,11 +0,0 @@ -.. _deployment-graph-hierarchy: - -Deployment graph hierarchy --------------------------- - -A sequence in which Fuel processes the deployment graph classes. -The hierarchy of deployment graph classes includes the following levels: - -* ``release`` -* ``plugin`` -* ``cluster`` \ No newline at end of file diff --git a/glossary/d/deployment-graph-rendering.rst b/glossary/d/deployment-graph-rendering.rst deleted file mode 100644 index f76f1bbcc..000000000 --- a/glossary/d/deployment-graph-rendering.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. deployment-graph-rendering: - -Deployment graph rendering --------------------------- - -The process of compilation of the deployment graph. -The process comprises the assignment of deployment tasks to nodes, -computation of the deployment tasks parameters, and resolution of -the deployment tasks dependencies. \ No newline at end of file diff --git a/glossary/d/deployment-graph.rst b/glossary/d/deployment-graph.rst deleted file mode 100644 index e2997f975..000000000 --- a/glossary/d/deployment-graph.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. _deployment-graph: - -Deployment graph ----------------- - -A collection of deployment tasks with their parameters and dependencies -resolved according to the settings of the current deployment. - -Fuel renders each graph from a three-level hierarchical representation of its -class. For example, for basic deployment, the deployment graph class is -``default``. Fuel builds the deployment graph with respect to the existing -graphs of the default class for plugins as well as for a cluster-specific -graph. \ No newline at end of file diff --git a/glossary/d/deployment-group-fault-tolerance.rst b/glossary/d/deployment-group-fault-tolerance.rst deleted file mode 100644 index 8059324cf..000000000 --- a/glossary/d/deployment-group-fault-tolerance.rst +++ /dev/null @@ -1,8 +0,0 @@ -.. deployment-group-fault-tolerance: - -Deployment group fault tolerance --------------------------------- - -An absolute or relative value for the number of nodes of a deployment group -that can fail. The value is useful for the deployment to succeed when a limited -amount of non-critical nodes fails to deploy. \ No newline at end of file diff --git a/glossary/d/deployment-group.rst b/glossary/d/deployment-group.rst deleted file mode 100644 index 83da0b9ed..000000000 --- a/glossary/d/deployment-group.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. deployment-group: - -Deployment group ----------------- - -A low-level grouping entity which works as an association between -roles and deployment tasks. Fuel associates each group simultaneously with -a role and a set of tasks. One role may be associated with more than one -deployment group and one deployment group may be associated with several -deployment tasks. \ No newline at end of file diff --git a/glossary/d/deployment-pipeline.rst b/glossary/d/deployment-pipeline.rst deleted file mode 100644 index 47fe67f09..000000000 --- a/glossary/d/deployment-pipeline.rst +++ /dev/null @@ -1,25 +0,0 @@ -.. _deployment-pipeline: - -Deployment pipeline -------------------- - -A sequence of data transformations from user-friendly instructions -to the low-level data representation in the form of deployment input -data and deployment graph. - -The deployment pipeline workflow: - -#. Fuel manipulates the input data provided by the user. Data examples: - - * Cluster attributes - * OpenStack release version - * Networking settings - * Huge Pages allocation - -#. Fuel converts the data using a set of serializers. - -#. Using the converted data, Fuel builds a deployment graph. - -#. Fuel passes the deployment graph to a task executor. - -#. The task executor carries out the deployment tasks based on the input data. \ No newline at end of file diff --git a/glossary/d/deployment-role.rst b/glossary/d/deployment-role.rst deleted file mode 100644 index 4e60df9f8..000000000 --- a/glossary/d/deployment-role.rst +++ /dev/null @@ -1,8 +0,0 @@ -.. deployment-role: - -Deployment role ---------------- - -A high-level entity representing the node's profile; for example, a set of -services provided by a node. The examples of a node's profile are -``controller``, ``compute``, ``load-balancer``, ``zabbix``. \ No newline at end of file diff --git a/glossary/d/deployment-task.rst b/glossary/d/deployment-task.rst deleted file mode 100644 index 8a2ffb442..000000000 --- a/glossary/d/deployment-task.rst +++ /dev/null @@ -1,11 +0,0 @@ -.. _deployment-task: - -Deployment task ---------------- - -A unit of execution on a node responsible for the configuration and -installation of a particular piece; for example, keystone, database, -bonding configuration, and so on. - -Each deployment task has a set of parameters which specify how and when Fuel -executes the task. \ No newline at end of file diff --git a/glossary/d/discovery.rst b/glossary/d/discovery.rst deleted file mode 100644 index a608e55ed..000000000 --- a/glossary/d/discovery.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. discovery: - -Discovery ---------- - -The process of discovering a newly booted node for the Fuel purposes of -provisioning and deployment. - -During discovery, the node registers in the Fuel Nailgun service and receives -an identifier required for the deployment and provisioning phase. \ No newline at end of file diff --git a/glossary/e.rst b/glossary/e.rst deleted file mode 100644 index 30dbc91f4..000000000 --- a/glossary/e.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. _e: - -= -E -= - -.. toctree:: - :maxdepth: 3 - - e/environment-release.rst \ No newline at end of file diff --git a/glossary/e/environment-release.rst b/glossary/e/environment-release.rst deleted file mode 100644 index 69ca4c31d..000000000 --- a/glossary/e/environment-release.rst +++ /dev/null @@ -1,12 +0,0 @@ -.. environment-release: - -.. index:: environment, release, Fuel, MOS, MOM, MCP - -Environment release -------------------- - -A set of pre-configured parameters applied to an OpenStack environment -from the ``Release`` template. -The ``Release`` template specifies a set of common attributes such as a -repository list, default list of roles, default node partitioning, networks -allocation, and so on. \ No newline at end of file diff --git a/glossary/glossary.rst b/glossary/glossary.rst deleted file mode 100644 index ba5e451d6..000000000 --- a/glossary/glossary.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. _glossary: - -Glossary -======== - -This glossary is a collection of terms related to OpenStack and Fuel. -The glossary is intended to assist in consistency in usage -of terminology in the Fuel documentation. - -.. toctree:: - :maxdepth: 2 - - d.rst - e.rst - i.rst - n.rst - p.rst - s.rst diff --git a/glossary/i.rst b/glossary/i.rst deleted file mode 100644 index 9b8c205d9..000000000 --- a/glossary/i.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. _i: - -= -I -= - -.. toctree:: - :maxdepth: 3 - - i/inventory.rst \ No newline at end of file diff --git a/glossary/i/inventory.rst b/glossary/i/inventory.rst deleted file mode 100644 index 70673dfbf..000000000 --- a/glossary/i/inventory.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. inventory: - -Inventory ---------- - -The process of collecting specific node data; such as hardware -specification, rack location in the data-center, and so on. - -Fuel Nailgun uses the collected data to calculate the values of -serialized attributes; such as partitioning schema. \ No newline at end of file diff --git a/glossary/n.rst b/glossary/n.rst deleted file mode 100644 index c9fdfb7bd..000000000 --- a/glossary/n.rst +++ /dev/null @@ -1,11 +0,0 @@ -.. _n: - -= -N -= - -.. toctree:: - :maxdepth: 3 - - n/nailgun-extension.rst - n/nailgun-supertask.rst \ No newline at end of file diff --git a/glossary/n/nailgun-extension.rst b/glossary/n/nailgun-extension.rst deleted file mode 100644 index df6eea750..000000000 --- a/glossary/n/nailgun-extension.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. nailgun-extension: - -Nailgun extension ------------------ - -An isolated piece of code that you keep in a separate repository and -plug in and out. The Nailgun extension can introduce additional -API handlers, callbacks and embeds itself into the attributes serialization -pipeline. - -You can use the extensions to integrate into the deployment pipeline -third-party services, such as LDAP or your own configuration management -database. \ No newline at end of file diff --git a/glossary/n/nailgun-supertask.rst b/glossary/n/nailgun-supertask.rst deleted file mode 100644 index 095dbc8de..000000000 --- a/glossary/n/nailgun-supertask.rst +++ /dev/null @@ -1,15 +0,0 @@ -.. _nailgun-supertask: - -Nailgun supertask ------------------ - -An entity of operations with the cluster. The operations can contain several -other transactions, such as provisioning, deployment, network verification, -and so on. - -Each cluster operation represents a Nailgun transaction. -Each transaction may consist of several instances of a deployment pipeline -invocation: data conversion and graph execution. - -.. note:: The transactions cannot be completely rolled back. - The transactions are not true transactions in terms of ACID. \ No newline at end of file diff --git a/glossary/p.rst b/glossary/p.rst deleted file mode 100644 index 8683371f4..000000000 --- a/glossary/p.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. _p: - -= -P -= - -.. toctree:: - :maxdepth: 3 - - p/provisioning.rst \ No newline at end of file diff --git a/glossary/p/provisioning.rst b/glossary/p/provisioning.rst deleted file mode 100644 index 8f52efa7c..000000000 --- a/glossary/p/provisioning.rst +++ /dev/null @@ -1,11 +0,0 @@ -.. provisioning: - -Provisioning ------------- - -The process of setting up a node into a minimal viable state with a -pre-installed operating system and required supporting components. -This process includes partitioning, installation of base system, and -preconfiguration of a minimal amount of services and settings that Fuel -requires to be able to manage this node after rebooting it into the -installed system. \ No newline at end of file diff --git a/glossary/s.rst b/glossary/s.rst deleted file mode 100644 index b42ba2775..000000000 --- a/glossary/s.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. _s: - -= -S -= - -.. toctree:: - :maxdepth: 3 - - s/serialized-attributes.rst \ No newline at end of file diff --git a/glossary/s/serialized-attributes.rst b/glossary/s/serialized-attributes.rst deleted file mode 100644 index 744f75f01..000000000 --- a/glossary/s/serialized-attributes.rst +++ /dev/null @@ -1,17 +0,0 @@ -.. serialized-attributes: - -Serialized attributes ---------------------- - -A large hash of attributes used as input data for deployment tasks. - -Fuel derives the serialized attributes from the user-provided high-level -input. - -Input examples: - -* Common cluster attributes -* Per-node attributes -* Networking configuration -* Node data collected during the inventory phase -* Any third-party configuration \ No newline at end of file diff --git a/index.rst b/index.rst deleted file mode 100644 index df4c36aa6..000000000 --- a/index.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. _contents: - -============================== -Welcome to Fuel Documentation! -============================== - -Fuel is an open-source tool that enables you to easily and quickly -provision multiple OpenStack environments, as well as manage your environments -after deployment. You can install Fuel and deploy your OpenStack environment -on a virtual platform such as Oracle VirtualBox or VMware vSphere for testing -purposes, as well as on bare-metal hardware for production. - -This page provides Fuel developer and user documentation. - -User documentation -~~~~~~~~~~~~~~~~~~ - -Learn how to install and configure Fuel, as well as how to deploy your -OpenStack environments and manage them after deployment. - -.. toctree:: - :maxdepth: 1 - - userdocs/fuel-install-guide - userdocs/fuel-user-guide - userdocs/release-notes - -Developer documentation -~~~~~~~~~~~~~~~~~~~~~~~ - -Learn about Fuel internals, software architecture, and how Fuel components -interact with each other. - -.. toctree:: - :maxdepth: 1 - - devdocs/develop - devdocs/devops - devdocs/buildsystem - devdocs/infra - devdocs/packaging - -Plugin documentation -~~~~~~~~~~~~~~~~~~~~ - -Learn how to develop and work with Fuel plugins - -.. toctree:: - :maxdepth: 1 - - plugindocs/fuel-plugin-sdk-guide - -Glossary -~~~~~~~~ - -Fuel documentation glossary - -.. toctree:: - :maxdepth: 1 - - glossary/glossary.rst \ No newline at end of file diff --git a/make.bat b/make.bat deleted file mode 100644 index 34e9cb2e8..000000000 --- a/make.bat +++ /dev/null @@ -1,199 +0,0 @@ -@ECHO OFF - -REM Command file for Sphinx documentation - -if "%SPHINXBUILD%" == "" ( - set SPHINXBUILD=sphinx-build -) -set BUILDDIR=_build -set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% . -set I18NSPHINXOPTS=%SPHINXOPTS% . -if NOT "%PAPER%" == "" ( - set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS% - set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS% -) - -if "%1" == "" goto help - -if "%1" == "help" ( - :help - echo.Please use `make ^` where ^ 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. 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. pdf to make PDF files - echo. text to make text files - echo. man to make manual pages - echo. texinfo to make Texinfo files - echo. gettext to make PO message catalogs - echo. changes to make an overview over all changed/added/deprecated items - echo. linkcheck to check all external links for integrity - echo. doctest to run all doctests embedded in the documentation if enabled - goto end -) - -if "%1" == "clean" ( - for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i - del /q /s %BUILDDIR%\* - goto end -) - -if "%1" == "html" ( - %SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/html. - goto end -) - -if "%1" == "dirhtml" ( - %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml. - goto end -) - -if "%1" == "singlehtml" ( - %SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml. - goto end -) - -if "%1" == "pickle" ( - %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can process the pickle files. - goto end -) - -if "%1" == "json" ( - %SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can process the JSON files. - goto end -) - -if "%1" == "htmlhelp" ( - %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can run HTML Help Workshop with the ^ -.hhp project file in %BUILDDIR%/htmlhelp. - goto end -) - -if "%1" == "qthelp" ( - %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can run "qcollectiongenerator" with the ^ -.qhcp project file in %BUILDDIR%/qthelp, like this: - echo.^> qcollectiongenerator %BUILDDIR%\qthelp\fuel.qhcp - echo.To view the help file: - echo.^> assistant -collectionFile %BUILDDIR%\qthelp\fuel.ghc - goto end -) - -if "%1" == "devhelp" ( - %SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. - goto end -) - -if "%1" == "epub" ( - %SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The epub file is in %BUILDDIR%/epub. - goto end -) - -if "%1" == "latex" ( - %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; the LaTeX files are in %BUILDDIR%/latex. - goto end -) - -if "%1" == "pdf" ( - %SPHINXBUILD% -bpdf %ALLSPHINXOPTS% %BUILDDIR%/pdf - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; the PDF files are in %BUILDDIR%/pdf. - goto end -) - -if "%1" == "text" ( - %SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The text files are in %BUILDDIR%/text. - goto end -) - -if "%1" == "man" ( - %SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The manual pages are in %BUILDDIR%/man. - goto end -) - -if "%1" == "texinfo" ( - %SPHINXBUILD% -b texinfo %ALLSPHINXOPTS% %BUILDDIR%/texinfo - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The Texinfo files are in %BUILDDIR%/texinfo. - goto end -) - -if "%1" == "gettext" ( - %SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The message catalogs are in %BUILDDIR%/locale. - goto end -) - -if "%1" == "changes" ( - %SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes - if errorlevel 1 exit /b 1 - echo. - echo.The overview file is in %BUILDDIR%/changes. - goto end -) - -if "%1" == "linkcheck" ( - %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck - if errorlevel 1 exit /b 1 - echo. - echo.Link check complete; look for any errors in the above output ^ -or in %BUILDDIR%/linkcheck/output.txt. - goto end -) - -if "%1" == "doctest" ( - %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest - if errorlevel 1 exit /b 1 - echo. - echo.Testing of doctests in the sources finished, look at the ^ -results in %BUILDDIR%/doctest/output.txt. - goto end -) - -:end diff --git a/plugindocs/fuel-plugin-sdk-guide.rst b/plugindocs/fuel-plugin-sdk-guide.rst deleted file mode 100644 index adfbc315c..000000000 --- a/plugindocs/fuel-plugin-sdk-guide.rst +++ /dev/null @@ -1,21 +0,0 @@ -.. index:: Fuel Plugin SDK Guide - -.. _fuel-plugin-sdk-guide: - -===================== -Fuel Plugin SDK Guide -===================== - -.. toctree:: - :maxdepth: 3 - - fuel-plugin-sdk-guide/introduction.rst - fuel-plugin-sdk-guide/how-plugins-work.rst - fuel-plugin-sdk-guide/existing-plugins.rst - fuel-plugin-sdk-guide/create-environment.rst - fuel-plugin-sdk-guide/create-plugin.rst - fuel-plugin-sdk-guide/requirements.rst - fuel-plugin-sdk-guide/limitations.rst - fuel-plugin-sdk-guide/reference.rst - fuel-plugin-sdk-guide/faq.rst - fuel-plugin-sdk-guide/additional-information.rst diff --git a/plugindocs/fuel-plugin-sdk-guide/additional-information.rst b/plugindocs/fuel-plugin-sdk-guide/additional-information.rst deleted file mode 100644 index 12369c4c2..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/additional-information.rst +++ /dev/null @@ -1,23 +0,0 @@ -.. _additional-information: - -Additional information -====================== - -If you have any questions about Fuel plugins, use the openstack-dev -mailing list (use the [fuel][plugins] prefix). For instructions on -the mailing list usage, see the -`openstack-dev `_ -mailing list instructions. - -To file a defect for this document, do the following: - -#. Go to the `Fuel Launchpad project `_. -#. Click :guilabel:`Report a bug.` -#. Put ``[SDK]`` in the :guilabel:`Summary` field and provide a summary - of the defect. -#. Provide a detailed description of the defect in the ticket body. -#. Once you save the bug, tag it with ``area-docs``. - -Use the same procedure to file a bug report for the Fuel plugin framework -itself, just use ``[Fuel plugins]`` instead of ``[SDK]`` in the -:guilabel:`Summary` field. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment.rst deleted file mode 100644 index 741f35449..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. _create-environment: - -Create a development environment -================================ - -To create a development environment, you must: - -* Set up a repository and adhere to the workflow. -* Set up Continuous Integration and Continuous Deployment (CI/CD). -* Set up a testing framework. - -This section includes the following topics: - -.. toctree:: - :maxdepth: 2 - - create-environment/development-requirements.rst - create-environment/code-style.rst - create-environment/repository-workflow.rst - create-environment/repository-branching.rst - create-environment/launchpad-project.rst - create-environment/plugin-repo.rst - create-environment/plugin-ci.rst - create-environment/autotests.rst diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/autotests.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/autotests.rst deleted file mode 100644 index 87c58dbdd..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/autotests.rst +++ /dev/null @@ -1,70 +0,0 @@ -.. _autotests: - -Prepare a testing environment ------------------------------ - -You must configure a testing environment to ensure you plugin code quality. - -Use the following resources to download test, examples, and instructions on -how to configure a testing environment: - -* `Fuel tests `_. -* `Plugin test cases example `_. -* `Instructions on configuring an environment `_. - -Follow these additional guidelines on creating and formating your own tests: - -* When creating your own test class, you must inherit this test class from the - ``TestBasic`` class in ``base_test_case.py``, where the Fuel web client - initialization is performed. -* Each test class and method must be decorated with ``@test``. -* Each class in the test group has groups to run all test cases together - and each test case has groups for a separate run. -* Test cases have the ``depends_on`` method or ``test`` which means that this - test case does not run until the ``depends_on`` method or ``test`` is done. - -**Prepare a testing environment** - -#. Clone the ``fuel-qa`` Git repository: - - .. code-block:: console - - git clone https://github.com/stackforge/fuel-qa - -#. Activate the virtual environment: - - .. code-block:: console - - source ~/venv-nailgun-tests-2.9/bin/activate - -#. Export the Fuel ISO: - - .. code-block:: console - - export ISO_PATH=path-to-iso - -#. Go to ``fuel-qa``: - - .. code-block:: console - - cd fuel-qa/ - -#. Start the tests: - - .. code-block:: console - - ./utils/jenkins/system_tests.sh -t test -w \ - $(pwd) -j fuelweb_test -i $ISO_PATH -o --group=setup - -#. For additional information, type: - - .. code-block:: console - - ./utils/jenkins/system_tests.sh -h - -.. toctree:: - :maxdepth: 3 - :hidden: - - autotests/autotests-workflow.rst - autotests/autotests-files.rst diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/autotests/autotests-files.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/autotests/autotests-files.rst deleted file mode 100644 index a85813ba9..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/autotests/autotests-files.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _autotests-files: - -Automation test files ---------------------- - -Main files and modules: - -* ``system_tests.sh`` - The file where tests start execution. This file processes - the parameters specified from the command line and invokes ``run_tests.py``. -* ``run_tests.py`` - Used to import your test files inside this file to run your - test. -* ``settings.py`` - Contains environment variables used for environment - customization. With this file, you can set such variables as path to ISO, - nodes quantity, etc. -* ``environment.py`` - Contains methods for environment deploying, virtual machines - creation and networking, installation of Fuel on the Fuel Master node, etc. -* ``nailgun_client.py`` - Contains functionality for nailgun handlers, methods and - API that are supported by the nailgun client. The nailgun client uses the - HTTP client that located in the ``helpers`` folder. The nailgun client is - used in the Fuel web client. -* ``checkers.py`` - Has methods for the SSH client to verify nodes access. -* ``common.py`` - Has methods for OpenStack API access, instances creation, etc. -* ``decorators.py`` - Has different decorators; the most usable is - ‘’log_snapshot_on_error’’; it is recommended to use this decorator for all - tests, if any error diagnostic and environment snapshots will be created. -* ``os_actions.py`` - Has methods to work with OpenStack. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/autotests/autotests-workflow.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/autotests/autotests-workflow.rst deleted file mode 100644 index b64bca6df..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/autotests/autotests-workflow.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _autotests-workflow: - -Automation tests execution order --------------------------------- - -#. Base test cases are executed: these are the tests that set up environment - and install the Fuel Master node. -#. After passing these tests, snapshots are created which will be used by - the tests for creating clusters. -#. Revert to the previously created snapshots. -#. Set up the cluster and deploy it. -#. Run OSTF. - -For test execution debugging, use ``dos.py``. - -To create a snapshot, run: - -.. code-block:: console - - dos.py snapshot --snapshot-name= - -To revert a snapshot, run: - -.. code-block:: console - - dos.py revert --snapshot-name= \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/code-style.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/code-style.rst deleted file mode 100644 index ea0f0be41..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/code-style.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. _code-style: - -Install style checkers ----------------------- - -To keep the code readable, reviewable, and maintainable, adhere to the -standardized style of `Puppet `_ -and `Python `_. - -Integrate the code style checkers to your Continuous Integration (CI) workflow. - -**To install a Puppet code style checker:** - -.. code-block:: console - - gem install puppet-lint - puppet-lint --with-context ./myplugin/deployment_scripts - -**To install a Python code style checker:** - -.. code-block:: console - - pip install pep8 - pep8 --show-source --show-pep8 ./myplugin/deployment_scripts \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/development-requirements.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/development-requirements.rst deleted file mode 100644 index 893c597fd..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/development-requirements.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. _development-requirements: - -Development requirements ------------------------- - -Your development environment must meet the following requirements: - -* Provide DEB and RPM packages and the dependencies. For instructions - on creating packages, see `Fedora project wiki `_ - and `Ubuntu Packaging Guide `_. - -* Create Puppet manifests according to the Official OpenStack documentation. - See `Puppet in OpenStack `_. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/launchpad-project.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/launchpad-project.rst deleted file mode 100644 index fdc309ad4..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/launchpad-project.rst +++ /dev/null @@ -1,25 +0,0 @@ -.. _launchpad-project: - -Launchpad project ------------------ - -Launchpad is the bug tracking system that all OpenStack projects, -including Fuel and Fuel plugins, use. You must create a Launchpad -project as described in the official Launchpad documentation and -use it as a single entry point for reporting issues on your plugin -and tracking development progress. - -All Fuel plugins must follow the following conventions: - -* The project name must be in the ``fuel-plugin-`` - format. -* The project page must link to the source plugin repository and its - entry in `DriverLog `_. -* The project teams must incorporate all development team members. -* The milestones must repeat the plugin release specified in the - ``metadata.yaml file``. For example, ``1.0.0``, ``2.0.0``. - -.. seealso:: - - - `List of existing Launchpad projects `_ - - `Launchpad documentation `_ diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-ci.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-ci.rst deleted file mode 100644 index 1924b3870..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-ci.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. _plugin-ci: - -Configure a continuous integration environment ----------------------------------------------- - -Plugin integration requires a Continuous Integration (CI) for testing -and deploying new changes. - -**To configure a continuous integration environment:** - -#. Configure Gerrit integration: - - #. Create and configure a Launchpad user to votie as a third-party - developer. See `Third Party Testing `_. - #. Add the username and public key for the Gerrit plugin configuration - in Jenkins. - #. Send an email to the openstack-dev mailing list and nominate your system - for voting permissions. - -#. Prepare the development and testing environments: - - #. Create a repository as described in :ref:`repository-workflow`. - #. Allocate enough plugin-specific testing labs. - #. Install and configure plugin-specific hardware resources. - #. Confiure testing labs. See the `Fuel development documentation `_. - -#. Configure CI: - - #. Have your own CI server. This - provides better versioning, collecting test-results, deduplicating the - same jobs, easier configuration and managing. - #. Use Jenkins with the `Jenkins Job Builder plugin `_, - which provides easy job management and storage configuration. - #. Install the Jenkins Job Builder from Git as described - below. - #. Create a pre-commit-hook to check your code: - - .. code-block:: console - - #!/bin/bash - # Save this script to /.git/hooks/pre-review - and make it executable - set -e - set -o pipefail - - find . -name '*.pp' | xargs -P1 -L1 puppet parser \ - validate --verbose - find . -name '*.pp' | xargs -P1 -L1 puppet-lint \ - --fail-on-warnings \ - --with-context \ - --with-filename \ - --no-140chars-check \ - --no-variable_scope-check \ - --no-nested_classes_or_defines-check \ - --no-autoloader_layout-check \ - --no-class_inherits_from_params_class-check \ - --no-documentation-check \ - --no-arrow_alignment-check \ - --no-case_without_default-check - find . -name '*.erb' | xargs -P1 -L1 -I '%' \ - erb -P -x -T '-' % | ruby -c - fpb --check ./ - -.. seealso:: - - - :ref:`plugin-ci-job-examples` - -.. toctree:: - :hidden: - - plugin-ci/plugin-ci-workflow.rst - plugin-ci/plugin-ci-job-examples.rst diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-ci/plugin-ci-job-examples.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-ci/plugin-ci-job-examples.rst deleted file mode 100644 index 027a32775..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-ci/plugin-ci-job-examples.rst +++ /dev/null @@ -1,214 +0,0 @@ -.. _plugin-ci-job-examples: - -Job examples ------------- - -The following text is the example of Jenkins jobs at you can create -for plugins. - -* deploy-plugin.sh: - - .. code-block:: console - - #!/bin/bash - set -ex - - export SYSTEM_TESTS="${WORKSPACE}/utils/\ - jenkins/system_tests.sh" - export LOGS_DIR=${WORKSPACE}/logs/\ - ${BUILD_NUMBER} - export VENV_PATH='/home/jenkins/\ - venv-nailgun-tests-2.9' - # Change this to appropriate fuel-qa - # variable for your plugin - YOUR_PLUGIN_PATH="$(ls ./*rpm)" - export YOUR_PLUGIN_PATH - - sh -x "${SYSTEM_TESTS}" -w "${WORKSPACE}" -V \ - "${VENV_PATH}" -i "${ISO_PATH}" -t test -o \ - --group="${TEST_GROUP}" - -* prepare_env.sh: - - .. code-block:: console - - #!/bin/bash - set -ex - - export VENV_PATH="/home/jenkins/\ - venv-nailgun-tests-2.9" - - rm -rf "${VENV_PATH}" - - REQS_PATH="${WORKSPACE}/fuel-qa/\ - fuelweb_test/requirements.txt" - - virtualenv --system-site-packages \ - "${VENV_PATH}" - source "${VENV_PATH}/bin/activate" - pip install -r "${REQS_PATH}" --upgrade - django-admin.py syncdb --settings=devops.\ - settings --noinput - django-admin.py migrate devops --settings\ - =devops.settings --noinput - deactivate - -* syntax-build-plugin.sh: - - .. code-block:: console - - #!/bin/bash - set -ex - - find . -name '*.erb' -print 0 | xargs -0 -P1 \ - -I '%' erb -P -x -T '-' % | ruby -c - find . -name '*.pp' -print 0| xargs -0 -P1 \ - puppet parser validate --verbose - find . -name '*.pp' -print 0| xargs -0 -P1 \ - puppet-lint \ - --fail-on-warnings \ - --with-context \ - --with-filename \ - --no-140chars-check \ - --no-variable_scope-check \ - --no-nested_classes_or_defines-check \ - --no-autoloader_layout-check \ - --no-class_inherits_from_params_class-check \ - --no-documentation-check \ - --no-arrow_alignment-check - - fpb --check ./ - fpb --build ./ - -* plugins.yaml: - - .. code-block:: ini - - - project: - name: plugin_name #Your plugin mame - path_to_fuel_iso: $PWD #Path to FuelISO - plugin_repo: plugin_repo #Your plugin repo name\ - at stackforge - email_to: emails_list #List of emails separated\ - by comma - test_group: test_group #Test group in fuel-qa for\ - deployment tests of your plugin - jobs: - - 'prepare_env' - - '{name}.build' - - '{name}.{dist}.deploy': - dist: 'centos' - - '{name}.{dist}.deploy': - dist: 'ubuntu' - - - job-template: - name: 'prepare_env' - builders: - - shell: - !include-raw-escape './builders/prepare_env.sh' - description: 'Prepare environment to testing' - logrotate: - numToKeep: 10 - parameters: - - string: - name: 'GERRIT_REFSPEC' - default: 'refs/heads/master' - scm: - - git: - branches: - - $GERRIT_BRANCH - refspec: $GERRIT_REFSPEC - url: 'https://review.openstack.org/stackforge\ - /fuel-qa' - choosing-strategy: gerrit - clean: - before: true - publishers: - - email: - notify-every-unstable-build: true - recipients: '{email_to}' - - - job-template: - name: '{name}.build' - builders: - - shell: - !include-raw-escape './builders/syntax-\ - build-plugin.sh' - description: 'Build {name} plugin\ - from fuel-plugins project' - logrotate: - numToKeep: 10 - parameters: - - string: - name: 'GERRIT_REFSPEC' - default: 'refs/heads/master' - scm: - - git: - branches: - - $GERRIT_BRANCH - name: '' - refspec: $GERRIT_REFSPEC - url: 'https://review.openstack.org/\ - stackforge/{plugin_repo}' - choosing-strategy: gerrit - clean: - before: true - triggers: - - gerrit: - trigger-on: - - patchset-created-event #Trigger\ - plugin build for every gerrit patchset - projects: - - project-compare-type: 'PLAIN' - project-pattern: '{plugin_repo}' - branches: - - branch-compare-type: 'ANT' - branch-pattern: '**' - silent: true - server-name: 'review.openstack.org' - publishers: - - archive: - artifacts: '*.rpm' - - email: - notify-every-unstable-build: true - recipients: '{email_to}' - - - job-template: - name: '{name}.{dist}.deploy' - builders: - - copyartifact: - project: '{name}.build' - which-build: last-successful - - inject: - properties-content: | - OPENSTACK_RELEASE={dist} - TEST_GROUP={test_group} - ISO_PATH={path_to_fuel_iso} - - shell: - !include-raw-escape './builders/\ - deploy-plugin.sh' - description: 'fuel-qa system test for {name}' - logrotate: - numToKeep: 10 - parameters: - - string: - name: 'GERRIT_REFSPEC' - default: 'refs/heads/master' - scm: - - git: - branches: - - $GERRIT_BRANCH - refspec: $GERRIT_REFSPEC - url: 'https://review.openstack.org/\ - stackforge/fuel-qa' - choosing-strategy: gerrit - clean: - before: true - wipe-workspace: false - publishers: - - archive: - artifacts: 'logs/$BUILD_NUMBER/*' - - email: - notify-every-unstable-build: true - recipients: '{email_to}' diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-ci/plugin-ci-workflow.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-ci/plugin-ci-workflow.rst deleted file mode 100644 index 0020aaf17..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-ci/plugin-ci-workflow.rst +++ /dev/null @@ -1,50 +0,0 @@ -.. _plugin-ci-workflow: - -CI workflow ------------ - -The Fuel developers team recommends that you follow this CI workflow: - -#. Prepare labs and start or update the lab: - - * Download the ISO from `Fuel CI `_. - Depending on the Fuel version specified in plugin’s requirements, - Jenkins downloads the released ISO and/or the currently developed - and passed BVT test on core CI. - - * Deploy the downloaded ISO and prepare the required labs - for testing using the ``fuel-dev`` and ``fuel-qa`` repositories: - - .. code-block:: console - - $ fuel-main/utils/jenkins/system_tests -t test -j \ - dis_fuelweb_test -i (path to downloaded Fuel-ISO) \ - -o --group=setup -V ${VIRTUAL_ENV} -k - - * Create or restore the required empty VMs from snapshots. - -#. A Gerrit review job starts building your plugin. - See `Gerrit workflow `_. - - #. Use a preconfigured `Gerrit Trigger `_ - to start your job after a new Gerrit patch arrives. - #. Run a code syntax checker and unit tests according to the instructions - from `Testing `_. - #. Run a Puppet linter. See `Puppet OpenStack `_. - #. Build the plugin. - #. Trigger the plugin testing. - -#. Vote on the Gerrit patch page and add review the result in the comment - using Gerrit Trigger. -#. Test the plugin: - - #. Install the plugin. - #. Configure the environment. - #. Deploy the environment with the inactive plugin. - #. Run the OSTF tests. - -#. Run plugin-specific functional tests to check that the current plugin - version provides expected functionality. -#. Publish the resulting aggregated logs to the log storage. - - You can do this by archiving logs. diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-repo.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-repo.rst deleted file mode 100644 index 2ea432079..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-repo.rst +++ /dev/null @@ -1,53 +0,0 @@ -.. _plugin-repo: - -Request an OpenStack repository -------------------------------- - -When you are ready to move your plugin project to a repository -in the OpenStack namespace, request a repository in the Fuel for -OpenStack Launchpad project. - -Before requesting an OpenStack repository, verify that you have -the following: - -* An account in Launchpad. -* A list of members to whom you want to grant the core reviewer - status in your plugin project. -* A list of members to whom you want to grant the release developer - status. - -**To request an OpenStack repository:** - -#. Ensure you are registered with the following resources: -#. Go to the `Fuel project in Launchpad `_. -#. Click :guilabel:`Report a bug`. -#. In :guilabel:`Summary`, type in ``Create a Fuel Plugin project in - /Openstack``. -#. In the :guilabel:`Further information` field put the following details: - - * Plugin name. - * Plugin functionality overview. - * Developer's contact information (email, skype, etc.). - - Ensure that all members to who you want to grant the core reviewer rights - are registered at - ``__. Otherwise, they cannot be granted the - core review status. - - * List of core review developers with contact information: name, email in - ``__. These developers will merge changes. - * List of release developers with contact information: name, email in - ``__. These developers will create release - branches and tags in the repository. - `Example `__. - -#. Click :guilabel:`Extra`. -#. In :guilabel:`Tags`, type ``devops``. - - When the Launchpad ticket is marked ``Fix Committed`` or ``Fix Released``, - your repository is created. - -#. Fill your repository with the required files: - - * Your plugin code. See :ref:`describe-plugin`. - * Documentation. diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-branching.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-branching.rst deleted file mode 100644 index 50369ad19..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-branching.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _repository-branching: - -Managing Git branches ---------------------- - -To track the release cycle efficiently, branch your project or use tags. - -Difference between a branch and a tag: - -* A tag represents a version of a particular branch at a moment in time. -* A branch represents a separate thread of development that may run - concurrently with other development efforts on the same code base. - Changes to a branch may eventually be merged back into another branch - to unify them. - -Examples: - -* For a tagging example, see the `VPNaaS plugin `_ repository. -* For a branching example, see the `LMA plugin `_ repository. - -.. toctree:: - :maxdepth: 3 - :hidden: - - repository-branching/repository-branching-create.rst - repository-branching/repository-branching-delete.rst diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-branching/repository-branching-create.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-branching/repository-branching-create.rst deleted file mode 100644 index ae4e631a7..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-branching/repository-branching-create.rst +++ /dev/null @@ -1,30 +0,0 @@ -.. _repository-branching-create: - -Create a branch ---------------- - -There are two ways to create a branch, using CLI or using the web UI. - -**To create a branch using CLI:** - -.. code-block:: console - - git push : - -Where: - -* ```` is the name of your Gerrit remote or the full remote URL. -* ```` is the refname; this can be a branch or something else. -* ```` is the name of the branch you want created. - -**To create a branch using the web UI:** - -#. Ensure you are a core reviewer. -#. Go to `review.openstack.org `_. -#. In the :guilabel:`Project` menu, click :guilabel:`Branches`. -#. Enter a new branch name and click the :guilabel:`Create branch` button. - You can leave the :guilabel:`Initial revision` field blank. - -.. seealso:: - - - :ref:`repository-branching-delete` \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-branching/repository-branching-delete.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-branching/repository-branching-delete.rst deleted file mode 100644 index c4f3d31ce..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-branching/repository-branching-delete.rst +++ /dev/null @@ -1,22 +0,0 @@ -.. _repository-branching-delete: - -Delete a branch ---------------- - -You may need to delete a branch in OpenStack if you no longer need the branch, -merged that branch with other branch, or dropped the development of the branch - -**To delete a branch:** - -#. Select from the following options: - - * Contact the openstack-infra core team via mailing list. - See `example request `_. - * Report a bug in the `Fuel project `_ and assign - it to Fuel DevOps team. - * Request in #openstack-infra IRC channel on freenode.net. You can contact - the following core members there: fungi, clarkb, jeblair, pleia2. - -.. seealso:: - - - :ref:`repository-branching-create` \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-workflow.rst b/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-workflow.rst deleted file mode 100644 index 165aec5ae..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-environment/repository-workflow.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. _repository-workflow: - -Repository workflow -------------------- - -As a plugin developer, your repository workflow must be the following: - -#. Start your plugin development in your own repository open to public. - The repository can be any public Git hosting; for example, GitHub. - -#. When you are ready to put your developed plugin project to the official - repository in the OpenStack namespace, you need to do the following: - - * Have your code reviewed by the `Fuel team `_. - You can also request a review in the #fuel-dev channel in IRC. You are welcome - to request peer review from the members of your development team. - * Plan to set up a CI for the plugin. See :ref:`plugin-ci`. - * Confirm that you are going to support the plugin for more than one - version of Fuel. - * Confirm that you are releasing your plugin code under the Apache 2.0 - license. - * Confirm your plugin code has no binary files. - * Request repository creation in the OpenStack namespace. - See :ref:`plugin-repo`. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin.rst deleted file mode 100644 index 0b9aa87a7..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin.rst +++ /dev/null @@ -1,28 +0,0 @@ -.. _create-plugin: - -==================== -Create a Fuel plugin -==================== - -To create a Fuel plugin, you must: - -* Install Fuel Plugin Builder on the Fuel Master node. -* Create a plugin. - -This section includes the following topics: - -.. toctree:: - :maxdepth: 3 - - create-plugin/install-plugin-builder.rst - create-plugin/create-auto-plugin.rst - create-plugin/describe-plugin.rst - create-plugin/define-plugin-actions.rst - create-plugin/actions-existing-roles.rst - create-plugin/plugin-settings.rst - create-plugin/plugin-node-roles.rst - create-plugin/plugin-attributes.rst - create-plugin/modify-ui.rst - create-plugin/plugin-repos.rst - create-plugin/add-driverlog.rst - create-plugin/plugin-versioning-system.rst \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/actions-existing-roles.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/actions-existing-roles.rst deleted file mode 100644 index b3e97c57f..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/actions-existing-roles.rst +++ /dev/null @@ -1,256 +0,0 @@ - -.. _actions-existing-roles: - -Actions for existing roles --------------------------- - -The :ref:`deployment_tasks.yaml` file contains tasks that define actions. -The tasks that define actions execute on the existing roles. - -Basic syntax for a task definition: - -.. code-block:: ini - - - id: - type: - groups: [] - required_for: [] - requires: [] - parameters: - : - ... - -.. note:: You can represent the lists in the full form or the abbreviated - form: - - * Full: - - .. code-block:: ini - - keyword: - - value1 - - value2 - - value3 - - * Abbreviated: - - .. code-block:: ini - - keyword: [ value1, value2, value3 ] - -**Examples** - -We will provide examples of tasks that define actions. We will also provide -examples of how to test the tasks. - -We will list possible keyword values for reference. - -Prerequisites - -* A deployed Fuel environment with one controller node and one compute node. -* A plugin enabled in the environment settings. - -You can make live changes to the plugin's deployment tasks, as this is much -faster to test the changes this way rather than do the full environment -reinstallation for every task change. - -.. tip:: Here is how plugin live update works. When a plugin is installed, - its files are in the directory - ``/var/www/nailgun/plugins/`` on the Fuel Master node: - ``plugin root directory`` or ``plugin root``; the definitions of tasks - are in the Nailgun database. - - To quickly change and debug the plugin tasks, edit the files in - the ``/var/www/nailgun/plugins/`` directory without - rebuilding and reinstalling the plugin. Then synchronise the Nailgun - database content with the filesystem with the command - :command:`fuel plugins --sync`. - - You can also update the plugin from one version to a newer one with - the command - :command:`fuel plugins --update `. - In this case you also need to run :command:`fuel plugins --sync` - after that. - - You can also download all task definitions, including the core and - plugins tasks, for the environment with the command - :command:`fuel env --env --deployment-tasks --download` - and verify that your plugin's tasks are present by searching for - the task IDs. - - You can also change the tasks inside this file directly and then - upload it. This way you can change and debug the already existing - core tasks on the Fuel Master node in ``/etc/puppet/modules``, - not related to your plugin, but this is outside of the scope of this - guide. - -To make it simple, we will delete the automatically generated ``tasks.yaml`` -and :ref:`deployment_tasks.yaml` files. We will create a new -:ref:`deployment_tasks.yaml` from scratch. - -Add a task to execute shell commands: - -.. code-block:: ini - - - id: fuel-plugin-example-iotop - type: shell - role: '*' - requires: [post_deployment_start] - required_for: [post_deployment_end] - parameters: - cmd: apt install iotop && echo `date` ' iotop installed' >> - /tmp/post_deployment || echo `date` ' failed to install iotop' - >> /tmp/post_deployment - -Then sync the plugin tasks, execute the newly defined one, and verify the results: - -.. code-block:: console - - # fuel plugins --sync - # fuel node --nodes 1,2 --tasks fuel-plugin-example-iotop - # ssh node-1 "cat /tmp/post_deployment; iotop --version" - Fri May 20 12:48:08 UTC 2016 iotop installed - iotop 0.6 - -.. note:: In the snippet above, the values for the node IDs and the node - name are just examples and they may differ from the ones in your - installation. To find the correct values, use the command - ``fuel nodes``. - -The task in the example executes the shell commands listed in the parameter -``cmd``: the task installs the package iotop on all the nodes in the -environment; or, in our test, in the subset listed after the key '--nodes'. -Pay attention to the parameters ``requires`` and ``required_for``: they define -when exactly during installation the task will run and are required for the -task execution. The task will usually run in the post-deployment stage, but in -our example we forced it to run alone. After the task execution, you can use -the command :command:`iotop` to monitor the I/O on the environment nodes. - -.. note:: If you receive the error message ``400 Client Error: Bad Request - (Problem with loading YAML file /var/www/nailgun/plugins/ - fuel-plugin-example-1.0/deployment_tasks.yaml)``, verify the syntax - of :ref:`deployment_tasks.yaml`. - - The error ``400 Client Error: Bad Request (Tasks fuel-plugin-example - -iotop are not present in deployment graph)`` means that your tasks - failed to synchronise with the Nailgun database or that your plugin - is not enabled for the environment with the nodes that you specified. - - If other issues, check the Astute log on the Fuel Master node at - ``/var/log/docker-logs/astute/astute.log``. Alternatively, check - the :guilabel:`Logs` tab in the Fuel web UI. - -In our example, we used the asterisk '*' as the value for the keyword -``role``. To run the tasks only on particular roles, but not the others, -replace the value with the list of roles on which to run; for example: - -.. code-block:: ini - - role: [ primary-controller, controller, compute] - -.. note:: Use the list even if your task needs to run on only one role; - for example ``role: [compute]``. This will not work: - ``role: compute``. - -.. note:: The roles ``primary-controller`` and ``controller`` are not the - same. The ``controller`` role does not include the - ``primary-controller`` role, so they should be specified explicitly. - -.. note:: While you can run tasks on particular roles, you cannot run tasks on - all roles except a particular role. For example, there is option - to run tasks on all roles except for a compute role. - -Our example task with the commands listed in the cmd parameter is not suitable -for more than two shell commands; but we always can put the commands in -a shell script and call the script instead: - -.. code-block:: ini - - parameters: - cmd: bash install_iotop.sh - -Put the script ``install_iotop.sh`` in the subdirectory ``deployment_scripts`` -in ``plugin root``. If you run the plugin task, the result will be the same as -in the previous case, when we defined all the commands in -:ref:`deployment_tasks.yaml`. - -The mechanism behind this is as follows. Before the plugin task runs, all the -files inside the ``plugin root`` are synced by rsync protocol to the directory -``/etc/fuel/plugins/`` on target nodes. This directory is set as -the default working directory for plugin tasks -- although you can override it -by specifying the explicit ``cwd`` parameter for the task, so the command -:command:`bash install_iotop.sh` will run the script from it. - -Considering that deployment scripts are copied to target nodes before any of -the tasks run, you can skip the step for syncing tasks if you only change the -contents of the deployment scripts in the process of debugging and run the -tasks directly after the changes. - -You can use any script language or executable as long as they can be called -from shell, but Puppet is the most common tool to write Fuel plugins and there -is support for Puppet tasks. - -Let us rewrite the same task using Puppet manifests. - -:ref:`deployment_tasks.yaml`: - -.. code-block:: ini - - - id: fuel-plugin-example-iotop - type: puppet - role: '*' - requires: [post_deployment_start] - required_for: [post_deployment_end] - parameters: - puppet_manifest: puppet/manifests/install_iotop.pp - puppet_modules: puppet/modules:/etc/puppet/modules - -``deployment_scripts/puppet/manifests/install_iotop.pp``: - -.. code-block:: ini - - notice('MODULAR: fuel-plugin-example/iotop') - - package { 'iotop': - ensure => 'installed', - } - -.. note:: All plugin tasks must be idempotent: each plugin task must be able - to run multiple times without changing the results. Puppet manifests - have an inherent advantage of idempotency and this is one of the - reasons to use Puppet for plugin tasks. - -We changed the ``type`` attribute of the deployment task to ``puppet`` and -replaced the ``cmd`` parameter with the two Puppet specific ones: -``puppet_manifest`` and ``puppet_modules``. If you are familiar with Puppet, -these parameters are self-explanatory. The values of the parameters are path -specifications relative to the ``deployment_scripts`` directory in -``plugin root``. Follow the standard Puppet conventions and keep Puppet -manifests in modules in separate subdirectories. In our example we are using -no modules, but in any other not so trivial case it is good to keep the code -modular. The parameter ``puppet_modules`` is required. - -.. note:: Pay attention to the first line of our Puppet manifest: - - .. code-block:: ini - - notice('MODULAR: fuel-plugin-example/iotop') - - This is a convention to start any of your Puppet tasks in a plugin - with the notice statement that starts with a substring ``MODULAR:`` - followed by the name of the plugin and the name of the task itself. - This output is in the Puppet logs. You can find the output in the - :guilabel:`Logs`of the Fuel web UI, at ``/var/log/puppet.log`` on - the Fuel target node, or at - ``/var/log/remote///puppet-apply.log``. This - convention is very helpful for debugging. - -**Related links** - -See also `Deployment Tasks on Fuel Wiki `_. - -.. toctree:: - :maxdepth: 3 - - actions-existing-roles/deployment-stages.rst - actions-existing-roles/skip-core-tasks.rst diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/actions-existing-roles/deployment-stages.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/actions-existing-roles/deployment-stages.rst deleted file mode 100644 index ee5c97593..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/actions-existing-roles/deployment-stages.rst +++ /dev/null @@ -1,127 +0,0 @@ - -.. _deployment-stages: - -Pre- and post-deployment stages -------------------------------- - -Fuel can execute tasks in the pre- or post-deployment stages. - -For information on how to put tasks in a post-deployment stage, see -:ref:`actions-existing-roles`. - -**To put a task in a pre-deployment stage** - -Change the snippet: - -.. code-block:: ini - - requires: [post_deployment_start] - required_for: [post_deployment_end] - -to - -.. code-block:: ini - - requires: [pre_deployment_start] - required_for: [pre_deployment_end] - -.. note:: Fuel defines a number of tasks organised in a graph. Fuel traverses - this graph during deployment; each task from the graph executes in - its turn. See the in-depth description of the process in the - *Modular Architecture* section of *Developer Guide*. - - We will call the tasks that are already defined by Fuel *core tasks*, - as opposed to *plugin tasks*. - - The core tasks execute Puppet manifests from the directory - ``/etc/puppet/modules/osnailyfacter/modular/`` on the target nodes. - The entire ``/etc/puppet`` tree in turn syncs from the Fuel Master - node to target nodes before the deployment. - - If you need to put plugin tasks in a specific position of the graph, - examine the graph and determine the right place for your task. To get - the graph, use the command :command:`fuel graph`. You can get the - plain text representation of the graph in the - `DOT `_ - format using the command - :command:`fuel graph --env 1 --download > graph.gv`. After that you - can generate the picture in the PNG format from it, using the - command :command:`fuel graph --render graph.gv --tred`, ensure you - install additional packages to the Fuel Master node with the - following commands: - - .. code-block:: console - - yum install graphviz - rpm -i https://www.dropbox.com/s/1fyv9p55kslbxkg/\ - python-pygraphviz-1.3-3.rc2.el7-mos1.x86_64.rpm - - The key ``--tred`` is optional, but it forces the graph to be - `transitionally reducted `_, - in other words -- much simpler. - - See a `sample graph generated for Fuel 8.0 Maintenance Update 1 - environment `_. - -**To put a task in a main deployment stage** - -#. Change the keyword ``role`` to ``groups`` -- ensure the singular ``role`` - and the plural ``groups``. The keyword ``groups`` supports the list of - roles on which the task runs as the value, but does not support the - wildcard '*', so it is necessary to specify each role explicitly. - -#. Specify a timeout in the parameters of the task, otherwise it will not run. - -#. The start and the end of the main deployment stage are ``deploy_start`` - and ``deploy_end``. Do not confuse these with ``deployment_start`` and - ``deployment_end``, which are the counterparts for other stages, not the - main stage. - -A working example for the main deployment stage: - -.. code-block:: ini - - - id: fuel-plugin-example-iotop - type: puppet - groups: [primary-controller, controller, compute] - requires: [deploy_start] - required_for: [deploy_end] - parameters: - puppet_manifest: puppet/manifests/install_iotop.pp - puppet_modules: puppet/modules:/etc/puppet/modules - timeout: 720 - -.. note:: For testing purposes, you can run not one task, but a range - of them. To do this, use the following form of the command - :command:`fuel node`: - - .. code-block:: console - - fuel node --node --start \ - --end [ --skip ] - - For example, to make the task run between the main stage's tasks - ``firewall`` and ``hosts``: - - .. code-block:: ini - - - id: fuel-plugin-example-iotop - type: puppet - groups: [compute] - requires: [firewall] - required_for: [hosts] - parameters: - puppet_manifest: puppet/manifests/install_iotop.pp - puppet_modules: puppet/modules:/etc/puppet/modules - timeout: 720 - - To run a range of tasks from ``firewall`` to ``hosts``, skipping - the tasks related to SSL, use the following command: - - .. code-block:: console - - fuel node --node 2 --start firewall --end hosts --skip \ - ssl-add-trust-chain ssl-keys-saving ssl-dns-setup - Started tasks [u'firewall', u'fuel-plugin-example-iotop', - u'hosts'] for nodes nodes [7]. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/actions-existing-roles/skip-core-tasks.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/actions-existing-roles/skip-core-tasks.rst deleted file mode 100644 index 72e44cd6d..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/actions-existing-roles/skip-core-tasks.rst +++ /dev/null @@ -1,25 +0,0 @@ - -.. _skip-core-tasks: - -Skipping core tasks -------------------- - -Core tasks are the tasks defined by Fuel, as opposed to plugin tasks. - -You can disable core tasks from running on target nodes either completely -or to overrun the core tasks with your plugin tasks. - -For example, networking plugins often disable creation of the default -networks, which are usually created by Fuel during deployment. You can -do this by describing the task with the same ID as the existing one and -the type ``skipped``: - -:ref:`deployment_tasks.yaml`: - -.. code-block:: ini - - - id: openstack-network-networks - type: skipped - -.. note:: If you try to redefine a core task by creating a new task with same - ID as the one of the existing, the deployment will fail. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/add-driverlog.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/add-driverlog.rst deleted file mode 100644 index 63ff9c36d..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/add-driverlog.rst +++ /dev/null @@ -1,14 +0,0 @@ - -.. _add-driverlog: - -Add plugin to DriverLog ------------------------ - -The DriverLog project provides information about drivers and plugins to -the OpenStack community. - -To make your plugin visible and engage the community, add the plugin to -the DriverLog project. - -For information on how to add your plugin, see the -`DriverLog wiki page `_. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/create-auto-plugin.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/create-auto-plugin.rst deleted file mode 100644 index dbb49a1c4..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/create-auto-plugin.rst +++ /dev/null @@ -1,128 +0,0 @@ - -.. _create-auto-plugin: - -Create an automatically generated plugin ----------------------------------------- - -The automatically generated plugin is a template for your plugin. - -The automatically generated plugin does the following: - -#. Creates the file ``/tmp/plugin.all`` on all nodes in the environment. -#. Runs the ``deployment_scripts/deploy.sh`` script. This creates the - ``/tmp/fuel-plugin-example file`` on the controllers. -#. Creates a new role ``fuel-plugin-example_role``. - -**To create an automatically generated plugin** - -#. Log into the Fuel Master node. -#. Run: - - .. code-block:: console - - fpb --create fuel-plugin-example - - This will generate the following files: - - +----------------------------------------------+--------------------------------------------------+ - | File | Descrption | - +==============================================+==================================================+ - |``components.yaml`` |Fuel web UI components | - +----------------------------------------------+--------------------------------------------------+ - |``deployment_scripts`` |Directory for the plugin tasks code | - +----------------------------------------------+--------------------------------------------------+ - |``deployment_scripts/deploy.sh`` |Shell script sample | - +----------------------------------------------+--------------------------------------------------+ - |:ref:`deployment_tasks.yaml` |Definition of plugin tasks | - +----------------------------------------------+--------------------------------------------------+ - |:ref:`environment_config.yaml` |Fuel web UI plugin parameters | - +----------------------------------------------+--------------------------------------------------+ - |``fuel-plugin-example-1.0-1.0.0-1.noarch.rpm``|A plugin package created after you build a plugin | - +----------------------------------------------+--------------------------------------------------+ - |``LICENSE`` |Standard Apache 2.0 license file | - +----------------------------------------------+--------------------------------------------------+ - |:ref:`metadata.yaml` |Plugin information | - +----------------------------------------------+--------------------------------------------------+ - |``network_roles.yaml`` |Network roles data | - +----------------------------------------------+--------------------------------------------------+ - |``node_roles.yaml`` |Definition of new node roles created by the plugin| - +----------------------------------------------+--------------------------------------------------+ - |``pre_build_hook`` |Actions to run on plugin build | - +----------------------------------------------+--------------------------------------------------+ - |``README.md`` |Free-form description of plugin | - +----------------------------------------------+--------------------------------------------------+ - |``repositories`` |Directory for plugin specific packages | - +----------------------------------------------+--------------------------------------------------+ - |``repositories/centos`` |Directory for plugin CentOS packages | - +----------------------------------------------+--------------------------------------------------+ - |``repositories/ubuntu`` |Directory for plugin Ubuntu packages | - +----------------------------------------------+--------------------------------------------------+ - |``tasks.yaml`` |Deprecated, use :ref:`deployment_tasks.yaml` | - +----------------------------------------------+--------------------------------------------------+ - |``volumes.yaml`` |Mapping between node roles and volume allocation. | - | |You can also define new volumes and map them to | - | |the new or existing nodes. | - +----------------------------------------------+--------------------------------------------------+ - -#. Build the automatically generated plugin: - - .. code-block:: console - - fpb --build fuel-plugin-example - -#. Copy the plugin to the Fuel Master node. - -#. Deploy a new environment. - -#. Install the plugin: - - .. code-block:: console - - fuel plugins --install - fuel-plugin-example/fuel-plugin-example-1.0-1.0.0-1.noarch.rpm - - The resulting RPM file is what you need to redistribute to the end user. - -.. note:: The RPM file resulting from the :command:`fpb --build` command is - usually all you need to redistribute the plugin to the end user. - But, despite the plugin's package being a standard RPM package, the - user must not install it directly using the RPM CLI tool, because - the nailgun database cannot be updated with the plugin information - this way. The correct method to install Fuel plugins is by using - the :command:`fuel plugins` command. The benefit of distributing in - RPM format is the ability to automatically upgrade plugins using - YUM. Keep in mind that currently Fuel does not support plugin - upgrades from one major version to another. - -After installing the plugin, you can view it in the Fuel web UI on the -:guilabel:`Plugins` tab. - -You can also verify the plugin installation using Fuel CLI: - -.. code-block:: console - - # fuel plugins --list - id | name | version | package_version - ---|---------------------|---------|---------------- - 1 | fuel-plugin-example | 1.0.0 | 4.0.0 - -**To enable the installed plugin** - -#. In the Fuel web UI, click :guilabel:`Other`, then :guilabel:`Settings`. -#. Check the plugin box. - -.. note:: If you can see your plugin in the ``fuel plugins --list`` output, - but not in the Fuel web UI, then your plugin does not support the - installed version of Fuel. Specifically, the plugin does not have - the version of the Fuel Master node in its :ref:`metadata.yaml`. - -.. tip:: By default, all plugin settings are under the group 'Other'. To place - your plugin settings to a different group, specify it - in :ref:`environment_config.yaml`. - -.. tip:: Tip: Although you can see the plugin settings in the deployed - environment after installation, you cannot enable the plugin. - Enabling a plugin after deployment makes sense only in one case: - when this adds a new node role and a node with this role can be - added after the environment is deployed. In this case use the keyword - ``is_hotppluggable`` in :ref:`metadata.yaml`. diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/define-plugin-actions.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/define-plugin-actions.rst deleted file mode 100644 index 16139c4f0..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/define-plugin-actions.rst +++ /dev/null @@ -1,34 +0,0 @@ - -.. _define-plugin-actions: - -Define plugin actions ---------------------- - -All actions that a plugin can execute fall into the following categories: - -* Actions for the existing roles -- all nodes have one or more roles - associated with them; for example, controller or compute. You can - change the deployment process for the roles defined by Fuel or add - new actions for these roles. - -* Actions for plugin specific roles -- you can create a new role; for - example, if you want to deploy a product that runs on the nodes separate - from the ones running the OpenStack services deployed by Fuel, - and define all the actions that should be executed on such nodes. - -* Actions executed on the Fuel Master node -- you can change the Fuel Master - node. Generally this is not recommended, as you may accidentally affect - the environments on which the user does not want the plugin to be enabled. - There are options to do this. - -.. note:: There are two files with the definitions of plugin actions: - ``tasks.yaml`` and :ref:`deployment_tasks.yaml`. - The ``tasks.yaml`` file is deprecated and can only contain - definitions of tasks in the outdated format used in Fuel 6.0. - You can only describe the pre- and post-deployment tasks using - the old format. - The file :ref:`deployment_tasks.yaml` can contain tasks in the same old - format, but also tasks in the new format, which supports the main - deployment tasks and task dependencies. - Use :ref:`deployment_tasks.yaml` and only the new format for all task - definitions. diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/describe-plugin.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/describe-plugin.rst deleted file mode 100644 index aced6a4fc..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/describe-plugin.rst +++ /dev/null @@ -1,111 +0,0 @@ - -.. _describe-plugin: - -Describe your plugin --------------------- - -The Fuel Plugin Builder generates three files: - -* LICENSE -- free-form information file. -* README.md -- free-form information file. -* :ref:`metadata.yaml` -- mandatory file in YAML format. Your plugin cannot - build without :ref:`metadata.yaml`. - -.. note:: You can put any files -- even the ones not directly related to - Fuel Plugin Builder -- in the plugin directory. Fuel Plugin Builder - will add all the files to the plugin package. - -**To describe your plugin** - -#. Edit the ``LICENSE`` file so that it contains the license, under which - your plugin can be redistributed. You may want to use the - `Apache 2.0 `_ license. - All plugin files that provide intellectual property must have a respective - copyright. - -#. Edit the ``README.md`` file -- put some free-form description of the plugin - here. Describe the purpose of your plugin and give instructions on the - installation. If you publish the code of your plugin on GitHub, the contents - of this file will be on the main page of the repository. You can use - MarkDown formatting in the file. For more information see - `Getting started with writing on GitHub `_. Good examples of plugin description: - `Mellanox `_ - and `LMA Collector `_. - -#. Edit the ``metadata.yaml`` file with the list of required parameters: - - * ``name`` -- Name of the plugin that will be in the plugin's RPM file name. - The allowed name characters are lowercase letters, dash ``-``, and - underscore ``_``. - * ``title`` -- Human-readable plugin name displayed on the Fuel web UI. - * ``version`` -- Plugin version. For guidelines, see :ref:`plugin_versioning_system`. - * ``licenses`` -- List the licenses under which your plugin can be - distributed. - * ``authors`` -- Name of the plugin author. A company or an individual. - * ``homepage`` -- A link to page with your plugin. This can be your plugin's - GitHub repository page. - * ``is_hotpluggable`` -- State if the plugin is hot-pluggable. - See :ref:`plugin-hotpluggable`. - * ``groups`` -- A group to which your plugin belongs in the Fuel web UI. - * ``releases`` -- A list of OpenStack releases compatible with the plugin. - - * ``release_name:`` -- Name of the release. - * ``description:`` -- Description of the release. - * ``releases: os`` -- A compatible Linux distribution for the plugin. - The supported values are ``ubuntu`` and ``centos``. Fuel 8.0 supports - only Ubuntu. - * ``version`` -- A compatible OpenStack release version. - * ``is_release:`` -- Must be set to ``true`` for plugins that define - releases: ``is_release: true``. - * ``releases: mode`` -- A list of compatible cluster deployment modes. - Fuel 8.0 supports only the ``haz`` value. - * ``releases: deployment_scripts_path`` -- A path in your plugin directory - where all the deployment scripts for the release are. The path is - relative to the plugin root. - * ``releases: repository_path`` -- A path in your plugin directory where - all the packages for the release are. Relative to the plugin root. - * ``base_release_path`` -- Defines the template from which to inherit - the data tree by overriding keys. - * ``networks_path`` -- Path to the ``networks.yaml`` file. - * ``volumes_path`` -- Path to the ``volumes.yaml`` file. - * ``roles_path`` -- Path to the ``roles.yaml`` file. - * ``network_roles_path`` -- Path to the ``network_roles.yaml`` file. - * ``components_path`` -- Path to the ``components.yaml`` file. - * ``attributes_path`` -- Path to the ``attributes.yaml`` file. - * ``vmware_attributes_path`` -- Path to the ``vmware.yaml`` file. - * ``node_attributes_path`` -- Path to the ``node.yaml`` file. - * ``nic_attributes_path`` -- Path to the ``nic.yaml`` file. - * ``bond_attributes_path`` -- Path to the ``bond.yaml`` file. - * ``graphs`` -- Graph types: - - * ``type: default`` and ``tasks_path`` -- Path to the - ``deployment_graph.yaml`` file. - * ``type: provisioning`` and ``tasks_path`` -- Path to - the ``provisioning_graph.yaml`` file. - * ``type: deletion`` and ``tasks_path`` -- Path to the - ``deletion_graph.yaml`` file. - * ``type: network_verification`` and ``tasks_path`` -- - Path to the ``network_verification_graph.yaml`` file. - * ``deployment_scripts_path`` -- Path to the deployment scripts for the - release. - * ``repository_path`` -- Path to the repositories. - - * ``package_version`` -- A version of the compatible plugin format. - To build your plugin, the Fuel Plugin Builder version must be the same - as the version of the compatible plugin format or newer. Each new plugin - format version introduces new features and, possibly, deprecates some of - the old ones. The Fuel master node must support the specific - ``package_version``, otherwise, you cannot install the plugin. - * ``build_version`` -- A version of the build that allows to iterate the - package version without updating the plugin version. You can specify - a value in any format, such as timestamp and so on. If the value is empty, - fpb adds "1" at the end of the plugin's output file name. For example, - ``plugin-x.x-x.x.x-1.rpm``. - - See the `metadata.yaml example `_. - -We recommend that you create a directory ``doc`` in your plugin root -directory and put extensive documentation there. - -You can find more information about preparing documentation for Fuel plugins -on `GitHub `_. diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/install-plugin-builder.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/install-plugin-builder.rst deleted file mode 100644 index 42ce2c6c6..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/install-plugin-builder.rst +++ /dev/null @@ -1,70 +0,0 @@ - -.. _install-plugin-builder: - -Install Fuel Plugin Builder ---------------------------- - -You must install the Fuel Plugin Builder on the Fuel Master node. -You must use the Fuel Master node as the build environment. - -**To install the Fuel Plugin Builder** - -#. Log into the Fuel Master node. -#. Install the required packages: - - .. code-block:: console - - yum install -y git python-mako createrepo dpkg-devel dpkg-dev rpm \ - rpm-build - -#. Clone the Fuel Plugin Builder repository: - - .. code-block:: console - - git clone https://github.com/openstack/fuel-plugins - -#. Change to the ``fuel-plugins`` directory: - - .. code-block:: console - - cd fuel-plugins - -#. Check out a specific commit from the Fuel Plugin Builder repository - compatible with Fuel 8.0: - - .. code-block:: console - - git checkout a22bc32 - - The ``tasks.yaml`` file is required for the plugin to build, even if - the file is empty. - - .. note:: If the plugin metadata does not specify the same version of - OpenStack as the one supported by the Fuel Master node, - on which the plugin is installed, you will not see any - plugin fields in the Fuel web UI. To be compatible with Fuel 8.0, - the :ref:`metadata.yaml` file of the plugin must contain the - following lines: - - .. code-block:: ini - - releases: - - os: ubuntu - version: liberty-8.0 - mode: ['ha'] - -#. Build and install the Fuel Plugin Builder: - - .. code-block:: console - - python setup.py install - -#. Verify the installed version of the Fuel Plugin Builder: - - .. code-block:: console - - python -c 'import pkg_resources; - print pkg_resources.get_distribution\ - ("fuel-plugin-builder").version' - - This should display ``4.0.0``. diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/modify-ui.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/modify-ui.rst deleted file mode 100644 index 611c012cc..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/modify-ui.rst +++ /dev/null @@ -1,113 +0,0 @@ -.. _modify-ui: - -====================== -Modify the Fuel web UI -====================== - -The Fuel web UI provides the ability to quickly choose which components -to enable for a new environment. - -Fuel has a `significant number of predefined components `_. -Plugins add their own plugin-specific components. - -Each of the components can be marked as compatible, incompatible, or required -in relation to any other component. This allows a user to choose a high-level -set of enabled features for a new cloud without worrying about incompatibility -issues. - -A plugin defines relationship between its own and any arbitrary components -by specifying them in the file ``components.yaml``. The automatically -generated plugin contains only a very basic ``components.yaml`` that -describes one component without defining any inter-component relationships: - -.. code-block:: ini - - - name: additional_service:fuel-plugin-example - compatible: [] - requires: [] - incompatible: [] - label: "Plugin label, that will be shown on UI" - description: "Component description (optional)" - -A new component appears on the :guilabel:`Additional Services` tab with -a tooltip that displays information if the component was tested with the -components selected previously. - -By default, the only effect of enabling any component associated with a -plugin is that the plugin will be enabled in the environment settings -after the Fuel web UI wizard completion. - -**To change ``components.yaml``** - -#. Modify the ``components.yaml`` file. -#. Synchronise with the :command:`fuel plugins --sync` command. -#. Create a new environment to test the Fuel web UI wizard. - -Example of an edited ``components.yaml`` file: - -.. code-block:: ini - - - name: additional_service:fuel-plugin-example - bind: !!pairs - - settings:common.use_cow_images.value: false - - settings:storage.osd_pool_size.value: 2 - compatible: - - name: hypervisor:qemu - - name: storage:block:ceph - - name: storage:ephemeral:ceph - requires: - - name: storage:block:ceph - message: "Example component requires Ceph as a storage - backend" - - name: storage:ephemeral:ceph - message: "Example component requires Ceph as an - ephemeral storage backend" - incompatible: - - name: network:neutron:ml2:vlan - message: "Example component is incompatible with VLAN segmentation" - label: "Example plugin component" - description: "Just an example of a plugin component" - -The property ``weight`` defines a relative placement of the component in the -wizard, which is the same with roles and settings definitions. This example -ensures that the component shows at the top of the list. See -`weight examples `_. - -The property ``bind`` defines the settings that must be set if the component -is enabled. To set specific values, do not use the form ``bind: !!pairs`` as -in the example. -The example ensures that enabling the component uses raw format for the images -instead of qcow and cepho object replication factor setting to ``2``, while -the default is ``3``. - -The property ``compatible`` has the list of components tested with the plugin. -If some of the components do not specify any other component as compatible, -then both will have a warning icon next to them in the Fuel web UI, and a -tooltip will provide a list of components with an unspecified compatibility -status on a mouseover. - -The property ``requires`` specifies components that must be enabled for this -one to be available. In the example, the user will not be able to select -the component without enabling Ceph for block and ephemeral storage. - -You should always provide an appropriate value for ``message`` so that the -user can troubleshoot component enabling with proper tooltip message. - -The property ``incompatible`` is the opposite of ``incompatible``. This property -defines the components that cannot be enabled with this component. -In the example, the incompatible component is ``VLAN segmentation``. - -The properties ``label`` and ``description`` are self-explanatory. - -.. note:: Currently, there is no association between the settings bound - to incompatible or required components and the settings that - restrict each other using the mechanism described in - :ref:`settings-restrictions`. This means that the user can manually - choose some settings that enable features of an incompatible - component after the wizard is finished. Plugin developers should not - only specify incompatible components but also provide appropriate - restrictions for the incompatible settings. - -See `components.yaml `_ -and `environment_config.yaml `_ -from the Fuel XenServer plugin as an example. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-attributes.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-attributes.rst deleted file mode 100644 index 55e00504e..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-attributes.rst +++ /dev/null @@ -1,70 +0,0 @@ - -.. _plugin-attributes: - -Additional attributes for NICs, bonds, and nodes ------------------------------------------------- - -You can provide additional attributes for NICs, bonds, and nodes. This is -useful for a plugin providing "per interface" or "per node" technology. - -An example of this use case is virtual functions support for vRouter on -each network interface in Contrail. - -**To provide additional attributes for NICs:** - -Edit the ``nic_attributes.yaml`` file with the additional attributes. - -**Example:** - -.. code-block:: yaml - - attribute_a: - label: "NIC attribute A" - description: "Your description" - type: "text" - value: "" - attribute_b: - label: "NIC attribute B" - description: "Your description" - type: "checkbox" - value: false - -**To provide additional attributes for bonds:** - -Edit the ``bond_attributes.yaml`` file with the additional attributes. - -**Example:** - -.. code-block:: yaml - - attribute_a: - label: "Bond attribute A" - description: "Your description" - type: "text" - value: "" - attribute_b: - label: "Bond attribute B" - description: "Your description" - type: "checkbox" - value: false - -**To provide additional attributes for nodes:** - -Edit the ``node_attributes.yaml`` file with the additional attributes. - -**Example:** - -.. code-block:: yaml - - plugin_section_a: - metadata: - group: "your_new_section" - label: "Section A" - attribute_a: - label: "Node attribute A for section A" - description: "Your description" - type: "text" - attribute_b: - label: "Node attribute B for section A" - description: "Your description" - type: "checkbox" \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles.rst deleted file mode 100644 index 1aa32ae8b..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. _plugin-node-roles: - -========================== -Plugin specific node roles -========================== - -Defining a new role allows you to explicitly define all the tasks that run on -it. - -Defining a new role is convenient if you need to run some services on -separate nodes: - -* If you deploy a service with some specific hardware or security - requirements. - -* If your software conflicts with some of the packages installed on - the existing roles - -* If the tasks that you execute conflict with the existing tasks. - -.. toctree:: - :maxdepth: 3 - - plugin-node-roles/define-new-role.rst - plugin-node-roles/volume-allocation.rst - plugin-node-roles/hot-pluggable.rst - plugin-node-roles/modify-ui-wizard.rst \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/define-new-role.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/define-new-role.rst deleted file mode 100644 index 70b0713a3..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/define-new-role.rst +++ /dev/null @@ -1,136 +0,0 @@ - -.. _define-new-role: - -Define a new role ------------------ - -You must define a new role in ``node_roles.yaml``. - -The automatically generated plugin contains one example role in the file, -but you can delete the contents of the file and start with a new role: - -.. code-block:: ini - - fuel-plugin-example_role: - name: Example plugin role - description: Just a test role - weight: 1000 - -The only required field besides the ID here is ``name``, but this is always -a good idea to provide some description of the role's purpose. The parameter -``weight`` defines relative placement of the role in the list of roles in the -Fuel web UI. Standard roles have weights from 10 to 100, with the weight 1000 -your role will appear at the end of the list. You can look up the exact values -as well as the definitions for the standard roles at -`openstack.yaml on GitHub `_ . - -Like plugin tasks and unlike plugin settings, role definitions are affected by -the :command:`fuel --sync`` command and can be easily updated. - -To verify that your new role is defined and can be assigned to new nodes use -the button :guilabel:`Add nodes` in the :guilabel:`Nodes` UI tab: -url ``http://:8000/#cluster//nodes/add``. - -.. note:: Keep in mind that a plugin should be enabled for its roles to appear - in the Fuel web UI. - -You must define a new group for the tasks that belong to the new role in -:ref:`deployment_tasks.yaml`: - -.. code-block:: ini - - - id: fuel-plugin-example_role - type: group - role: [fuel-plugin-example_role] - tasks: [globals] - parameters: - strategy: - type: parallel - -The ID of the group must be the same as the ID of the new role. You define -the list of the core tasks, which run on the new role, in the field ``tasks``. -The parameter ``strategy`` is required and it defines how the deployment -should proceed if there are multiple nodes to be deployed with the role. - -The possible values for ``strategy`` are: - -* ``one-by-one`` -- all the nodes with the role will be deployed - sequentially, one after another - -* ``parallel`` -- nodes will be deployed in parallel, at the same time - -.. note:: Fuel 8.0 Maintenance Update 1 runs hooks on the target nodes with - a new role even if you defined no tasks for the role. One of such - hooks creates the file ``/etc/hosts`` on targets and it will fail - with the error ``Could not find data item node_name_prefix_for_ - messaging in any Hiera data file and no default supplied at - /etc/puppet/modules/osnailyfacter/modular/hosts/hosts.pp:6`` - if the task ``globals`` was not run before it. You should always add - ``globals`` or the one that depends on it in the list of the tasks - for a new role; the task ``global``, in turn, depends on tasks - ``hiera``, ``setup_repostories``, and ``fuel_pkgs``, which provide - some basic configuration of the node: for example, the ``hiera`` - task configures hiera, so all of the settings defined via the Fuel - web UI are available through hiera. - -The next step after determining core tasks that should be run on your role, -will be to define plugin tasks and the process is the same as the one that -described in :ref:`actions-existing-roles`. The only difference is that you -will use the ID of the new role in the task definition: - -.. code-block:: ini - - - id: fuel-plugin-example-iotop - type: puppet - role: [fuel-plugin-example_role] - requires: [post_deployment_start] - required_for: [post_deployment_end] - parameters: - puppet_manifest: puppet/manifests/install_iotop.pp - puppet_modules: puppet/modules:/etc/puppet/modules - -The difference between the deployment of the nodes with the new role and the -pre-existing ones is that only the core tasks that you explicitly defined in -the tasks field of the role's group definition will run on the node with the -new role, while there is a predefined list of core tasks to run on the nodes -with pre-existing roles. - -.. tip:: For debugging purposes, deploy the environment consisting only of - the node with the role defined by a plugin. By default, you cannot - deploy an environment without a controller from the Fuel web UI, so - here is an example showing how to do this with the help of Fuel CLI: - - .. code-block:: console - - # fuel env create --name test-plugin-role-1 --rel 2 - Environment 'test-plugin-role-1' with id=3 was created! - # id=`fuel env | grep test-plugin-role-1 | tr -d ' ' \ - |cut -d\| -f1` - # fuel --env $id settings download - # awk -F: 'BEGIN {OFS = FS} $1 ~ "fuel-plugin-example" \ - { f=1 } f && $1 ~ "enabled" { f=0; $2=" true"} \ - { print } ' settings_${id}.yaml > tmp && mv \ - tmp settings_${id}.yaml - # fuel --env $id settings upload - # fuel --env $id node set --node 10 --role - fuel-plugin-example_role - Nodes [10] with roles ['fuel-plugin-example_role'] were added - to environment 3 - # fuel --env $id deploy-changes - - This example does the following: - - * Creates a new environment. - * Downloads the settings. - * Changes the plugin to be enabled in the settings by changing the - plugin ``enabled`` parameter from ``false`` to ``true`` through - AWK. - * Uploads the settings back to the Nailgun database. - * Adds a new node with the role ``fuel-plugin-example_role`` to the - environment. - * Deploys this new environment consisting only of one node with the - new role. - - You can create a new environment, enable the plugin in it, and add - a single node with the new role from the Fuel web UI, using only the - last command to deploy the environment then. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/hot-pluggable.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/hot-pluggable.rst deleted file mode 100644 index 07f852d97..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/hot-pluggable.rst +++ /dev/null @@ -1,41 +0,0 @@ - -.. _plugin-hotpluggable: - -Hot-pluggable plugins ---------------------- - -The hot-pluggable plugins do not affect the core deployment and can be -installed on existing environments. Another term for hot-pluggable plugins -is application-level plugins. - -The following are characteristics of a hot-pluggable plugin: - -* Provides new applications. -* Installs applications on a new node. -* Does not affect existing services or applications. -* Does not override existing tasks. - -Example of hot-pluggable plugins: - -* `Dynatrace `_ -* `LMA Collector `_ - -Compare these to the plugins that affect Fuel core functionality, such as SDN -or storage plugins. These plugins can only be installed before deploying an -environment. - -Defining tasks for existing roles in a hot-pluggable plugin executes these -tasks with the corresponding roles if these nodes are installed after the -plugin is enabled. This option, however, is error-prone, as you cannot -differentiate between the nodes deployed before and after the plugin is -enabled. In this case, nodes have the same role but different functionality. - -The recommended use case for a hot-pluggable plugin is to add a node with a -plugin-specific role to an already existing environment. - -An application-level plugin must have the ``is_hotpluggable`` attribute -set to ``true`` in the :ref:`metadata.yaml` file: - -.. code-block:: ini - - is_hotpluggable: true \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/modify-ui-wizard.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/modify-ui-wizard.rst deleted file mode 100644 index c5e1b6c32..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/modify-ui-wizard.rst +++ /dev/null @@ -1,113 +0,0 @@ -.. _edit-ui-wizard: - -============================= -Modify the Fuel web UI wizard -============================= - -The Fuel web UI provides the ability to quickly choose which components -to enable for a new environment. - -Fuel has a `significant number of predefined components `_. -Plugins add their own plugin-specific components. - -Each of the components can be marked as compatible, incompatible, or required -in relation to any other component. This allows a user to choose a high-level -set of enabled features for a new cloud without worrying about incompatibility -issues. - -A plugin defines relationship between its own and any arbitrary components -by specifying them in the file ``components.yaml``. The automatically -generated plugin contains only a very basic ``components.yaml`` that -describes one component without defining any inter-component relationships: - -.. code-block:: ini - - - name: additional_service:fuel-plugin-example - compatible: [] - requires: [] - incompatible: [] - label: "Plugin label, that will be shown on UI" - description: "Component description (optional)" - -A new component appears on the :guilabel:`Additional Services` tab with -a tooltip that displays information if the component was tested with the -components selected previously. - -By default, the only effect of enabling any component associated with a -plugin is that the plugin will be enabled in the environment settings -after the Fuel web UI wizard completion. - -**To change ``components.yaml``** - -#. Modify the ``components.yaml`` file. -#. Synchronise with the :command:`fuel plugins --sync` command. -#. Create a new environment to test the Fuel web UI wizard. - -Example of an edited ``components.yaml`` file: - -.. code-block:: ini - - - name: additional_service:fuel-plugin-example - bind: !!pairs - - settings:common.use_cow_images.value: false - - settings:storage.osd_pool_size.value: 2 - compatible: - - name: hypervisor:qemu - - name: storage:block:ceph - - name: storage:ephemeral:ceph - requires: - - name: storage:block:ceph - message: "Example component requires Ceph as a storage - backend" - - name: storage:ephemeral:ceph - message: "Example component requires Ceph as an - ephemeral storage backend" - incompatible: - - name: network:neutron:ml2:vlan - message: "Example component is incompatible with VLAN segmentation" - label: "Example plugin component" - description: "Just an example of a plugin component" - -The property ``weight`` defines a relative placement of the component in the -wizard, which is the same with roles and settings definitions. This example -ensures that the component shows at the top of the list. See -`weight examples `_. - -The property ``bind`` defines the settings that must be set if the component -is enabled. To set specific values, do not use the form ``bind: !!pairs`` as -in the example. -The example ensures that enabling the component uses raw format for the images -instead of qcow and cepho object replication factor setting to ``2``, while -the default is ``3``. - -The property ``compatible`` has the list of components tested with the plugin. -If some of the components do not specify any other component as compatible, -then both will have a warning icon next to them in the Fuel web UI, and a -tooltip will provide a list of components with an unspecified compatibility -status on a mouseover. - -The property ``requires`` specifies components that must be enabled for this -one to be available. In the example, the user will not be able to select -the component without enabling Ceph for block and ephemeral storage. - -You should always provide an appropriate value for ``message`` so that the -user can troubleshoot component enabling with proper tooltip message. - -The property ``incompatible`` is the opposite of ``incompatible``. This property -defines the components that cannot be enabled with this component. -In the example, the incompatible component is ``VLAN segmentation``. - -The properties ``label`` and ``description`` are self-explanatory. - -.. note:: Currently, there is no association between the settings bound - to incompatible or required components and the settings that - restrict each other using the mechanism described in - :ref:`settings-restrictions`. This means that the user can manually - choose some settings that enable features of an incompatible - component after the wizard is finished. Plugin developers should not - only specify incompatible components but also provide appropriate - restrictions for the incompatible settings. - -See `components.yaml `_ -and `environment_config.yaml `_ -from the Fuel XenServer plugin as an example. diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/volume-allocation.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/volume-allocation.rst deleted file mode 100644 index d34cc105b..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-node-roles/volume-allocation.rst +++ /dev/null @@ -1,143 +0,0 @@ -.. _volume-allocation: - -Volume allocation ------------------ - -Fuel defines a set of rules for existing roles. The rules determine disk space -usage on the nodes with the specified role. Fuel partitions the disk drives -assigned to the node in accordance with these rules. - -Using the Fuel web UI, you can also tweak the disk size for a predetermined -partition on the node before the deployment. - -The plugin framework allows you to change the predefined rules and to specify -new rules for the plugin-specific roles using the file ``volumes.yaml`` in the -plugin root directory. - -The syntax of the ``volumes.yaml`` file follows the same conventions used to -define volumes for the standard Fuel roles. For reference, -see :ref:`Creating Partitions on Nodes` and -`an example of partitioning rules `_. - -.. note:: The plugin framework only allows changing disk partitioning to - an extent; you can always use some of a plugin's tasks to partition - disks with a sophisticated scheme. The main purpose of specifying - partitions with definitions in ``volumes.yaml`` is to allow - interactive resizing of partitions, which are defined by the plugin, - from the Fuel web UI before environment deployment. - -There are two primary use cases with ``volumes.yaml``: - -* Defining the disk allocation for a new role. -* Redefining the disk allocation for the existing role. - -**Define disk allocation for a new role** - -An example of an automatically generated ``volumes.yaml``: - -.. code-block:: ini - - volumes_roles_mapping: - # Default role mapping - fuel-plugin-example_role: - - {allocate_size: "all", id: "os"} - - # Set here new volumes for your role - volumes: [] - -The two sections are: - -* ``volumes_roles_mapping`` -- defines which volumes the nodes with the - given role will contain; the volumes are Fuel-defined and plugin-specific. - In the given example, there is only one rule: all the disk size is assigned - to one volume named ``"os"``. This is also the default rule, which means that - even if you define a new role but do not provide volume mapping for it, - it will be used implicitly. - -* ``volumes`` -- contains the definition of plugin-specific volumes. In the - given example, there are no plugin-specific volumes defined. - -To assign a minimal size to the OS VG and create a raw partition on all of -the remaining space: - -#. Edit ``volumes.yaml``: - - .. code-block:: ini - - volumes_roles_mapping: - fuel-plugin-example_role: - - {allocate_size: "min", id: "os"} - - {allocate_size: "all", id: "fuel-plugin-example-raw_partition"} - - volumes: - - id: fuel-plugin-example-raw_partition - type: partition - min_size: - generator: calc_gb_to_mb - generator_args: [10] - label: "Example Plugin raw partition" - mount: none - disk_label: "example" - file_system: none - -#. Synchronize the edited ``volumes.yaml`` using :command:`fuel plugins --sync`. -#. In the Fuel web UI, add a new node with the plugin's role. - -.. note:: The definitions in ``volumes.yaml`` are not retroactive. The - definitions will affect only the nodes created after - synchronization. The nodes created before synchronization - keep their previous disk partitioning. - -**Redefine disk allocation for an existing role** - -An example of adding two plugin-specific volume groups to the standard -controller role: - -.. code-block:: ini - - volumes_roles_mapping: - compute: - - {allocate_size: "min", id: "os"} - - {allocate_size: "all", id: "vm"} - - {allocate_size: "min", id: "example1"} - - {allocate_size: "min", id: "example2"} - - # Set here new volumes for your role - volumes: - - id: "example1" - type: "vg" - min_size: - generator: "calc_gb_to_mb" - generator_args: [5] - label: "Example 1" - volumes: - - mount: "/example1" - type: "lv" - name: "example1" - size: - generator: "calc_total_vg" - generator_args: ["example1"] - file_system: "ext4" - - id: "example2" - type: "vg" - min_size: - generator: "calc_gb_to_mb" - generator_args: [10] - label: "Example 2" - volumes: - - mount: "/example2" - type: "lv" - name: "example2" - size: - generator: "calc_total_vg" - generator_args: ["example2"] - file_system: "xfs" - -Although allocation of volumes for existing roles can be redefined by -a plugin, existing volumes definition cannot be changed; there will be -no error message, but you will not be able to open the settings for the -environment. If you need to redefine the partitioning for the already -existing roles, the only way to do that is to define your own volumes -and replace the standard one with them in the mappings. We do not -recommend this approach, though, as it makes the plugin incompatible -with other plugins, as well as with any updates. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-repos.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-repos.rst deleted file mode 100644 index 03fb13e92..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-repos.rst +++ /dev/null @@ -1,7 +0,0 @@ -.. _plugin-repos: - -=================== -Plugin repositories -=================== - -TBD \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings.rst deleted file mode 100644 index a96705edf..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings.rst +++ /dev/null @@ -1,16 +0,0 @@ - -.. _plugin-settings: - -Plugin settings ---------------- - -You can add plugin setting to the Fuel web UI, set restrictions, task -conditions, and override the core task settings. - -.. toctree:: - :maxdepth: 3 - - plugin-settings/add-settings.rst - plugin-settings/settings-restrictions.rst - plugin-settings/task-conditions.rst - plugin-settings/override-core-settings.rst \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/add-settings.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/add-settings.rst deleted file mode 100644 index 2f4a353a1..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/add-settings.rst +++ /dev/null @@ -1,297 +0,0 @@ - -.. _add-settings: - -Add plugin settings to the Fuel web UI --------------------------------------- - -You can add your plugin settings to the Fuel web UI. - -**To add plugin settings to the Fuel web UI** - -To place plugin specific settings to the Fuel web UI on the -:guilabel:`Settings` tab, you must edit the :ref:`environment_config.yaml` file. - -An automatically generated plugin contains only one example text field setting -in the group :guilabel:`Other`: - -.. code-block:: ini - - attributes: - metadata: - # Settings group can be one of "general", "security", "compute", - "network", - # "storage", "logging", "openstack_services" and "other". - group: 'other' - fuel-plugin-example_text: - value: 'Set default value' - label: 'Text field' - description: 'Description for text field' - weight: 25 - type: "text" - -Change the file to include more UI elements definitions: - -.. code-block:: ini - - attributes: - - # Text field - fuel_plugin_example_text: - type: "text" - weight: 10 - value: "default value" - label: "Text field label" - description: "Field description" - regex: - source: '\S' - error: "Error field cannot be empty" - - # Select - fuel_plugin_example_select: - type: "select" - weight: 20 - value: "value2" - label: "Select label" - description: "Select description" - values: - - data: "value1" - label: "Value 1 label" - - data: "value2" - label: "Value 2 label" - - data: "value3" - label: "Value 3 label" - - # Checkbox - fuel_plugin_example_checkbox: - type: "checkbox" - weight: 30 - value: true - label: "Checkbox label" - description: "Checkbox description" - - # Radio button - fuel_plugin_example_radio: - type: "radio" - weight: 40 - value: "data1" - label: "Radio buttons label" - values: - - data: "data1" - label: "Label data1" - description: "Description data1" - - data: "data2" - label: "Label data2" - description: "Description data2" - - data: "data3" - label: "Label data3" - description: "Description data3" - - # Multiple sigle line text inputs - since Fuel 9.0 - fuel_plugin_example_text_list: - value: ['text1','text2'] - label: 'Multiple Text field' - description: 'Description for text field' - weight: 25 - type: "text_list" - min: 1 - max: 5 - - # Multiple multiline text inputs - since Fuel 9.0 - fuel_plugin_example_textarea_list: - value: ['textarea1'] - label: 'Multiple text area field' - description: 'Description for textarea field' - weight: 25 - type: "textarea_list" - min: 1 - max: 2 - -.. note:: There is no ``group`` for plugin settings in this example, so the - settings for the plugin are under the default group - :guilabel:`Other` in the :guilabel:`Settings` tab of the Fuel web - UI. You can specify one of the values ``general``, ``security``, - ``compute``, ``network``, ``storage``, ``logging``, - ``openstack_services``, ``other`` as the group to place plugin - settings in. All of the groups with the exception of ``network`` - will be placed in the :guilabel:`Settings` tab, settings in the - ``network`` group will be put in the :guilabel:`Networks` tab. - Currently it is not possible to spread the settings for one plugin - between multiple groups. - -**Debug the Fuel web UI settings** - -Changes in :ref:`environment_config.yaml` affect only the environments which you -create after the changes, even if you use :command:`fuel plugins --sync`. -The Nailgun database stores each piece of the environment settings at the time -of the environment creation. During this time the synchronisation process does -not update the settings. - -To debug the Fuel web UI settings, use one of the following approaches: - -* Create a new environment after changing the settings definition. This might - be tedious, but you can speed up the process by using the command like this - from Fuel CLI: - - .. code-block:: console - - # fuel env create --name settings-test --rel 2 ; read -p 'Press \ - any key to delete test env...' key; fuel env --delete --env \ - `fuel env | grep settings-test | cut -d\| -f1` - Environment 'test2' with id=20 was created! - Press any key to delete test env... - Environment with id=20 was deleted - - This command creates an environment with the name ```settings-test``, waits - while you press any key, then deletes it. Unfortunately, you cannot just - reload the web page with the UI settings after using this command, as the - URL contains the environment ID, which is new for each created environment. - -* Download the settings for the existing environment with the command - :command:`fuel --env settings --download`, find your settings by - searching for the substring with the name of your plugin in the downloaded - file -- named ``settings_.yaml`` -- and then upload the file back - with the command :command:`fuel --env settings --upload`. The plugin - must be enabled in the environment for this method to work. - -Ensure that your browser does not use a stale page cache. In many browsers you -can use the shortcut SHIFT-F5 (CMD-R in Mac OS) to reload the page skipping -browser's cache. - -.. note:: This is also true for minor version updates. If the new minor - version has new UI settings, they will not be present on the - :guilabel:`Settings` tab for an existing environment after - the update. This is crucial for hot-pluggable plugins, as they - should work on the already deployed environments. - To resolve this, do the following: - - #. Create a new environment with the new version of the plugin. - #. Download the new plugin's UI settings and the settings - for the environment that you update. - #. Copy the downloaded settings of the plugin to the existing - environment and upload edited settings back to the existing - environment. - -.. note:: This is always a good idea to ensure that your browser bypasses - cache before trying to debug issues with the Fuel web UI. - -Before the deployment starts, Astute uploads all settings to the -``/etc/astute.yaml`` file on each of the target nodes. This file contains -the section for the plugin: - -.. code-block:: ini - - fuel-plugin-example: - fuel_plugin_name_checkbox: true - fuel_plugin_name_radio: data1 - fuel_plugin_name_select: value2 - fuel_plugin_name_text: default value - metadata: - always_editable: false - class: plugin - enabled: true - label: Title for fuel-plugin-example plugin - plugin_id: 1 - plugin_version: 1.0.0 - toggleable: true - weight: 70 - -The metadata fields, which are not defined explicitly in -:ref:`environment_config.yaml`, receive default values, while each of the UI -elements sets a corresponding parameter in ``astute.yaml``. - -One of the core tasks named ``hiera`` configures hiera so that ``astute.yaml`` -becomes one of the sources of information for it. Using ``hiera`` to get the -values for the settings as opposed to manual parsing of ``astute.yaml`` is -strongly recommended. - -Examples of ``hiera`` lookups: - -Bash: - -.. code-block:: ini - - STR=$(hiera “str”) - HASH=$(hiera -h “hash_name”) - ARRAY=$(hiera -a “array_name”) - -Puppet: - -.. code-block:: ini - - $str = hiera(‘str’, ‘’) - $arr = hiera_array(‘arr_name’, []) - $hash = hiera_hash(‘hash_name’, {}) - -Ruby: - -.. code-block:: ini - - #!/usr/bin/env ruby - require 'hiera' - ENV['LANG'] = 'C' - hiera = Hiera.new(:config => '/etc/hiera.yaml') - glanced = hiera.lookup 'glance', {} , {}, nil, :hash - nodes_array = hiera.lookup 'nodes', [], {}, nil, :array - -Use :command:`hiera ` to verify all of the plugin settings -from the shell prompt on a target node: - -.. code-block:: console - - # hiera fuel-plugin-example - {"fuel_plugin_name_select"=>"value2", - "fuel_plugin_name_checkbox"=>true, - "fuel_plugin_name_radio"=>"data1", - "fuel_plugin_name_text"=>"default value 1", - "metadata"=> - {"plugin_version"=>"1.0.1", - "group"=>"other", - "always_editable"=>false, - "weight"=>70, - "enabled"=>true, - "label"=>"Title for fuel-plugin-example plugin", - "toggleable"=>true, - "plugin_id"=>1, - "class"=>"plugin"}} - -Use the plugin settings to generalize the *iotop* task, so it will install -the packages from the list specified in the UI settings. Currently it is not -possible to dynamically add settings to the Fuel web UI, so use the -``textarea field``, which contains the names of the packages that you want -to install on the target node, one per line. - -.. note:: You can dynamically add setting starting with Fuel 9.0. - See the `blueprint `_. - -:ref:`environment_config.yaml`: - -.. code-block:: ini - - attributes: - - fuel_plugin_example_packages: - description: Field description - label: Text field label - type: textarea - value: default value - -Update the Puppet manifest, so it will install all the packages in the -variable ``fuel_plugin_example_packages``, which it will get from hiera: - -``deployment_scripts/puppet/manifests/install_iotop.pp``: - -.. code-block:: ini - - notice('MODULAR: fuel-plugin-example/iotop') - - $fuel_plugin_example = hiera(fuel-plugin-example, {}) - $packages = split($fuel_plugin_example['fuel_plugin_ - example_packages'], '\n') - - package { $packages: - ensure => 'installed', - } - -.. note:: If you do not want to provide Fuel web UI settings for your plugin, - except for the :guilabel:`Enable plugin` checkbox, you still need to - fill the :ref:`environment_config.yaml` with metadata for that checkbox. diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/override-core-settings.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/override-core-settings.rst deleted file mode 100644 index ebce034eb..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/override-core-settings.rst +++ /dev/null @@ -1,7 +0,0 @@ - -.. _override-core-settings: - -Override core settings ----------------------- - -TBD \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/settings-restrictions.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/settings-restrictions.rst deleted file mode 100644 index e93cde585..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/settings-restrictions.rst +++ /dev/null @@ -1,50 +0,0 @@ - -.. _settings-restrictions: - -Settings restrictions ---------------------- - -Plugin functionality can depend on some core features of Fuel or on the -features of other plugins. You can provide only some subset of the -functionality when some core feature is disabled and, vice versa, the -full functionality. You can also provide different functions depending -on what kind of hypervisor the user selects. Settings restrictions provide -a way to dynamically change the settings provided by a plugin. The general -information on the settings restrictions is in -*Developer Guide* -> *Extending OpenStack Settings* -> *Restrictions*. - -Settings restrictions are defined in :ref:`environment_config.yaml` and can be -applied not only to any specific setting but also for a plugin as a whole. -In this case, the restrictions should be applied to plugin metadata. - -This is an example of using restrictions in `Fuel Xenserver plugin `_: - -.. code-block:: ini - - attributes: - metadata: - restrictions: - - "settings:common.libvirt_type.value == 'kvm'" - - "settings:storage.volumes_ceph.value == true" - - "settings:storage.images_ceph.value == true" - - "settings:storage.ephemeral_ceph.value == true" - - "settings:storage.objects_ceph.value == true" - - "settings:additional_components.sahara.value == true" - - "settings:additional_components.murano.value == true" - - "settings:additional_components.ceilometer.value == true" - - "settings:additional_components.mongo.value == true" - - "settings:additional_components.ironic.value == true" - -If any of the listed settings are enabled, then the user cannot enable the -plugin. The restrictions are bidirectional, i.e. if you enable the plugin, -you cannot enable any of the listed settings without disabling the plugin -first. - -You can use other entry points to the Fuel API besides ``settings`` as -context. Some of the valid contexts are ``networking_parameters``, -``version``, and ``cluster``. Settings restrictions are used extensively -for the core Fuel settings. -To examine them, use the command -:command:`fuel --env 38 settings --default` to download the default settings -from one of the existing environments and look for the substring -``restrictions`` in the resulting file. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/task-conditions.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/task-conditions.rst deleted file mode 100644 index 3e042dfba..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-settings/task-conditions.rst +++ /dev/null @@ -1,50 +0,0 @@ - -.. _task-conditions: - -Conditions for plugin tasks ---------------------------- - -You can restrict plugin tasks from running, depending on whether some specific -settings in the Fuel web UI are enabled or not. The syntax slightly differs -from the one for the settings restriction as in the case of the task you -provide the opposite to the restriction -- a condition that must be true for -the task to run, but the net result is the same -- restricting the task from -running if the condition is not true. - -Here is an example. - -:ref:`deployment_tasks.yaml`: - -.. code-block:: ini - - - id: upload_cirros - type: shell - role: ['primary-controller'] - condition: "settings:swiftstack.upload_cirros_test.value == true" - -In this example, the default task ``upload_cirros`` will only run when -a specific setting for it is enabled in the Fuel web UI. The setting -itself can be defined as: - -:ref:`environment_config.yaml`: - -.. code-block:: ini - - upload_cirros_test: - weight: 20 - type: "checkbox" - value: true - label: "Enable upload test" - description: "Upload cirros base image when the deployment is done" - -You can perform lifecycle management tasks based on the history of -the OpenStack environment states. You can introduce expressions that can be -computed within the context of the OpenStack environment configuration, -so that you can control task assignment and execution depending on the -changes in configuration. - -.. note:: Conditions can only use settings and cluster contexts of the - Fuel API. - -.. seealso:: - - :ref:`data-driven` \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-versioning-system.rst b/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-versioning-system.rst deleted file mode 100644 index aa7780b81..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/create-plugin/plugin-versioning-system.rst +++ /dev/null @@ -1,62 +0,0 @@ - -.. _plugin_versioning_system: - -Plugin versioning system ------------------------- - -When the developer adds new functionality to a plugin, minor updates -or security fixes should be delivered. -The plugin developer creates a new version of the plugin: this can be -a major version or a minor one: - -* Major -- Changes in API, functionality, major OpenStack release introduced. -* Minor -- Security fixes only. - -The plugin versioning is the following: - -+-----+-----------------------+---------------------+-----------------+---------+---------+ -| | **Plugin file format**|**fuel-plugin value**|**metadata.yaml**|**major**|**minor**| -+-----+-----------------------+---------------------+-----------------+---------+---------+ -| RPM | fuel-plugin-1.0-1.0.0 | 1.0 | 1.0.1 |1.0.0 | 1.0.1 | -+-----+-----------------------+---------------------+-----------------+---------+---------+ - -**Plugin versioning example** - -If a plugin has version ``1.0.1`` in the ``metadat.yaml`` file, the file name -of the plugin must be ``plugin-1.0-1.0.1-N.rpm``. - -If you use the default setting of the Fuel plugin builder, N equals 1. You can -also specify a value from the ``build_version`` variable defined in the -:ref:`metadata.yaml` file that allows to iterate the package version without -updating the plugin version. - -Update procedure -~~~~~~~~~~~~~~~~ - -+-----+----------+-------------------------------------------------------------------------------------+ -| |**Update**|**Limitations** | -+-----+----------+-------------------------------------------------------------------------------------+ -| fp | No | 1.0 | -+-----+----------+-------------------------------------------------------------------------------------+ -| RPM | Yes | Can be updated to minor version only with *fuel plugins --update *| -| | | command. To get a major one, user has to download it from `Fuel Plugins Catalog | -| | | `_ and | -| | | create a new environment from scratch. | -+-----+----------+-------------------------------------------------------------------------------------+ - -Versioning scheme -~~~~~~~~~~~~~~~~~ - -* Versioning does not support the ``.fp`` plugins. The user must download and - install the ``.fp`` plugin from scratch. -* For RPM plugins, the versioning is as follows: - -.. image:: /_images/deliverables/scr_plugin_versioning.png - :width: 70% - :align: center - -.. note:: - Change the versioning scheme for customized packages to - have a clear indicator which package is installed - the official - Mirantis OpenStack or customized ones. Otherwise, check the - Python files to understand which package is actually installed. diff --git a/plugindocs/fuel-plugin-sdk-guide/existing-plugins.rst b/plugindocs/fuel-plugin-sdk-guide/existing-plugins.rst deleted file mode 100644 index feb006370..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/existing-plugins.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. _existing-plugins: - -Overview of existing plugins -============================ - -* `Fuel plugins on GitHub `_ - - contains the source code of Fuel Plugins. -* `DriverLog `_ - - contains the list of plugin maintainers with their contacts, compatible OpenStack releases, - and the CI/CD pipeline. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/faq.rst b/plugindocs/fuel-plugin-sdk-guide/faq.rst deleted file mode 100644 index a453d80d5..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/faq.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _faq: - -FAQ -=== - -**Where can I find the Fuel Plugin Builder source code?** - -You can find the source code for Fuel Plugin Builder and basic plugin -examples in the `fuel-plugins `_ -repository. - -**Are there any plugin examples?** - -The basic plugin examples are in the -`fuel-plugins `_ repository. - -For the existing plugins with open source code, see the section -:ref:`existing-plugins`. - -**I need to provide some external packages within my plugin, -but I do not want to place them in the plugin repository. Is there -any other way?** - -Use the ``pre_build_hook`` script to download packages in the -required directories: - -.. code-block:: ini - - #!/bin/bash - set -eux - - ROOT="$(dirname `readlink -f $0`)" - RPM_REPO="${ROOT}"/repositories/centos/ - DEB_REPO="${ROOT}"/repositories/ubuntu/ - - wget -P "${RPM_REPO}" http://mirror.fuel-infra.org/fuel-plugins/\ - 6.0/centos/glusterfs-3.5.2-1.mira2.x86_64.rpm - wget -P "${DEB_REPO}" http://mirror.fuel-infra.org/fuel-plugins/\ - 6.0/ubuntu/glusterfs-client_3.5.2-4_amd64.deb - -In this example, the hook downloads two packages to the plugin's directories -before Fuel Plugin Builder starts the build process. - -**What is the user context that the Fuel plugin hooks are invoked in: -root or fuel user?** - -Fuel executes the plugin hooks under the root user. - -**Are there role-naming conventions for plugins?** - -There are no strict requirements for naming plugin roles. We recommend using -a role name that contains the name of your product and unequivocally -associates with the plugin. - -**The large installer file stays a deployed node in ``/etc/fuel/plugins/...`` -after the deployment completes. Should we remove it after a successful -deployment on a node to save space?** - -We recommend providing any product specific files as packages that are put in -the repositories on the Fuel master nodes. The other option is to download the -files from external sources at the time of the deployment. - -With downloading the files from external sources, you can update the -product specific packages without updating the plugin itself. The files copied -to ``/etc/fuel/plugins`` are synced to the target nodes anew when the -deployment starts; this includes the cases when we only start a subset of -tasks by hand. This might be non-optimal to store the files in external -source and delete the files in plugin code. - -**I don't see a way to add just my one new role for a plugin to an -already-deployed BASE_OS machine.** - -Plugins are not expected to use the BASE-OS role.The BASE_OS role is not -intended to be combined with other roles. This role should be used when -you want to install just an operating system and do the rest of the work -manually. The Fuel plugin should either define its own roles -or add tasks to already existed roles. The operating system is installed -automatically when the plugin defines its own roles. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/how-plugins-work.rst b/plugindocs/fuel-plugin-sdk-guide/how-plugins-work.rst deleted file mode 100644 index c6adf5872..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/how-plugins-work.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. _how-plugins-work: - -About Fuel plugins -================== - -You can extend the functionality of your OpenStack environment through Fuel -plugins. Some Fuel plugins eliminate the need to install drivers and patches -manually after Fuel deploys an OpenStack environment, while others -enable users to configure additional capabilities, such as additional storage -types and networking functionality. For example, the -`Load Balancing as a Service (LBaaS) `_ -plugin allows you to add network load balancing functionality to your cloud, -so that incoming traffic can be spread across multiple nodes. You can use the -`Nova NFS plugin `_ -so that you can use `NFS `_ -as a storage backend for Nova ephemeral volumes. There is a number of Fuel -plugins available to download for free -in `DriverLog `_. - -In addition, Fuel offers an open source framework that enables developers to -create their own plugins and extend their environment functionalities as -required. For example, hardware vendors can benefit from using the plugin -framework by creating plugins that deploy custom drivers and enable OpenStack -to run on custom hardware. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/introduction.rst b/plugindocs/fuel-plugin-sdk-guide/introduction.rst deleted file mode 100644 index df655af88..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/introduction.rst +++ /dev/null @@ -1,23 +0,0 @@ - -.. index:: Introduction - -.. _plugin-sdk-introduction: - -Introduction to the Fuel Plugin SDK Guide -========================================= - -The Fuel Plugin SDK Guide provides instructions on how to build, test, and -troubleshoot your plugins; the guide also gives an overview of the existing -plugins. - -Before you read this document, you must do the following: - -#. Install the latest Fuel version. See :ref:`fuel-install-guide`. -#. Deploy an OpenStack environment with one controller and one compute node. - See :ref:`create-env-ug`. For testing purposes you will need to use at - least 3 Controller nodes for high availability. - -This guide is a work in progress and will eventually have most of -the information you need on Fuel Plugin SDK. In the meantime, use -the `community Wiki page `_ -as a supplementing reference. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/limitations.rst b/plugindocs/fuel-plugin-sdk-guide/limitations.rst deleted file mode 100644 index f1593cd68..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/limitations.rst +++ /dev/null @@ -1,12 +0,0 @@ -.. _plugin-limitations: - -Limitations -=========== - -* You must install and configure Fuel plugins that affect core functionality - before deploying an OpenStack environment. Otherwise, you will have to - redeploy the environment to enable the core plugin. Application-level - plugins can be installed later on top of the already deployed environments. -* Fuel plugins cannot be upgraded from one major to another major version. -* Fuel plugins for SDN solutions cannot create a new networking option in - the Fuel web UI wizard. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/reference.rst b/plugindocs/fuel-plugin-sdk-guide/reference.rst deleted file mode 100644 index f727a03d6..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/reference.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. _plugin-reference: - -Reference -========= - -.. toctree:: - :maxdepth: 3 - - reference/files.rst diff --git a/plugindocs/fuel-plugin-sdk-guide/reference/files.rst b/plugindocs/fuel-plugin-sdk-guide/reference/files.rst deleted file mode 100644 index 2d162a378..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/reference/files.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. _plugin-reference-files: - - -Files -===== - -.. toctree:: - :maxdepth: 3 - - files/components.rst - files/deployment_tasks.rst - files/environment_config.rst - files/metadata.rst - files/network_roles.rst - files/node_roles.rst - files/volumes.rst diff --git a/plugindocs/fuel-plugin-sdk-guide/reference/files/components.rst b/plugindocs/fuel-plugin-sdk-guide/reference/files/components.rst deleted file mode 100644 index b26a7a134..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/reference/files/components.rst +++ /dev/null @@ -1,4 +0,0 @@ -.. _components.yaml: - -components.yaml -================ diff --git a/plugindocs/fuel-plugin-sdk-guide/reference/files/deployment_tasks.rst b/plugindocs/fuel-plugin-sdk-guide/reference/files/deployment_tasks.rst deleted file mode 100644 index b7b734c91..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/reference/files/deployment_tasks.rst +++ /dev/null @@ -1,154 +0,0 @@ -.. _deployment_tasks.yaml: - -deployment_tasks.yaml ---------------------- - -Fuel uses the ``deployment_tasks.yaml`` file to define deployment tasks -and deployment tasks dependencies. - -Example: - -.. code-block:: ini - - - id: myplugin-keystonedb - groups: [primary-controller] - required_for: [keystone] - requires: [database] - type: puppet - parameters: - puppet_manifest: /etc/puppet/modules/osnailyfacter/modular/keystone/db.pp - puppet_modules: /etc/puppet/modules - timeout: 1800 - - -Fields: - -* ``role`` -- Describes a role of a node where tasks execute. You can only use - ``role`` with pre/post deployment tasks. - -* ``groups`` -- Describes a group of nodes with the specified role where tasks - will execute. You can only use ``groups`` with the main deployment tasks. - The task must have either a ``role`` or ``group`` field, but not both. - -* ``requires`` -- Specifies the list of tasks that the current task needs. - You can obtain the list of tasks using CLI: - - .. code-block:: console - - fuel graph --env 1 --download - -* ``required_for`` -- Specifies the list of tasks dependent on the current one. - -* ``timeout`` -- Specifies the execution timeout in seconds. Once specified, - the deployment will fail if the timeout expires. By default, the timeout is - set to 300 seconds. - -* ``type`` -- Determines the task's type. The type must be ``shell``, - ``puppet``, ``reboot```, or ``group``: - - * ``type: shell`` -- The task runs a shell script defined in the parameter - ``cmd``. - - Example: - - .. code-block:: ini - - # This tasks will be applied on controller nodes, - # here you can also specify several roles, for example - # ['cinder', 'compute'] will be applied only on - # cinder and compute nodes - - id: task-shell-deploy - role: ['controller'] - type: shell - parameters: - cmd: bash deploy.sh - timeout: 42 - - - id: task-shell-deploy - role: ['cinder','compute''] - type: shell - parameters: - cmd: bash deploy.sh - timeout: 42 - - # Task is applied for all roles - - id: task-shell-pluginlog - role: '*' - type: shell - parameters: - cmd: echo all > /tmp/plugin.all - timeout: 42 - - - * ``type: puppet`` -- The task lets you apply your own Puppet manifests - on OpenStack nodes. - - Parameters: - - * puppet_manifest - manifests directory path (relative to deployment_scripts). - * puppet_modules - modules directory path (relative to deployment_scripts). - - Example: - - .. code-block:: ini - - # Deployment will be applied on controllers only - - role: ['controller'] - type: puppet - parameters: - puppet_manifest: puppet/manifests/site.pp - puppet_modules: puppet/modules - timeout: 360 - - * ``type: reboot`` -- The task lets you reboot nodes with the specified - roles after the timeout. - - Example: - - .. code-block:: ini - - - role: '*' - type: reboot - parameters: - timeout: 300 - - * ``type: group`` -- This is a meta-task. The task must contain the - ``tasks`` field with the list of tasks to be executed on the specified - nodes. - - .. code-block:: ini - - - id: standalone-keystone - type: group - role: [standalone-keystone] - requires: [deploy_start, primary-standalone-keystone] - required_for: [deploy_end] - tasks: [fuel_pkgs, hiera, globals, tools, logging, netconfig, - hosts, firewall, deploy_start, cluster, keystone-vip, - cluster-haproxy, memcached, openstack-haproxy-stats, task-keystone] - parameters: - strategy: - type: parallel - -When you set up a group of tasks, you can also specify how these tasks -execute: in “parallel” or “one-by-one”. - -* ``strategy: type``: - - * "parallel" - tasks will be executed in parallel - * "one-by-one" - tasks will be executed one-by-one - -Once you choose “parallel”, you can specify the maximum number of tasks -that run in parallel using the ``amount`` parameter. - -.. code-block:: ini - - - id: controller - type: group - role: [controller] - requires: [primary-controller] - required_for: [deploy_end] - parameters: - strategy: - type: parallel - amount: 6 \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/reference/files/environment_config.rst b/plugindocs/fuel-plugin-sdk-guide/reference/files/environment_config.rst deleted file mode 100644 index bfa3067e1..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/reference/files/environment_config.rst +++ /dev/null @@ -1,42 +0,0 @@ -.. _environment_config.yaml: - -======================= -environment_config.yaml -======================= - -Fuel uses the ``environment_config.yaml`` file for the additional attributes -that will appear on the :guilabel:`Settings` tab of the Fuel web UI. - -When Fuel deploys the environment, these attributes pass to the task executor -so that the data is available in the ``/etc/astute.yaml`` file on each target -node and can be accessed from your bash or Puppet scripts. - -Example: - -.. code-block:: ini - - attributes: - metadata: - group: 'other' - restrictions: - - "settings:common.libvirt_type.value == 'kvm'" - fuel_plugin_name_attr1: - value: 'Set default value' - label: 'Text field 1' - description: 'Description for text field 1' - weight: 25 - type: 'text' - fuel_plugin_name_attr2: - value: 'Set default value' - label: 'Text field 2' - description: 'Description for text field 2' - weight: 25 - type: 'text' - -The file should consist of the``attributes`` keywords, followed by ``metadata`` -and the list of atttributes. The ``metadata`` keyword may contain ``group`` -and ``restrictions``. - -For descriptions of the fields, refer to `this section`_ in Fuel Developer Guide. - -.. _this section: http://docs.openstack.org/developer/fuel-docs/devdocs/develop/nailgun/customization/settings.html diff --git a/plugindocs/fuel-plugin-sdk-guide/reference/files/metadata.rst b/plugindocs/fuel-plugin-sdk-guide/reference/files/metadata.rst deleted file mode 100644 index 88c965dc4..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/reference/files/metadata.rst +++ /dev/null @@ -1,112 +0,0 @@ -.. _metadata.yaml: - -============= -metadata.yaml -============= - -The file :ref:`metadata.yaml` contains a various metadata related to a plugin: - -Example: - -.. code-block:: ini - - # Plugin name - name: elasticsearch_kibana - # Human-readable name for your plugin - title: The StackLight Elasticsearch-Kibana Server Plugin - # Plugin version - version: '1.0.0' - # Description - description: Deploy Elasticsearch and the Kibana web interface. - # Required fuel version - fuel_version: ['8.0', '9.0'] - # Licences - licenses: ['Apache License Version 2.0'] - # Specify author or company name - authors: ['Mirantis Inc.'] - # A link to the plugin homepage - homepage: 'https://github.com/openstack/fuel-plugin-elasticsearch-kibana' - groups: ['monitoring'] - is_hotpluggable: true - - # The plugin is compatible with releases in the list - releases: - - os: ubuntu - version: liberty-8.0 - mode: ['ha'] - deployment_scripts_path: deployment_scripts/ - repository_path: repositories/ubuntu - - os: ubuntu - version: liberty-9.0 - mode: ['ha'] - deployment_scripts_path: deployment_scripts/ - repository_path: repositories/ubuntu - - os: ubuntu - version: mitaka-9.0 - mode: ['ha'] - deployment_scripts_path: deployment_scripts/ - repository_path: repositories/ubuntu - - # Version of the plugin package - package_version: '4.0.0' - # Version of the plugin build - build_version: '1476097405' - -Fields: - - - * ``name`` -- Name of the plugin that will be in the plugin's RPM file name. - The allowed name characters are lowercase letters, dash ``-``, and - underscore ``_``. - * ``title`` -- Human-readable plugin name displayed on the Fuel web UI. - * ``version`` -- Plugin version. For guidelines, see - :ref:`plugin_versioning_system`. - * ``fuel_version`` -- The Fuel version that your plugin is compatible with. - Currently, the builder verifies ``fuel_version`` only against - ``package_version``. The ``package_version`` field must be supported - by the Fuel versions listed at the bottom of this section. - Leaving this field empty will skip the check. For format guidelines, - see `_ClassType StrictVersion `_. - * ``licenses`` -- List the licenses under which your plugin can be - distributed. - * ``authors`` -- Name of the plugin author. A company or an individual. - * ``homepage`` -- A link to page with your plugin. This can be your plugin's - GitHub repository page. - * ``is_hotpluggable`` -- State if the plugin is hot-pluggable. - See :ref:`plugin-hotpluggable`. - * ``groups`` -- A group to which your plugin belongs in the Fuel web UI. - * ``releases`` -- A list of OpenStack releases compatible with the plugin. - - * ``releases: os`` -- A compatible Linux distribution for the plugin. - The supported values are ``ubuntu`` and ``centos``. Fuel 8.0 supports - only Ubuntu. - * ``releases: version`` -- A compatible OpenStack release version. - Fuel Plugin Builder does not validate the ``releases: version`` - field; but if there is no OpenStack release with the same version - on the Fuel Master, the user cannot enable the plugin. See also a - note in :ref:`install-plugin-builder`. - * ``releases: mode`` -- A list of compatible cluster deployment modes. - Fuel 8.0 supports only the ``haz`` value. - * ``releases: deployment_scripts_path`` -- A path in your plugin directory - where all the deployment scripts for the release are. The path is - relative to the plugin root. - * ``releases: repository_path`` -- A path in your plugin directory where - all the packages for the release are. Relative to the plugin root. - - * ``package_version`` -- A version of the compatible plugin format. - To build your plugin, the Fuel Plugin Builder version must be the same - as the version of the compatible plugin format or newer. Each new plugin - format version introduces new features and, possibly, deprecates some of - the old ones. The Fuel master node must support the specific - ``package_version``, otherwise, you cannot install the plugin. - - The table below shows the existing plugin format versions and the versions of - Fuel starting from which they are supported: - - +---------------+-------+-------+-------+-------+-------+ - | Plugin format | 1.0.0 | 2.0.0 | 3.0.0 | 4.0.0 | 5.0.0 | - +---------------+-------+-------+-------+-------+-------+ - | Fuel | 6.0 | 6.1 | 7.0 | 8.0 | 9.0 | - +---------------+-------+-------+-------+-------+-------+ - * ``build_version`` -- A version of the build that allows to iterate package - version without updating the plugin version. \ No newline at end of file diff --git a/plugindocs/fuel-plugin-sdk-guide/reference/files/network_roles.rst b/plugindocs/fuel-plugin-sdk-guide/reference/files/network_roles.rst deleted file mode 100644 index f5292e6b6..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/reference/files/network_roles.rst +++ /dev/null @@ -1,4 +0,0 @@ -.. _network_roles.yaml: - -network_roles.yaml -================== diff --git a/plugindocs/fuel-plugin-sdk-guide/reference/files/node_roles.rst b/plugindocs/fuel-plugin-sdk-guide/reference/files/node_roles.rst deleted file mode 100644 index d76731f50..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/reference/files/node_roles.rst +++ /dev/null @@ -1,4 +0,0 @@ -.. _node_roles.yaml: - -node_roles.yaml -=============== diff --git a/plugindocs/fuel-plugin-sdk-guide/reference/files/volumes.rst b/plugindocs/fuel-plugin-sdk-guide/reference/files/volumes.rst deleted file mode 100644 index a673f5817..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/reference/files/volumes.rst +++ /dev/null @@ -1,4 +0,0 @@ -.. _volumes.yaml: - -volumes.yaml -============ diff --git a/plugindocs/fuel-plugin-sdk-guide/requirements.rst b/plugindocs/fuel-plugin-sdk-guide/requirements.rst deleted file mode 100644 index df03f8abf..000000000 --- a/plugindocs/fuel-plugin-sdk-guide/requirements.rst +++ /dev/null @@ -1,15 +0,0 @@ -.. _plugin-requirements: - -Requirements -============ - -* Plugin code must be idempotent. -* Do not copy modules from fuel-library. Add the module path - into task description instead and use fuel-library as framework: - ``puppet_modules: "puppet/modules:/etc/puppet/modules"`` -* If you use plugin pre-deployment scripts that somehow change the state of - the Fuel Master node -- for example, changes to Nailgun database -- - ensure that all these changes are removed in the post-deployment script. -* See :ref:`code-style` and - `Fuel contribution guidelines `_ -* recommendation on pre_build_hook \ No newline at end of file diff --git a/requirements.txt b/requirements.txt deleted file mode 100644 index 467f333c6..000000000 --- a/requirements.txt +++ /dev/null @@ -1,6 +0,0 @@ -sphinx==1.3b3 -rst2pdf -funcparserlib -webcolors -beautifulsoup4==4.4.0 -openstackdocstheme diff --git a/setup.cfg b/setup.cfg deleted file mode 100644 index c155cd21d..000000000 --- a/setup.cfg +++ /dev/null @@ -1,13 +0,0 @@ -[metadata] -name = fuel-docs -version = 9.0.0 -author = OpenStack -author-email = fuel-dev@lists.launchpad.net - -[build_sphinx] -all_files = 1 -build-dir = doc/build -source-dir = . - -[wheel] -universal = 1 diff --git a/setup.py b/setup.py deleted file mode 100644 index 8e868c604..000000000 --- a/setup.py +++ /dev/null @@ -1,20 +0,0 @@ -# Copyright 2012 Mirantis, Inc. -# -# Licensed under the Apache License, Version 2.0 (the "License"); you may -# not use this file except in compliance with the License. You may obtain -# a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT -# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the -# License for the specific language governing permissions and limitations -# under the License. - -import setuptools - - -setuptools.setup( - setup_requires=['pbr'], - pbr=True) diff --git a/tox.ini b/tox.ini deleted file mode 100644 index 3c0883626..000000000 --- a/tox.ini +++ /dev/null @@ -1,12 +0,0 @@ -[tox] -minversion = 1.6 -skipsdist = True - -[testenv] -usedevelop = True -install_command = pip install --allow-external -U {opts} {packages} -setenv = VIRTUAL_ENV={envdir} -deps = -r{toxinidir}/requirements.txt - -[testenv:venv] -commands = {posargs:} diff --git a/userdocs/fuel-install-guide.rst b/userdocs/fuel-install-guide.rst deleted file mode 100644 index 867707e23..000000000 --- a/userdocs/fuel-install-guide.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. _fuel-install-guide: - -======================= -Fuel Installation Guide -======================= - -.. toctree:: - :maxdepth: 3 - - fuel-install-guide/intro_fuel_install_intro - fuel-install-guide/sysreq_intro - fuel-install-guide/install_install_fuel - fuel-install-guide/bootstrap_intro - fuel-install-guide/local-repo - fuel-install-guide/plugins_intro - fuel-install-guide/vsphere_intro - fuel-install-guide/update-fuel - fuel-install-guide/upgrade_intro - fuel-install-guide/preinstall_intro - diff --git a/userdocs/fuel-install-guide/bootstrap/bootstrap_add_package.rst b/userdocs/fuel-install-guide/bootstrap/bootstrap_add_package.rst deleted file mode 100644 index 0e6130b40..000000000 --- a/userdocs/fuel-install-guide/bootstrap/bootstrap_add_package.rst +++ /dev/null @@ -1,188 +0,0 @@ -.. _bootstrap_add_package: - -Build a bootstrap image with an additional package --------------------------------------------------- - -You can install any custom package from the default repository or -the connected external repository through the ``fuel-bootstrap`` builder script. - -**Example 1: Installation of the ``strace`` package from the default repository** - -#. Build the bootstrap: - - .. code-block:: console - - $ fuel-bootstrap build --package 'strace' --label 'bootstrap_with_strace' \ - --output-dir ~/example1/ - - **System response:** - - .. code-block:: console - - ...Building process... - Building initramfs - Building squashfs - ... - Bootstrap image a778efad-88ca-41fe-b592-f02101c11d22 has been built: /root/example1/a778efad-88ca-41fe-b592-f02101c11d22.tar.gz - - You can also specify a path to a custom configuration file with parameters - for building a new bootstrap instead of using parameters from the default - configuration file. - - For example: - - .. code-block:: console - - $ fuel-bootstrap build --config /etc/fuel-bootstrap-cli/my-config-xenial.yaml - -#. After the build process is completed, you can import and activate the new bootstrap image: - - .. code-block:: console - - $ fuel-bootstrap import ~/example1/a778efad-88ca-41fe-b592-f02101c11d22.tar.gz --activate - -#. Verify that the bootsrtap image has been activated: - - .. code-block:: console - - $ fuel-bootstrap list |grep active - - **System response:** - - .. code-block:: console - - | a778efad-88ca-41fe-b592-f02101c11d22 | bootstrap_with_strace | active | - -#. Reboot the discovered node: - - .. code-block:: console - - $ ssh 10.109.0.3 reboot - -#. Verify that the new bootstrap image is loaded on the discovered node: - - #. Verify that the ``runtime_uuid`` value of the activated bootstrap image - has been updated in the ``nailgun-agent`` configuration file: - - .. code-block:: console - - # cat /etc/nailgun-agent/config.yaml - - **System response:** - - .. code-block:: console - - {runtime_uuid: a778efad-88ca-41fe-b592-f02101c11d22} - - #. Verify that the new package has been installed: - - .. code-block:: console - - # dpkg -l |grep strace - - **System response:** - - .. code-block:: console - - ii strace 4.8-1ubuntu5 amd64 A system call tracer - - -**Example 2: Installation of the ``nginx`` package using a custom repository** - -#. Add the ``nginx`` repository to the ``fuel_bootstrap_cli.yaml`` file: - - #. Open the fuel_bootstrap_cli.yaml file for editing: - - .. code-block:: console - - $ vim /etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml - - #. Add the following text: - - .. code-block:: yaml - - ... - repos: - - name: ubuntu-0 - ... - - name: ubuntu-1 - ... - - name: custom_user_repo - priority: 1001 - section: "nginx" - suite: trusty - type: deb - uri: "http://nginx.org/packages/ubuntu" - ... - - .. warning:: - - The first repository must point to the upstream mirror. - - .. warning:: - - Use priorities higher than 1000 to force the installation - of an old version of a package, when other repositories - have newer versions of the same package or a newer version - of the package is already installed on the system. - You can use the force installation in case of a regression - caused by the newer version of a package. - Find more information about apt-pinning in - `Debian Manuals `_. - -#. Build the bootstrap image: - - .. code-block:: console - - $ fuel-bootstrap --verbose --debug build --label 'with_nginx_repo_package' --package nginx --activate - - **System response:** - - .. code-block:: console - - ... - Bootstrap image e295a410-2605-4ddf-a967-c3d638d901bc has been built: - ... - Bootstrap image e295a410-2605-4ddf-a967-c3d638d901bc has been activated. - ... - -#. After the build process is completed, reboot the discovered node. - -#. Verify that the new package has been installed: - - .. code-block:: console - - # dpkg -l |grep nginx - - **System response:** - - .. code-block:: console - - ii nginx 1.8.1-1~trusty amd64 high performance web server - -#. View the status of the packageL - - .. code-block:: console - - # apt-cache show nginx - - **System response:** - - .. code-block:: console - - Package: nginx - Status: install ok installed - ... - -#. Verify that the ``runtime_uuid`` value of the activated bootstrap image - has been updated in the ``nailgun-agent`` configuration file: - - .. code-block:: console - - # cat /etc/nailgun-agent/config.yaml - - **System response:** - - .. code-block:: console - - {runtime_uuid: e295a410-2605-4ddf-a967-c3d638d901bc} diff --git a/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.rst b/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.rst deleted file mode 100644 index d57247624..000000000 --- a/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.rst +++ /dev/null @@ -1,66 +0,0 @@ -.. _bootstrap_builder: - -Overview of the Fuel bootstrap builder --------------------------------------- - -The bootstrap generator creates bootstrap images for the Fuel Master node -that Fuel will use to boot the Fuel Slave nodes. The bootstrap -generator uses default configurations, however, you -can modify these settings. - -You can customize a Fuel bootstrap image using one of the following options: - -* Set additional packages for the installation. -* Copy custom files into the root bootstrap. -* Run a user script at the bootstrap file system during the image - creation. - - -You can configure Fuel bootstrap images using the ``fuel-bootstrap`` command: - -.. code-block:: console - - usage: fuel-bootstrap [--version] [-v] [--log-file ] [-q] [-h] - [--debug] [--config ] - - -.. list-table:: **Optional arguments** - :widths: 15 25 - :header-rows: 0 - - * - Option - - Description - * - ``--version`` - - Shows a program's version number and exits. - * - ``-v``, ``--verbose`` - - Increases a verbosity of output. Can be repeated. - * - ``--log-file `` - - Specify a file to log output. Disabled by default. - * - ``-q``, ``--quiet`` - - Suppress output except for warnings and errors. - * - ``-h``, ``--help`` - - Shows this help message and exits. - * - ``--debug`` - - Shows tracebacks on errors. - * - ``--config `` - - Specify a configuration file with bootstrap settings. - - -.. list-table:: **Commands to operate with a bootstrap image** - :widths: 5 25 - :header-rows: 0 - - * - Command - - Description - * - ``activate`` - - Activates the specified bootstrap image. - * - ``build`` - - Builds a new bootstrap image with the specified parameters. - * - ``delete`` - - Deletes the specified bootstrap image from the system. - * - ``help`` - - Print the detailed help information for the corresponding command. - * - ``import`` - - Imports an already created bootstrap image to the system. - * - ``list`` - - Lists all available bootstrap images. diff --git a/userdocs/fuel-install-guide/bootstrap/bootstrap_container.rst b/userdocs/fuel-install-guide/bootstrap/bootstrap_container.rst deleted file mode 100644 index 09d8dc84d..000000000 --- a/userdocs/fuel-install-guide/bootstrap/bootstrap_container.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. _bootstrap_container_format: - -The fuel-bootstrap container format ------------------------------------ - -To simplify bootstrap sharing and delivery, pack all files required -for the bootstrap image in a ``tar.gz`` archive. You can also create and -archive manually without using the ``fuel-bootstrap`` script. - -The bootstrap archive must include: - -* ``metadata.yaml`` - a ``.yaml`` file that describes the configuration -* ``initrd.img`` - an initial RAM file system -* ``vmlinuz`` - a kernel image - -.. warning:: - - You cannot modify file names. This limitation is planned to be removed in future releases. - -Optionally, you can add extra files: - -* root.squashfs - a root file system - -Mandatory data fields for ``metadata.yaml`` are: - -.. code-block:: yaml - - extend_kopts : 'key=value net.ifnames=1 debug ignore_loglevel' - # kernel command line opts will be extended with Fuel default opts. - # But, its also possible to re-write default params - w\o any - # guarantee of work. - - uuid: 244782c1-7343-43f7-9ee3-8989c252eb2e - # Uuid for identify bootstrap. - -**Generate UUID** - -In the case of the manually built bootstrap you can generate UUID with -the following command: - -.. code-block:: console - - python -c "import uuid; print str(uuid.uuid4())" - -To connect (discover) and work correctly, ``fuel-bootstrap`` requires -runtime system to have installed and properly configured packages. -The list of packages is specified in the -``/etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml`` file. diff --git a/userdocs/fuel-install-guide/bootstrap/bootstrap_debug.rst b/userdocs/fuel-install-guide/bootstrap/bootstrap_debug.rst deleted file mode 100644 index 15df9ba25..000000000 --- a/userdocs/fuel-install-guide/bootstrap/bootstrap_debug.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _bootstrap_debug: - -Enable advanced debugging -------------------------- - -If creating a new bootstrap image results in errors, -you can analyze your system by enabling the chroot bootstrap -development environment. - -This section provides an example of running bootstrap building -in the chroot environment. - -**To enable advanced debugging:** - -.. warning:: - - Use for debug purpose only. - -#. Prepare the ``sleep`` script: - - .. code-block:: console - - $ cat /root/sleep.sh - #!/bin/bash - sleep 99h || true - -#. Start the build process with the ``sleep.sh`` script: - - .. code-block:: console - - $ fuel-bootstrap --verbose --debug build --extra-dir /root/mlnx/mlnx_bootstrap_root/ \ - --label debug --activate --script /root/sleep.sh - - **System response:** - - .. code-block:: console - - ... - Copy user-script /root/sleep.sh into chroot:/tmp/tmpdOS3ya.fuel-agent-image - Trying to execute command: chroot /tmp/tmpdOS3ya.fuel-agent-image /bin/bash -c /sleep.sh - - The process is sleeping and you can jump into chroot - - The ``sleep.sh`` script delays the start of the building process. - Therefore, you can enable the chroot environment. - -#. Enable the chroot environment: - - .. code-block:: console - - $ chroot /tmp/tmpdOS3ya.fuel-agent-image /bin/bash - -#. Fix ``PATH`` difference between CentOS and Ubuntu environmnets: - - .. code-block:: console - - $ export PATH=$PATH:/sbin:/bin - -#. You can now make any changes to the ``bootstrap-dev`` system. - -#. After you apply the required changes, exit the chroot environment. - -#. Terminate the ``sleep`` process: - - .. code-block:: console - - $ [root@nailgun ~]# ps xauf |grep sleep - - **System response:** - - .. code-block:: console - - root 23642 0.0 0.0 9524 1128 pts/14 S+ 17:54 0:00 | \_ /bin/bash /sleep.sh - root 23643 0.0 0.0 4340 360 pts/14 S+ 17:54 0:00 | \_ sleep 99h - - .. code-block:: console - - $ kill -s INT 23643 - -After that, the building process will continue as usual. diff --git a/userdocs/fuel-install-guide/bootstrap/bootstrap_inject_cert.rst b/userdocs/fuel-install-guide/bootstrap/bootstrap_inject_cert.rst deleted file mode 100644 index 35ef99b16..000000000 --- a/userdocs/fuel-install-guide/bootstrap/bootstrap_inject_cert.rst +++ /dev/null @@ -1,33 +0,0 @@ -.. _bootstrap_inject_cert: - -Inject custom SSL certificates ------------------------------- - -You can inject any customization scripts and files inside -a bootstrap using ``fuel-bootstrap``. -For example, you can add custom certificates to access -an https repository. - -**To inject certificate files:** - -#. Add a certificate to the Fuel Master system to provide - correct work of debootstrap run on the Fuel Master node: - - .. code-block:: console - - $ update-ca-trust force-enable - $ cp cert.crt /etc/pki/ca-trust/source/anchors/ - $ update-ca-trust extract - -#. Create a directory with the certificate to inject: - - .. code-block:: console - - $ mkdir -p /root/bootstrap_root/usr/local/share/ca-certificates/ - $ cp cert.crt /root/bootstrap_root/usr/local/share/ca-certificates/ - -#. Build the bootstrap: - - .. code-block:: console - - $ fuel-bootstrap build --load-cert --extra-dir /root/bootstrap_root/ diff --git a/userdocs/fuel-install-guide/bootstrap/bootstrap_inject_driver.rst b/userdocs/fuel-install-guide/bootstrap/bootstrap_inject_driver.rst deleted file mode 100644 index 9d7ececf7..000000000 --- a/userdocs/fuel-install-guide/bootstrap/bootstrap_inject_driver.rst +++ /dev/null @@ -1,225 +0,0 @@ -.. _bootstrap_inject_driver: - -Inject a driver from .deb packages ----------------------------------- - -When you need to install custom hardware drivers from the official -repository, you can inject them into a bootstrap. - -**To install a driver provided as a deb package:** - -Input: - -* ``.deb`` files provided by HW-support - Fetched from: - http://bgate.mellanox.com/openstack/mellanox_fuel_plugin/8.0/repositories/ubuntu/ - -* files to be injected to the bootstrap - Fetched from review. - -The ``.deb`` files: - -.. code-block:: console - - $ la -lah /root/mlnx_debs/ - -**System response:** - -.. code-block:: console - - -rw-r--r-- 1 root root 13M Jan 21 08:55 cirros-testvm-mellanox-ib_0.3.2-7_amd64.deb - -rw-r--r-- 1 root root 13M Jan 21 08:55 cirros-testvm-mellanox_0.3.2-ubuntu3_amd64.deb - -rw-r--r-- 1 root root 27K Jan 21 08:55 eswitchd_0.13-1_amd64.deb - -rw-r--r-- 1 root root 27K Jan 21 08:55 eswitchd_1.14-3_amd64.deb - -rw-r--r-- 1 root root 44K Jan 31 16:08 libibverbs1_1.1.8mlnx1-OFED.3.1.1.0.0_amd64.deb - -rw-r--r-- 1 root root 49K Jan 31 16:08 libmlx4-1_1.0.6mlnx1-OFED.3.1.1.0.0_amd64.deb - -rw-r--r-- 1 root root 3.7K Jan 21 08:55 mlnx-dnsmasq_2015.1.0-1_all.deb - -rw-r--r-- 1 root root 100M Jan 21 08:55 mlnx-ofed-fuel_2.3-2.0.8_amd64.deb - -rw-r--r-- 1 root root 193M Jan 21 08:55 mlnx-ofed-fuel_3.1-1.5.7_amd64.deb - -rw-r--r-- 1 root root 1.9M Jan 31 16:08 mlnx-ofed-kernel-dkms_3.1-OFED.3.1.1.0.3.1.g9032737_all.deb - -rw-r--r-- 1 root root 68K Jan 31 16:08 mlnx-ofed-kernel-utils_3.1-OFED.3.1.1.0.3.1.g9032737_amd64.deb - -rw-r--r-- 1 root root 14K Jan 31 16:08 ofed-scripts_3.1-OFED.3.1.1.0.3_amd64.deb - -rw-r--r-- 1 root root 18K Jan 21 08:55 python-networking-mlnx_2015.1.2-1_amd64.deb - -The files to be injected to the bootstrap image: - -.. code-block:: console - - $ tree /root/mlnx_files// - -**System response:** - -.. code-block:: console - - |-- mellanox_customize_init.sh - `-- mlnx_bootstrap_root - |-- etc - | `-- modprobe.d - | `-- ipoib.conf - `-- usr - `-- bin - `-- init_mlnx.sh - - -.. warning:: - - Injected files and folder should have execute permission - -.. code-block:: console - - $ find /root/mlnx_files/ -type f -iname *.sh -print | xargs chmod 0755 - $ find /root/mlnx_files/ -type d -print | xargs chmod 755 - -The custom script: - -.. code-block:: console - - $ cat /root/mlnx/mellanox_customize_init.sh - -**System response:** - -.. code-block:: console - - #!/bin/bash - - echo "MLNX add init_mlnx.sh into bootstrap /etc/rc.local" - sed -i 's/.*fix-configs.*/$(init_mlnx.sh > \/dev\/null 2>\&1) \& || true\n&/' /etc/rc.local - - -To push deb packages into the bootstrap, create a new repository on the Fuel Master node -and pull the repository to the builder following the steps below: - -#. Prepare a custom repository under ``nailgun`` folder: - - #. Create a fodler for the repository: - - .. code-block:: console - - $ mkdir -p /var/www/nailgun/mlnx_repo/ubuntu - - #. Copy all ``*.deb`` files to the folder: - - .. code-block:: console - - $ cp /root/mlnx_debs/*.deb /var/www/nailgun/mlnx_repo/ubuntu - - #. Run ``dpkg`` tool to create repo-metadata: - - .. code-block:: console - - $ pushd /var/www/nailgun/mlnx_repo/ubuntu/ - $ dpkg-scanpackages ./ /dev/null | gzip -9c > Packages.gz - $ popd - - #. Create a simple ``Release`` stub file: - - .. code-block:: console - - $ echo -e "Origin: user_custom\nLabel: custom\nSuite: user_custom\nCodename: \ - user_custom\nArchitectures: amd64\nComponents: main\nDescription: custom" \ - > /var/www/nailgun/mlnx_repo/ubuntu/Release - - -#. Include the repository to configure the bootstrap builder: - - .. code-block:: console - - $ vim /etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml - - **System response:** - - .. code-block:: yaml - - ... - repos: - ... - - name: custom_mlnx_repo - priority: 1001 - section: "" - suite: ./ - type: deb - uri: "http://:8080/mlnx_repo/ubuntu/" - - where ``FUEL_MASTER_IP`` is an IP address of the Fuel Master node. - - -#. Run the bootstrap builder: - - .. code-block:: console - - $ fuel-bootstrap --verbose --debug build --package mlnx-ofed-kernel-dkms \ - --package mlnx-ofed-kernel-utils --extra-dir \ - /root/mlnx/mlnx_bootstrap_root/ --label mlnx-ofed-kernel \ - --activate --script /root/mlnx/mellanox_customize_init.sh - - **System response:** - - .. code-block:: console - - ... - Trying to execute command: rsync -rlptDKv /root/mlnx/mlnx_bootstrap_root// /tmp/tmpsJA1Yp.fuel-agent-image/ - ... - Trying to execute command: chroot /tmp/tmpsJA1Yp.fuel-agent-image /bin/bash -c /mellanox_customize_init.sh - .... - stdout:MLNX add init_mlnx.sh into bootstrap /etc/rc.local - ... - Setting up mlnx-ofed-kernel-dkms (3.1-OFED.3.1.1.0.3.1.g9032737) - ... - Loading new mlnx-ofed-kernel-3.1 DKMS files - ... - Rsync files from /root/mlnx/mlnx_bootstrap_root/ to: /tmp/tmpIA5Ro8.fuel-agent-image - ... - --- Building bootstrap image END (do_mkbootstrap) --- - ... - Bootstrap image 37369fd8-34c0-444d-a4d1-2f266d586442 has been activated - - -#. Reboot the affected nodes: - - .. code-block:: console - - $ ssh 10.109.0.3 reboot - -#. Check that the driver has been installed succesfully: - - #. View the information about the installed packages: - - .. code-block:: console - - # dpkg -l |grep mlnx - - **System response:** - - .. code-block:: console - - ii mlnx-ofed-kernel-dkms 3.1-OFED.3.1.1.0.3.1.g9032737 all DKMS support for mlnxofed kernel modules - ii mlnx-ofed-kernel-utils 3.1-OFED.3.1.1.0.3.1.g9032737 amd64 Userspace tools to restart and tune mlnx-ofed kernel modules - - #. View the information about the installed kernel module: - - .. code-block:: console - - # modinfo mlx4_core - - **System response:** - - .. code-block:: console - - filename: /lib/modules/3.13.0-76-generic/updates/dkms/mlx4_core.ko - version: 3.1-1.0.3 - license: Dual BSD/GPL - description: Mellanox ConnectX HCA low-level driver - author: Roland Dreier - ... - - #. View the running process: - - .. code-block:: console - - # ps xauf |grep init_mlnx.sh - - **System response:** - - .. code-block:: console - - root 3113 0.0 0.0 9600 1492 pts/0 S 13:00 0:00 /bin/bash /usr/bin/init_mlnx.sh diff --git a/userdocs/fuel-install-guide/bootstrap/bootstrap_install_kernel.rst b/userdocs/fuel-install-guide/bootstrap/bootstrap_install_kernel.rst deleted file mode 100644 index 504bbaf63..000000000 --- a/userdocs/fuel-install-guide/bootstrap/bootstrap_install_kernel.rst +++ /dev/null @@ -1,202 +0,0 @@ -.. _bootstrap_install_kernel: - -Install a custom kernel ------------------------ - -You can install a custom kernel in a bootstrap image. -For example, you can install the latest Ubuntu kernel -or an older version of the kernel intended to fix regressions. - -.. warning:: - - Non-standard kernels, which were not verified with the Fuel packages, - can brake your system. - -Install the latest kernel -------------------------- - -To install the latest ``lts-trusty`` kernel, you do not need -to make any customization. Simply run the bootstrap builder with -the default parameters and the latest ``lts-trusty`` kernel -available in the repositories will be fetched. - -**To install the latest kernel:** - -#. Install the kernel different from ``lts-trusty`` - -#. Open and edit configuration file adding the new repository: - - .. code-block:: console - - $ vim /etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml - - .. code-block:: yaml - - ... - - name: wily1 - priority: 1001 - section: "main restricted universe multiverse" - suite: wily - type: deb - uri: "http://cz.archive.ubuntu.com/ubuntu/" - - name: wily2 - priority: 1001 - section: "main restricted universe multiverse" - suite: wily-updates - type: deb - uri: "http://cz.archive.ubuntu.com/ubuntu/" - ... - -#. Build and activate a bootstrap image specifying a kernel flavor: - - .. code-block:: console - - $ fuel-bootstrap --verbose --debug build --label 'with_wily_kernel' --activate --kernel-flavor linux-image-generic-lts-wily - -#. Reboot the discovered node: - - .. code-block:: console - - $ ssh 10.109.0.3 - -#. Verify if the node applied the kernel succesfully: - - #. View infomation about the installed kernel image: - - .. code-block:: console - - # dpkg -l | grep wily - - **System response:** - - .. code-block:: console - - ii linux-image-generic-lts-wily 4.2.0.27.21 amd64 Generic Linux kernel image - - #. View infomation about the current kernel: - - .. code-block:: console - - # uname -a - - **System response:** - - .. code-block:: console - - Linux bootstrap 4.2.0-27-generic #32~14.04.1-Ubuntu SMP Fri Jan 22 15:32:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux - - -Install an old kernel ---------------------- - -For code stability, security, or other reasons, you may not want to install -the latest kernel as described above. - -.. note:: - - Due to a specific logic of ``apt-get upgrade\dist-upgrade`` system, - an old kernel cannot be installed as easily as the latest one. - -**To install an old version of kernel:** - -#. Verify the version of ``lts-vivid`` meta-package: - - .. code-block:: console - - apt-cache show linux-image-generic-lts-vivid | grep -i Depends - - **Example of system response:** - - .. code-block:: console - - Depends: linux-image-3.19.0-47-generic, linux-image-extra-3.19.0-47-generic, linux-firmware - -#. Prepare a bash script with the kernel version you want to install. - For example: - - .. code-block:: console - - $ cat /root/user_script.sh - - **System response:** - - .. code-block:: console - - #!/bin/bash - - echo "START user-script" - apt-get remove -y linux-image-generic-lts* linux-image-* - apt-get purge -y linux-image-generic-lts* linux-image-* - - rm -f /boot/vmlinuz* - rm -f /boot/initrd* - - apt-get install -y linux-image-3.19.0-25-generic linux-image-extra-3.19.0-25-generic - echo "END user-script" - - This bash script installs the ``linux-image-3.19.0-25-generic`` kernel. - -#. Build and activate a bootstrap image including the custom script you created before: - - .. code-block:: console - - $ fuel-bootstrap build --verbose --debug --activate --label 'old_kernel' --script /root/user_script.sh - - **System response:** - - .. code-block:: console - - ... - Copy user-script /root/user_script.sh into chroot:/tmp/tmplGugKE.fuel-agent-image - Make user-script /tmp/tmplGugKE.fuel-agent-image/user_script.sh executable - Trying to execute command: chroot /tmp/tmplGugKE.fuel-agent-image /bin/bash -c /user_script.sh - ... - Bootstrap image 244782c1-7343-43f7-9ee3-8989c252eb2e has been built - ... - Bootstrap image 244782c1-7343-43f7-9ee3-8989c252eb2e has been activated. - -#. Reboot the discovered node: - - .. code-block:: console - - $ ssh 10.109.0.3 - -#. Verify if the node applied the kernel succesfully: - - #. View infomation about the current kernel: - - .. code-block:: console - - # uname -a - - **System response:** - - .. code-block:: console - - Linux bootstrap 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux - - #. View infomation about the installed kernel image: - - .. code-block:: console - - # dpkg -l | grep image - - **System response:** - - .. code-block:: console - - ii linux-image-3.19.0-25-generic 3.19.0-25.26~14.04.1 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP - ii linux-image-extra-3.19.0-25-generic 3.19.0-25.26~14.04.1 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP - - #. Verify that the ``runtime_uuid`` value of the activated bootstrap image - has been updated in the ``nailgun-agent`` configuration file: - - .. code-block:: console - - # cat /etc/nailgun-agent/config.yaml - - **System response:** - - .. code-block:: console - - {runtime_uuid: 244782c1-7343-43f7-9ee3-8989c252eb2e} diff --git a/userdocs/fuel-install-guide/bootstrap/bootstrap_select.rst b/userdocs/fuel-install-guide/bootstrap/bootstrap_select.rst deleted file mode 100644 index ab397773b..000000000 --- a/userdocs/fuel-install-guide/bootstrap/bootstrap_select.rst +++ /dev/null @@ -1,55 +0,0 @@ -.. _bootstrap_select: - -Select a bootstrap image ------------------------- - -You can select a bootstrap image from the list of available -bootstraps and activate it. The discovered nodes will be loaded -with a new bootstrap after reboot. - -**To switch between bootstrap images:** - -#. Print the list of available bootstrap images: - - .. code-block:: console - - # fuel-bootstrap list - - **System response** - - .. code-block:: console - - +--------------------------------------+--------------------------------------+--------+ - | uuid | label | status | - +--------------------------------------+--------------------------------------+--------+ - | a778efad-88ca-41fe-b592-f02101c11d22 | bs1 | | - | 244782c1-7343-43f7-9ee3-8989c252eb2e | bs2 | active | - | 2b7fe334-4ef7-4a9d-8fcb-e0d7cc009d0c | 2b7fe334-4ef7-4a9d-8fcb-e0d7cc009d0c | | - | centos | deprecated | | - +--------------------------------------+--------------------------------------+--------+ - -#. Activate a new bootstrap image: - - .. code-block:: console - - # fuel-bootstrap activate a778efad-88ca-41fe-b592-f02101c11d22 - -#. Reboot the affected node: - - .. code-block:: console - - # fuel nodes - - **System response** - - .. code-block:: console - - +-------------------------------------------------------------------------------------------------------------+ - |id | status | name | cluster | ip | mac | roles | pending_roles | online | - |---|----------|------------------|---------|------------|-------------------|-------|---------------|--------| - |1 | discover | Untitled (29:bb) | None | 10.109.0.3 | 64:26:37:0b:29:bb | | | True | - +-------------------------------------------------------------------------------------------------------------+ - - .. code-block:: console - - # ssh 10.109.0.3 reboot diff --git a/userdocs/fuel-install-guide/bootstrap/bootstrap_troubleshoot.rst b/userdocs/fuel-install-guide/bootstrap/bootstrap_troubleshoot.rst deleted file mode 100644 index d63a4ade6..000000000 --- a/userdocs/fuel-install-guide/bootstrap/bootstrap_troubleshoot.rst +++ /dev/null @@ -1,138 +0,0 @@ -.. _bootstrap_troubleshoot: - -Troubleshoot custom bootstrap building --------------------------------------- - -**Automatic Fuel deployment has failed** - -Automatic bootstrap image building can fail with one of the -following error messages: - -.. code-block:: console - - "WARNING: Ubuntu bootstrap build has been skipped. - Please build and activate bootstrap manually with CLI command - `fuel-bootstrap build --activate`. - While you don't activate any bootstrap - new nodes cannot be discovered - and added to cluster. - For more information please visit - http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/bootstrap/bootstrap_troubleshoot.html" - -or - -.. code-block:: console - - WARNING: Failed to build the bootstrap image, see - /var/log/fuel-bootstrap-image-build.log - for details. Perhaps your Internet connection is broken. Please fix the - problem and run `fuel-bootstrap build --activate`. - While you don't activate any bootstrap - new nodes cannot be discovered - and added to cluster. - For more information please visit - http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/bootstrap/bootstrap_troubleshoot.html" - - -You typically receive such error messages when software -repositories are unavailable. - -To resolve the issue: - -* If the Fuel Master node has an Internet connection, - verify network connectivity to the software repositories. - -* If you use a local repository mirror: - - * Follow the instructions provided in the ``fuel-mirror`` - utility https://github.com/openstack/fuel-mirror - * Additionally, analyze the following log files: - - - ``/var/log/fuel-bootstrap-image-build.log`` - - ``/var/log/puppet/bootstrap_admin_node.log`` - - -**A node has an old ``cmdline`` or a wrong bootstrap image** - -``fuel-bootstrap`` has a limitation with UX issue. -You can not change a bootstrap image on nodes already added -to an environment (serialized). -This issue relates to the current architecture restriction. - -The problem may occur under the following conditions: - -* You have a deprecated CentOS bootstrap image in the ``active`` state; or - you power on nodes before the Fuel Master node is completely deployed - when ``ubuntu-bootstrap`` on the Fuel Master node has not been activated yet. - -* You start a node and add it to an OpenStack environment, or - you start or reset deployment on an environment, or any other case - that triggers Fuel to store a node and create a cobbler system. - - .. code-block:: console - - cobbler system report --name default |grep -i Profile - - **System response:** - - .. code-block:: console - - Profile : bootstrap - -* Fuel (Сobbler) creates a system with the CentOS bootstrap image. - - .. code-block:: console - - $ cobbler system report --name node-1 - - **System response:** - - .. code-block:: console - - ... - Profile : bootstrap (centos-bootstrap) - ... - -* Then, you change the active bootstrap, which makes - astute change the cobbler default profile to ``ubuntu-bootstrap``: - - .. code-block:: console - - $ cobbler system report --name default |grep -i Profile - - **System response:** - - .. code-block:: console - - Profile : ubuntu_bootstrap - - But the stored system still use the old bootstrap data. - -**To enable the new bootstarp image:** - -#. Remove the node from db, reboot, and re-discover it - - .. warning:: - - All node data will be destroyed! - - .. code-block:: console - - # fuel node --node-id 1 --delete-from-db - -#. Manually update the cobbler profile: - - .. note:: - - No data will be destroyed. - - .. code-block:: console - - $ cobbler system edit --name node-1 --profile=ubuntu_bootstrap - $ cobbler system report --name node-1 |grep Profile - - **System response:** - - .. code-block:: console - - Profile : ubuntu_bootstrap - -#. Reboot the node. diff --git a/userdocs/fuel-install-guide/bootstrap/bootstrap_view.rst b/userdocs/fuel-install-guide/bootstrap/bootstrap_view.rst deleted file mode 100644 index f35c06dc9..000000000 --- a/userdocs/fuel-install-guide/bootstrap/bootstrap_view.rst +++ /dev/null @@ -1,59 +0,0 @@ -.. _bootstrap_view: - -View available bootstraps -------------------------- - -You can view bootstrap images available in your system. - -#. Each bootstrap image has a unique ID which identifies it: - - .. code-block:: console - - $ fuel-bootstrap list - - **System response:** - - .. code-block:: console - - +--------------------------------------+--------------------------------------+--------+ - | uuid | label | status | - +--------------------------------------+--------------------------------------+--------+ - | 2b7fe334-4ef7-4a9d-8fcb-e0d7cc009d0c | 2b7fe334-4ef7-4a9d-8fcb-e0d7cc009d0c | active | - | centos | deprecated | | - +--------------------------------------+--------------------------------------+--------+ - -#. To check, which exactly bootstrap image is currently loaded on a discovered node: - - .. code-block:: console - - # fuel nodes - - **System response:** - - .. code-block:: console - - id | status | name | cluster | ip | mac | roles | pending_roles | online | group_id - ---|----------|------------------|---------|------------|-------------------|-------|---------------|--------|--------- - 1 | discover | Untitled (29:bb) | None | 10.109.0.3 | 64:26:37:0b:29:bb | | | True | None - - -#. Connect to a node by SSH and check the file: - - .. code-block:: console - - ssh 10.109.0.3 cat /etc/nailgun-agent/config.yaml - - **System response:** - - .. code-block:: console - - {runtime_uuid: 2b7fe334-4ef7-4a9d-8fcb-e0d7cc009d0c} - -#. You can use Fuel web UI as well: - - * Go to ``Nodes`` tab of your environment. - * Locate the node and click on ``gear`` button in front of the node name. - * Expand the ``System`` tab and find ``runtime uuid`` record. - -As you can see, Fuel loaded the discovered node with the bootstrap image marked -as ``Active`` in the bootstrap list. diff --git a/userdocs/fuel-install-guide/bootstrap_intro.rst b/userdocs/fuel-install-guide/bootstrap_intro.rst deleted file mode 100644 index 858d848e1..000000000 --- a/userdocs/fuel-install-guide/bootstrap_intro.rst +++ /dev/null @@ -1,28 +0,0 @@ -.. _install_configure_bootstrap: - -Configure a bootstrap image -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can build a custom Ubuntu bootstrap image with -the Fuel bootstrap builder that Fuel Master will use -to boot Fuel Slave nodes. - -You can include additional packages, custom drivers, and even -change the default Ubuntu kernel to be deployed on Fuel Slave nodes. - -This section includes the following topics: - -.. toctree:: - :maxdepth: 2 - - bootstrap/bootstrap_builder - bootstrap/bootstrap_container - bootstrap/bootstrap_view - bootstrap/bootstrap_select - bootstrap/bootstrap_add_package - bootstrap/bootstrap_install_kernel - bootstrap/bootstrap_inject_cert - bootstrap/bootstrap_inject_driver - bootstrap/bootstrap_debug - bootstrap/bootstrap_troubleshoot - diff --git a/userdocs/fuel-install-guide/install/install_before_you_install_fuel.rst b/userdocs/fuel-install-guide/install/install_before_you_install_fuel.rst deleted file mode 100644 index 38b4f5419..000000000 --- a/userdocs/fuel-install-guide/install/install_before_you_install_fuel.rst +++ /dev/null @@ -1,38 +0,0 @@ -.. _install_before_you_install_fuel: - -Before you install Fuel ------------------------ - -Before you install Fuel, verify that you have completed the following tasks: - -#. Read and complete the tasks described in the following sections: - -* :ref:`intro_install_overview` -* :ref:`sysreq_intro` - -#. If you use bare-metal hardware, set up and connect all hardware. -#. If you use virtual hardware, configure all required virtual machines, - network, and storage parameters. -#. Select a workflow: - -* If you install Fuel on a server with an Internet connection, follow this - workflow: - -.. image:: /_images/deliverables/d_install_w_internet.png - :width: 70% - :align: center - -* If you install Fuel on a server without an Internet connection, you must - configure a local repository and modify the default Fuel repositories, so - that Fuel installs the operating system packages from the local - repositories. Therefore, follow this workflow: - -.. image:: /_images/deliverables/d_install_wo_internet.png - :width: 70% - :align: center - -* If you install Fuel from on of RPM mirrors, follow this workflow: - -.. image:: /_images/deliverables/d_install_rpm.png - :width: 70% - :align: center diff --git a/userdocs/fuel-install-guide/install/install_boot_slave_nodes.rst b/userdocs/fuel-install-guide/install/install_boot_slave_nodes.rst deleted file mode 100644 index ca43b34e1..000000000 --- a/userdocs/fuel-install-guide/install/install_boot_slave_nodes.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _install_boot_nodes: - - -Boot the Fuel Slave nodes -------------------------- - -Before you boot the Fuel Slave nodes, verify that you have completed -the following tasks: - -#. :ref:`Install the Fuel Master node `. - -#. If you plan using RAID arrays, configure you RAID-attached devices first. - -#. Configure the network: - - * If you use bare-metal servers, verify that the Fuel Slave nodes are - physically connected to the same network as the Fuel Master node. - - * If you use virtual servers, verify that the Fuel Slave nodes - are bridged to the same network as the Fuel Master node. - The Fuel Master node and the Fuel Slave nodes must be in - the same L2 network segment. - -**To boot the Fuel Slave nodes:** - -#. Power on a Fuel Slave node. - -#. Boot the Fuel Slave node through PXE using one of the following options: - - * Modify the boot order in BIOS to PXE boot. - * Press the appropriate key to initiate a PXE boot. - - .. warning:: - - If the Fuel Slave node has several network interfaces, enable - the PXE boot on the interface that is on the same network - as Admin (PXE) network on the Fuel Master node. - -#. Repeat the procedure for all the Fuel Slave nodes you will use for your - OpenStack environment. - -Boot workflow of a Fuel Slave node -++++++++++++++++++++++++++++++++++ - -The boot workflow of a Fuel Slave node does not require any user interaction. -For general understanding of the processes that take place in the system when -the Fuel Slave node is booting, get acquainted with the boot procedure: - -#. The Fuel Slave node sends out a DHCP discovery request and gets the response - from the Fuel Master node that runs the DHCP server. - -#. On receiving the response, the Fuel Slave node fetches the PXELINUX - bootloader and the bootstrap image from the Fuel Master node's TFTP - server, and boots into it. - -#. On loading the image, the Fuel Slave node reports readiness and - configuration to the Fuel Master node. - -The number of discovered Fuel Slave nodes appears in the Fuel web UI. -When all nodes boot, you can create an OpenStack environment. - -.. seealso:: - - - *Create an OpenStack Environment* in *Fuel User Guide* - diff --git a/userdocs/fuel-install-guide/install/install_change_network_interface.rst b/userdocs/fuel-install-guide/install/install_change_network_interface.rst deleted file mode 100644 index 188a1a1ee..000000000 --- a/userdocs/fuel-install-guide/install/install_change_network_interface.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. _install_change_admin_network_interface: - -Change the Admin (PXE) network interface ----------------------------------------- - -By default, Fuel assigns ``eth0`` as a network interface for the Admin (PXE) -network. If you want to use the default network settings, skip this section. - -However, some environments may require you to configure other network -interfaces for the Admin (PXE) network. If you plan to use a network interface -that is differnt from the default setting, change it before you install the -Fuel Master node. - -.. warning:: - Do not change the network interface assigned for the Admin (PXE) network - after you install the Fuel Master node. - -**To change the Admin (PXE) network interface:** - -#. In the Fuel Setup screen, select **Network Setup**. -#. Select ``eth0``. -#. Change **Enable interface** to **No**. -#. Click **Apply**. - - Fuel disables ``eth0``. - -#. Select a network interface that you want to use for Admin (PXE) network - traffic. - - For example: ``eth1``. - -#. Change **Enable interface** to **Yes**. -#. Configure network parameters for ``eth1``. - - Default network parameters are: - - * IP address: 10.20.0.2 - * Netmask: 255.255.255.0 - * Gateway: 10.20.0.1 - -#. Click **Apply**. - - Fuel will now use ``eth1`` as a network interface for the Admin (PXE) - network. - -#. In Menu, select **PXE Setup**. -#. Set the DHCP pool range and gateway. -#. Verify your configuration by clicking **Check**. -#. Proceed to :ref:`install_login_fuel_master_node`. - -.. seealso:: - - - :ref:`install_configure_a_network_interface_for_fuel_web_ui` - - -.. _install_configure_a_network_interface_for_fuel_web_ui: - -Configure a network interface for the Fuel web UI -------------------------------------------------- - -You can configure a specific network interface through which users will access -the Fuel web UI. - -**To configure a network interface for the Fuel web UI:** - -#. In the Fuel Setup screen, select **Network Setup**. -#. Select an unassigned network interface. -#. Change **Enable interface** to **Yes**. -#. Enable DHCP. -#. Verify that the IP address, netmask, and gateway fields are empty. -#. Click **Apply**. - - Fuel now uses the selected interface for the Fuel web UI. - -#. Proceed to :ref:`install_login_fuel_master_node`. - -.. seealso:: - - - :ref:`install_login_fuel_master_node_multiple_nics` diff --git a/userdocs/fuel-install-guide/install/install_download_iso.rst b/userdocs/fuel-install-guide/install/install_download_iso.rst deleted file mode 100644 index 7b99b8591..000000000 --- a/userdocs/fuel-install-guide/install/install_download_iso.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. _install_download_iso: - -Download the ISO image ----------------------- - -The Fuel ISO image includes Fuel software components, as well as the -latest release of OpenStack which is required to create your OpenStack -environment. Therefore, if you use Fuel, you do not need to download any -additional OpenStack components. - -However, the Fuel ISO does not include the operating system packages. The Fuel -Master node dynamically downloads the packages from the configured software -repository. - -**To download the ISO image:** - -#. Go to the `Fuel project page `_. -#. Download the ISO to your computer. -#. Proceed to :ref:`install_prepare_install_media`. - diff --git a/userdocs/fuel-install-guide/install/install_install_fuel_master_node.rst b/userdocs/fuel-install-guide/install/install_install_fuel_master_node.rst deleted file mode 100644 index fcba74f2c..000000000 --- a/userdocs/fuel-install-guide/install/install_install_fuel_master_node.rst +++ /dev/null @@ -1,60 +0,0 @@ -.. _install_install_fuel_master_node: - -Install the Fuel Master node ----------------------------- - -Before you install the Fuel Master node, complete the steps described in -:ref:`Before you install Fuel `, - -If you choose installation using pre-built ISO image, you also need -to complete the steps described here -:ref:`Download the ISO image `, and -:ref:`Preparing an installation media `. - -and then start the Fuel Master node installation process as follows: - -#. Insert or mount through IPMI (or using any other remote control utility - supported by your hardware) the media with the Fuel ISO on the server - that will be your Fuel Master node. - -#. Verify that the Fuel installation media is the first device in the boot - order. - -#. Power on the server. The `Welcome to Fuel Installer` screen appears. - -#. Select the installation media. If necessary, modify the boot settings by - pressing the Tab key to display the loader command line. Using this command - line, configure the IP address, default gateway, and DNS server settings of - the Fuel Master node. - -#. Proceed to :ref:`Configure network parameters `. - -If you choose installation using RPM packages then follow the procedure -described here - -#. Install CentOS 7 on the node you assume to be the Fuel Master node as - described in the official CentOS documentation - -#. Install some additional packages that are necessary:: - sudo yum install -y PyYAML net-tools - -#. Install fuel-release RPM package from one of the Fuel mirrors:: - sudo rpm -i http://packages.fuel-infra.org/repositories/centos/master-centos7/os/x86_64/Packages/fuel-release-10.0.0-1.mos6376.git.a8c98d0.noarch.rpm - -.. note:: - - Due to version part of the package name particular URL can differ - from what is written here in the documentation. - -#. Install fuel-setup package:: - sudo yum install -y fuel-setup - -#. Run the Fuel bootstrap script:: - sudo /usr/sbin/bootstrap_admin_node.sh - -#. Proceed to :ref:`Fuel setup configuration `. - -.. note:: - - You can install the Fuel Master node on VMware vSphere. For more information, - see: :ref:`Before you install Fuel on VMware vSphere `. diff --git a/userdocs/fuel-install-guide/install/install_login_fuel_master_node.rst b/userdocs/fuel-install-guide/install/install_login_fuel_master_node.rst deleted file mode 100644 index 7d6ad26fe..000000000 --- a/userdocs/fuel-install-guide/install/install_login_fuel_master_node.rst +++ /dev/null @@ -1,84 +0,0 @@ -.. _install_login_fuel_master_node: - -Log in to the Fuel Master node ------------------------------- - -When Fuel completes the installation of the Fuel Master node, the Fuel Master -node boots automatically and the *Welcome to the Fuel server* message displays. -The message contains Fuel web UI and Fuel command-line interface default login -credentials. - -.. warning:: - - Remove the installation media before booting the system. - You may damage or delete the entire environment - by booting the installation media once again accidentally. - This is especially important if you set the boot order - so that the USB or DVD drive boots before the hard disk. - -Log in to the Fuel Master node for further configuration using one of -the following options: - -* Log in to the Fuel web UI. -* Log in to the Fuel CLI. - -You can perform most of the operations in both Fuel web UI and Fuel CLI. -However, for your convenience, we recommend that you use the Fuel web UI for -initial configuration. - -**To log in to the Fuel web UI:** - -#. In a web browser, type the IP address and port number that you have - assigned for the Fuel web UI in :ref:`Set up Fuel `. - - Fuel prompts you for the login credentials. - -#. In a web browser, enter the Fuel UI login and password that you have - set for the Fuel web UI in :ref:`Set up Fuel `. - - If you use the default network settings, use the following values: - - * IP address: ``https://10.20.0.2:8443/`` - * Fuel UI login: ``admin`` - * Fuel UI password: ``admin`` - - .. note:: - - The IP address must be reachable from the machine on which you open - the Fuel web UI URL. - - .. warning:: - - For security reasons, change the default credentials for - the administrator account. - - The Fuel web UI initial screen displays. - -#. Proceed to :ref:`Boot the Fuel Slave nodes `. - -**To log in to the Fuel CLI:** - -#. In the Fuel Master node console, type the root login and password that you - have assigned in :ref:`Set up Fuel `. - - If you use the default settings, type the following login credentials: - - * Login: ``root`` - * Password: ``r00tme`` - - You can change the password using the :command:`passwd` command after - you log in. - - .. warning:: - - For security reasons, change the default credentials for the root - account. - -#. Alternatively, connect to the Fuel Master node using SSH. - -#. Proceed to :ref:`Boot the Fuel Slave nodes `. - -.. seealso:: - - - :ref:`Log in to the Fuel Master node with multiple NICs ` - - :ref:`update_fuel` \ No newline at end of file diff --git a/userdocs/fuel-install-guide/install/install_login_fuel_master_node_multiple_nics.rst b/userdocs/fuel-install-guide/install/install_login_fuel_master_node_multiple_nics.rst deleted file mode 100644 index b70599a44..000000000 --- a/userdocs/fuel-install-guide/install/install_login_fuel_master_node_multiple_nics.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _install_login_fuel_master_node_multiple_nics: - -Log in to the Fuel Master node with multiple NICs -------------------------------------------------- - -If the server on which the Fuel Master node is installed has more than one -network interface card (NIC), you can access the Fuel web UI with a particular -NIC. - -**To access the Fuel web UI with a particular NIC:** - -#. Connect the NIC to the appropriate switch. -#. On the Fuel Master node, set an IP address for the NIC. -#. Use the IP address that you assigned to log in to the Fuel web UI. - For example: ``https://IP_YOU_ASSIGN:8443/`` - -.. note:: - - The tasks above do not change the default administrator network settings. - You can access the Fuel web UI using the URL displayed on the Fuel boot - screen. - -.. seealso:: - - - :ref:`install_login_fuel_master_node` - - :ref:`update_fuel` \ No newline at end of file diff --git a/userdocs/fuel-install-guide/install/install_prepare_install_media.rst b/userdocs/fuel-install-guide/install/install_prepare_install_media.rst deleted file mode 100644 index 69446a0ef..000000000 --- a/userdocs/fuel-install-guide/install/install_prepare_install_media.rst +++ /dev/null @@ -1,85 +0,0 @@ -.. _install_prepare_install_media: - -Prepare an installation media ------------------------------ - -After downloading the :ref:`Fuel ISO image `, you must -prepare the installation media by mounting the ISO or burning a DVD/USB -drive. - - -.. _install_create_dvd: - -Create a DVD drive ------------------- - -You can create a DVD with the Fuel ISO to install Fuel on a virtual or -bare-metal hardware. - -**To create a DVD drive:** - -#. Select from the following options: - - * For a remote installation, use a remote control utility to mount the - ISO image directly to the server's virtual DVD drive. For example: - - * `IPMItool `_ - * HP Integrated Lights Out (iLO) - * Dell iDRAC - - * For a bare-metal installation, burn the ISO image to a DVD drive using any - standard software. For example: - - - *Linux*: - - * `Xfburn `_ - * `Brasero `_ - - - *Mac OS X*: - - * Disk Utility (a commonly pre-installed application) - * `Burn `_ - - - *Windows*: - - * `ImgBurn `_ - * `InfraRecorder `_ - -#. Proceed to the - :ref:`Fuel Master node installation `. - - -.. _install_create_usb: - -Create a USB drive with the Fuel ISO on a UNIX system ------------------------------------------------------ - -After downloading the Fuel ISO image, you can use a USB flash drive to -install Fuel on your machine. - -.. note:: Write the Fuel ISO image to the USB drive itself and not to one of - its partitions, if any. For example, if you have a USB ``/dev/sdc`` with - the ``/dev/sdc1`` and ``/dev/sdc2`` partititions, write the ISO to - ``/dev/sdc``. - -**To create a USB drive on a UNIX system:** - -#. Plug in a USB drive to your machine. -#. Run the following command: - - .. code-block:: console - - # dd if=/path-to-your-ISO of=/path-to-your-USB - - **Example:** - - .. code-block:: console - - # dd if=/home/user/fuel-isos/fuel-9.0.iso of=/dev/sdc - - .. warning:: This operation wipes all the data you have - on the USB drive and places a bootable Fuel ISO - on it. - -#. Proceed to - :ref:`Install the Fuel Master node `. diff --git a/userdocs/fuel-install-guide/install/install_set_up_fuel.rst b/userdocs/fuel-install-guide/install/install_set_up_fuel.rst deleted file mode 100644 index 9f406c49c..000000000 --- a/userdocs/fuel-install-guide/install/install_set_up_fuel.rst +++ /dev/null @@ -1,135 +0,0 @@ -.. _install_set_up_fuel: - -Set up Fuel ------------ - -During installation, Fuel prompts you to access the Fuel setup screen where you -can modify the default network and authentication parameters. - -.. image:: /_images/deliverables/scr_fuel_setup.png - :width: 60% - :align: center - -Typically, you want to modify network settings to meet the requirements of -your existing network infrastructure. Also, you must change the default Fuel -administrator password. Although you can change some of the network interface -settings after you install the Fuel Master node, we recommend that you -finalize network configuration before you install the Fuel Master node. - -.. warning:: - Do not modify settings of the Admin (PXE) network after you deploy the Fuel - Master node, because Fuel will lose the ability to PXE boot and manage - OpentStack environments. - -If you are installing Fuel for testing purposes, you can keep the default -settings and proceed to :ref:`install_install_fuel_master_node`. - -**To set up Fuel:** - -#. Configure the following settings as required: - - +--------------------------------------+----------------------------------+ - | 1. Change the Fuel administrator | For security purposes, we | - | password. | strongly recommend that you | - | | change the Fuel administrator | - | | password during installation. | - +--------------------------------------+----------------------------------+ - | 2. Modify the network interface | By default, Fuel assigns the | - | settings. | following network parameters to | - | | the Admin (PXE) network | - | | (``eth0``): | - | | | - | | * Subnetwork: 10.20.0.2/24 | - | | * Gateway: 10.20.0.1 | - | | | - | | Modify these settings | - | | according to the requirements of | - | | your existing network | - | | infrastructure. | - +--------------------------------------+----------------------------------+ - | 3. Configure the Admin (PXE) network | By default, Fuel configures the | - | and a DHCP pool for the Fuel Slave| Admin (PXE) network on `eth0` and| - | nodes. | configures the following DHP pool| - | | settings: | - | | | - | | * DHCP pool start: 10.20.0.3 | - | | * DHCP pool end: 10.20.0.254 | - | | * DHCP gateway: 10.20.0.2 | - | | | - | | Modify these settings as needed. | - +--------------------------------------+----------------------------------+ - | 4. Configure the security settings. | By default, SSH access to the | - | | Fuel Master node is restricted | - | | to the Admin (PXE) network. | - | | You can change it, if | - | | needed, by entering a new network| - | | address in the CIDR format. Once | - | | applied, SSH access to the Fuel | - | | Master node will be allowed from | - | | the provided network only. | - +--------------------------------------+----------------------------------+ - | 5. Configure DNS and hostname. | Configure the DNS and hostname | - | | settings, if needed. If your Fuel| - | | Master node is not connected to | - | | the Internet, leave the External | - | | DNS field blank. | - +--------------------------------------+----------------------------------+ - | 6. Configure the bootstrap image that| Fuel ISO includes the CentOS | - | Fuel will use to discover the Fuel| bootstrap image that Fuel uses | - | Slave nodes through PXE. | to discover the Fuel Slave nodes.| - | | Although CentOS is the default | - | | and preferred option, it may not | - | | include drivers for your | - | | hardware, therefore, you may want| - | | to use the Ubuntu bootstrap image| - | | instead. | - | | | - | | Some organizations may | - | | configure the Fuel Master node in| - | | a network protected by a | - | | firewall, | - | | so that the Fuel Master node may | - | | not have an access to the | - | | Internet. In this case, you can | - | | specify a repository located in | - | | the accessible network, HTTP or | - | | HTTPS, by adding proxy | - | | parameters in the Ubuntu | - | | repository field. To configure | - | | the Ubuntu repository mirror | - | | on a local host, use the | - | | ``fuel-mirror`` script | - | | shipped with the Fuel ISO. | - | | | - | | For more information, see: | - | | :ref:`local-repo`. | - +--------------------------------------+----------------------------------+ - | 7. Configure the network time | To avoid issues with the time | - | protocol. | settings inconsistency on the | - | | Fuel Master node and other | - | | servers in your IT environment, | - | | verify that the Fuel Master node | - | | uses correct NTP settings. | - +--------------------------------------+----------------------------------+ - | 8. Change the root password. | For security reasons, change the | - | | default root password. Fuel will | - | | apply this password to all new | - | | OpenStack nodes. Existing | - | | OpenStack nodes will continue to | - | | use the old password. | - +--------------------------------------+----------------------------------+ - | 9. Configure network settings using | You can configure all settings | - | shell. | available on the Fuel Setup | - | | screen using shell. | - | | Particularly, use shell to | - | | apply complex network | - | | configurations. | - +--------------------------------------+----------------------------------+ - -2. Proceed to :ref:`install_install_fuel_master_node`. - -.. seealso:: - - - :ref:`Configure a network interface for the Fuel web UI - ` - - :ref:`Change the Admin (PXE) network interface ` diff --git a/userdocs/fuel-install-guide/install_install_fuel.rst b/userdocs/fuel-install-guide/install_install_fuel.rst deleted file mode 100644 index 7d12f3ec8..000000000 --- a/userdocs/fuel-install-guide/install_install_fuel.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _install_intro: - -Install Fuel -============ - -This section describes how to install Fuel on virtual or -bare-metal hardware. During the installation, you deploy the Fuel Master node -on the selected hardware and boot the servers or virtual machines that are -dedicated as Fuel Slave nodes. However, you do not install an operating -system or OpenStack components on the Fuel Slave nodes just yet. After you -deploy the Fuel Master node, you create an OpenStack environment using the -Fuel web UI or Fuel CLI. The Fuel Master node provisions the dedicated Fuel -Slave nodes with the selected operating system, OpenStack or other -components and roles when you deploy an OpenStack environment. - -If you install Fuel on VMware vSphere, see: :ref:`vsphere_intro`. - -This section includes the following topics: - -.. toctree:: - :maxdepth: 2 - - install/install_before_you_install_fuel - install/install_download_iso - install/install_prepare_install_media - install/install_install_fuel_master_node - install/install_set_up_fuel - install/install_change_network_interface - install/install_login_fuel_master_node - install/install_login_fuel_master_node_multiple_nics - install/install_boot_slave_nodes - -.. seealso:: - - * :ref:`update_fuel` \ No newline at end of file diff --git a/userdocs/fuel-install-guide/intro/intro_fuel_intro.rst b/userdocs/fuel-install-guide/intro/intro_fuel_intro.rst deleted file mode 100644 index 1db4bab48..000000000 --- a/userdocs/fuel-install-guide/intro/intro_fuel_intro.rst +++ /dev/null @@ -1,43 +0,0 @@ -.. _intro_fuel: - -Introduction to Fuel -~~~~~~~~~~~~~~~~~~~~ - -Fuel is an open-source software application that simplifies the deployment of -highly available OpenStack environments, as well as enables you to -manage your OpenStack environments after deployment. - -Fuel provides a web user interface (WUI), as well as a command-line user -interface (CLI) and RESTful API for provisioning, configuration, and -management of OpenStack environments. A link to the Horizon OpenStack -Dashboard appears in the Fuel web UI after you deploy an OpenStack -environment. - -Using Fuel you can: - -- Deploy multiple highly-available OpenStack environments on virtual or bare - metal hardware. - -- Configure and verify network configurations. - -- Test interoperability between the OpenStack components. - -- Easily scale your OpenStack environment by adding and removing nodes. - -Fuel architecture includes: - -Fuel Master node - A server with the installed Fuel application that performs initial - configuration, provisioning, and PXE booting of the Fuel Slave nodes, as - well as assigning the IP addresses to the Fuel Slave nodes. - -Fuel Slave node - In the Fuel project terminology, a generic term that describes a server that - is provisioned by the Fuel Master node. A Fuel Slave node can be a - controller, compute, or storage node, among others. These terms are - interchangeable with the OpenStack terminology. - -.. seealso:: - - - `Fuel Architecture - `_ diff --git a/userdocs/fuel-install-guide/intro/intro_install_overview.rst b/userdocs/fuel-install-guide/intro/intro_install_overview.rst deleted file mode 100644 index c591a82a0..000000000 --- a/userdocs/fuel-install-guide/intro/intro_install_overview.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _intro_install_overview: - -Overview of the installation process -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Deployment of an OpenStack environment requires extensive planning. -To ensure a successful deployment, review and understand the following -requirements and sequence of tasks that you must complete. - -#. Plan your OpenStack environment according to the official OpenStack - guidelines and :ref:`Planning your environment `. - -#. Verify that your environment meets the recommendations in - :ref:`System requirements `. - -#. Verify your hardware using the - :ref:`Hardware checklist `. - -#. Determine whether the server on which you plan to install the Fuel - Master node is connected to the Internet. - - * If the server does not have an Internet - connection, then you must configure a local repository. For more - information, see: :ref:`Set up a local repository `. - -#. If you plan to install Fuel on VMware vSphere, verify that your environment - meets the :ref:`VMware vSphere prerequisites ` - -#. Download and install Fuel as described in :ref:`Install Fuel ` - or if you are installing on VMware vSphere in - :ref:`Install Fuel on VMware vSphere `. - -#. Install the Fuel plug-ins, if needed. See: :ref:`Plug-ins `. - - diff --git a/userdocs/fuel-install-guide/intro/intro_planning_your_environment.rst b/userdocs/fuel-install-guide/intro/intro_planning_your_environment.rst deleted file mode 100644 index 6ecf039a4..000000000 --- a/userdocs/fuel-install-guide/intro/intro_planning_your_environment.rst +++ /dev/null @@ -1,33 +0,0 @@ -.. _intro_planning: - -Planning your environment -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Before you install Fuel and OpenStack, determine what type of -configuration addresses your business needs. You must understand -how OpenStack will integrate and communicate with existing components -in your IT infrastructure, as well as calculate resources required to process -estimated workloads. - -If you are testing Fuel and OpenStack in a lab environment, you can -skip the planning and deploy the default configuration. However, for a -production environment, you must decide on the following: - -* Network topology and IP address management plan -* Storage -* Number, type, and flavor of compute, controller, storage, and other nodes -* Monitoring facilities -* Additional components: Sahara and Murano -* Fuel plug-ins - -This guide explains what OpenStack configurations you can deploy using Fuel, -as well as briefly describes guidelines and examples on how to plan resources -for your environment. However, we recommend that you read `OpenStack -Architecture Design Guide `__, -so you can better estimate your network, storage, and compute requirements. - -.. seealso:: - - - :ref:`System requirements ` - - diff --git a/userdocs/fuel-install-guide/intro_fuel_install_intro.rst b/userdocs/fuel-install-guide/intro_fuel_install_intro.rst deleted file mode 100644 index 5176e187f..000000000 --- a/userdocs/fuel-install-guide/intro_fuel_install_intro.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. raw:: pdf - - PageBreak oneColumn - -.. _intro_fuel_install: - -Introduction to Fuel Installation -================================= - -This section provides an overview of the Fuel installation -process. You can install Fuel either using pre-built ISO image or -using rpm packages available on one of Fuel mirrors. Using ISO -you can install Fuel on a server with an Internet connection or -on a server that is isolated from the Internet for security reasons. -Depending on your choice, the workflow differs. - -This section includes the following topics: - -.. toctree:: - :maxdepth: 3 - - intro/intro_fuel_intro.rst - intro/intro_install_overview - intro/intro_planning_your_environment diff --git a/userdocs/fuel-install-guide/local-repo.rst b/userdocs/fuel-install-guide/local-repo.rst deleted file mode 100644 index e6f463d35..000000000 --- a/userdocs/fuel-install-guide/local-repo.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _local-repo: - -========================= -Set up a local repository -========================= - -Fuel downloads the OpenStack and operating system packages -from the predefined repositories on the Fuel Master node. -If your Fuel Master node does not have an Internet connection, -you must configure a local repository mirror with the required -packages and configure Fuel to use this repository. This -configuration is done using the ``fuel-mirror`` script. - -.. caution:: The ``fuel-createmirror`` script is deprecated. Use - ``fuel-mirror`` instead. - -**To set up a local repository using the Fuel CLI:** - -#. Log in to the Fuel Master node CLI. -#. Create a new local mirror on the Fuel Master node: - - .. code-block:: console - - fuel-mirror create -P PROFILE_NAME -G GROUP - - where ``PROFILE_NAME`` is the name of one of the files without the - ``.yaml`` extension that are provided by the ``fuel-mirror`` package - (``/usr/share/fuel-mirror/*.yaml``). - - **Example:** - - .. code-block:: console - - fuel-mirror create -P ubuntu -G ubuntu - -#. Apply the local mirror to an environment: - - .. code-block:: console - - fuel-mirror apply -P PROFILE_NAME -G GROUP - - You can add the following flags to the :command:`fuel-mirror apply` - command: - - * ``--default`` - to use the new local repository for new environments - by default. - - * ``--replace`` - to use the new local repository instead of the current - ones. Otherwise, the new local repository is merged with the existing - ones. And the current repositories will be overwritten if their - names match the names of the new local repositories. - - For example, to use only the new local repositories by default, run: - - .. code-block:: console - - fuel-mirror apply -G ubuntu -I /usr/share/fuel-mirror/ubuntu.yaml --replace --default - fuel-mirror apply -G mos -I /usr/share/fuel-mirror/ubuntu.yaml --default - -#. Verify that the repository URL is successfully changed using the - :command:`fuel2 release repos list` command. - -.. note:: If you changed the default Fuel root password, add the - ``--fuel-password YOUR_PASSWORD`` flag to the script command. - -About the fuel-mirror script -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The ``fuel-mirror`` script provided with the ``fuel-mirror`` package enables -you to modify the Fuel repository sources through the Fuel CLI. - -* To view help information, type ``fuel-mirror -h``. - -* The script supports running behind an HTTP or HTTPS proxy. - The following environment variable can be set either - system-wide (through ``~/.bashrc``) or in the script configuration file: - - .. code-block:: console - - http_proxy=http://username:password@host:port/ diff --git a/userdocs/fuel-install-guide/plugins/plugins_install_plugins.rst b/userdocs/fuel-install-guide/plugins/plugins_install_plugins.rst deleted file mode 100644 index b3811878d..000000000 --- a/userdocs/fuel-install-guide/plugins/plugins_install_plugins.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. _plugins_install_plugins: - - -Install a Fuel plugin ---------------------- - -The installation procedure is common for all plugins. -For more details about the plugin installation, -see the corresponding plugin documentation. - -**To install a Fuel plugin:** - -#. Install the Fuel Master node as described in - :ref:`Install the Fuel Master node `. - -#. Boot the Fuel Master node as described in - :ref:`Log in to the Fuel Master node `. - -#. Download a plugin from `Fuel Plugins - сatalog `_. - -#. Read a Plugin Guide to learn about prerequisites and limitations. - -#. Define variables with values suitable for your environment to be used - during the plugin installation process or replace them in your command - line when appropriate. - - .. code-block:: console - - export FUEL_PLUGIN_FILE=fuel-plugin.rpm - export FUEL_MASTER_NODE=10.20.0.2 - -#. Copy the plugin to the Fuel Master node. - - .. code-block:: console - - scp ${FUEL_PLUGIN_FILE} root@:${FUEL_MASTER_NODE}:/tmp - -#. Install the plugin by typing: - - .. code-block:: console - - ssh root@:${FUEL_MASTER_NODE} "fuel plugins --install /tmp/${FUEL_PLUGIN_FILE}" - -#. Create an OpenStack environment as described in - `Create a new OpenStack environment` in the `Fuel User Guide`. - -#. After completing the Create a new OpenStack environment wizard, click - :guilabel:`Settings` in the Fuel web UI. - -#. Enable plugin in the Fuel web UI as described in the plugin documentation. - -#. Configure and deploy your environment as described in - `Configure a new environment` in the `Fuel User Guide`. - - -.. seealso:: - - - Fuel plugins CLI - - `Fuel plugins catalog - `__ diff --git a/userdocs/fuel-install-guide/plugins/plugins_overview.rst b/userdocs/fuel-install-guide/plugins/plugins_overview.rst deleted file mode 100644 index aed3148f6..000000000 --- a/userdocs/fuel-install-guide/plugins/plugins_overview.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _plugins_overview: - -Fuel plugins overview ---------------------- - -Fuel provides plugins that you can use to extend the functionality -of your OpenStack environment and enable Fuel to work with various -third-party components and technologies. - -Most of the Fuel plugins are developed by the OpenStack community -members, as well as by the companies who support OpenStack. -The Fuel plugins are distributed free of charge. - -Fuel currently has the following plugins: - -* Networking plugins - Fuel plugins such as Firewall-as-a-Service and VPN-as-a-Service, - as well as plugins that enable Fuel to work with enterprise-grade - SDN and virtual networking. - -* Operations management plugins - Enable Fuel to work with the third-party monitoring tools such as - Zabbix and Grafana. - -* Storage plugins - Extend Fuel functionality by enabling OpenStack to use enterprise-class - storage platforms as a Cinder backend. - -* Compute plugins - Extend the Fuel compute functionality. For example, the XenServer plugin - enables you to use the XenServer hypervisor as a compute provider. - -.. note:: - - You must install all Fuel plugins that affect core Fuel functionality, - such as ML2 drivers, SDN, or storage plugins, before you deploy an - OpenStack environment. Application-level plugins, such as LMA, Zabbix, - and so on can be installed later. - -`Fuel Plugins SDK `__ enables -you to develop virtually any plugin that you need to meet your environment -prerequisites. - - -.. seealso:: - - - `Fuel Plugins catalog `__ diff --git a/userdocs/fuel-install-guide/plugins/plugins_prerequisites.rst b/userdocs/fuel-install-guide/plugins/plugins_prerequisites.rst deleted file mode 100644 index ef15daccd..000000000 --- a/userdocs/fuel-install-guide/plugins/plugins_prerequisites.rst +++ /dev/null @@ -1,17 +0,0 @@ -.. _plugins_prerequisites: - -Prerequisites -------------- - -When planning to deploy an environment with Fuel plugins, consider the -following: - -* If you already have an environment that you want to upgrade, see - *Upgrade Fuel*. -* Install plugin on Fuel 6.1 or later. -* Read additional requirements provided by the selected plugin. - -.. seealso:: - - - `Fuel plugins catalog - `__ diff --git a/userdocs/fuel-install-guide/plugins/plugins_uninstall_upgrade.rst b/userdocs/fuel-install-guide/plugins/plugins_uninstall_upgrade.rst deleted file mode 100644 index 324958c8d..000000000 --- a/userdocs/fuel-install-guide/plugins/plugins_uninstall_upgrade.rst +++ /dev/null @@ -1,29 +0,0 @@ -.. _plugins_upgrade_uninstall_plugin: - - -Uninstall a plugin ------------------- - -Fuel does not support upgrades for plugins. The old plugin versions -may not be compatible with the new version of Fuel. Therefore, you must -uninstall the Fuel plugins before upgrading Fuel. - -**To uninstall a plugin:** - -#. Log in to the Fuel Master node CLI. -#. Create an ``uninstall.sh`` script with the following content:: - - #!/bin/bash - set -eux - echo uninstall > /tmp/myplugin_uninstall - - where ``myplugin`` is the name of your plugin. - -#. Put the ``uninstall.sh`` script in your plugin folder. -#. Type:: - - fuel plugins --remove myplugin - -.. seealso:: - - - `Fuel Plugin Wiki `_ diff --git a/userdocs/fuel-install-guide/plugins/plugins_view_plugins.rst b/userdocs/fuel-install-guide/plugins/plugins_view_plugins.rst deleted file mode 100644 index 24dd6a6a5..000000000 --- a/userdocs/fuel-install-guide/plugins/plugins_view_plugins.rst +++ /dev/null @@ -1,25 +0,0 @@ -.. _plugins_view_plugins: - -View Fuel plugins ------------------ - -You can view the list of installed plugins in the Fuel Web UI, as well as in -the Fuel CLI. - -To view the list of installed plugins using the Fuel Web UI, click the -:guilabel:`Plugins` button. It is located at the top of the screen at the -Fuel level. - -You can find the following information for every plugin: - -* version -* description -* homepage -* authors -* licenses -* releases - -.. seealso:: - - - Fuel plugins CLI - diff --git a/userdocs/fuel-install-guide/plugins_intro.rst b/userdocs/fuel-install-guide/plugins_intro.rst deleted file mode 100644 index f8d90d9a1..000000000 --- a/userdocs/fuel-install-guide/plugins_intro.rst +++ /dev/null @@ -1,22 +0,0 @@ -.. raw:: pdf - - PageBreak oneColumn - -.. _fuel-plugins: - -Fuel Plugins -~~~~~~~~~~~~ - -You can extend Fuel functionality by installing the plugins -that companies and individual contributors develop for Fuel. - -This section includes the following topics: - -.. toctree:: - :maxdepth: 3 - - plugins/plugins_overview - plugins/plugins_prerequisites - plugins/plugins_install_plugins - plugins/plugins_view_plugins - plugins/plugins_uninstall_upgrade diff --git a/userdocs/fuel-install-guide/preinstall/preinstall_hardware_checklist.rst b/userdocs/fuel-install-guide/preinstall/preinstall_hardware_checklist.rst deleted file mode 100644 index b4e253ac0..000000000 --- a/userdocs/fuel-install-guide/preinstall/preinstall_hardware_checklist.rst +++ /dev/null @@ -1,62 +0,0 @@ -.. index:: Hardware configuration, confirm - -.. _preinstall_chklist_hardware_checklist: - -Hardware checklist ------------------- - -Before you install the Fuel Master node, verify that you have configured your -hardware correctly. If you install Fuel on virtual hardware for testing -purposes, skip this section. - -You must configure all items from the list below before you install Fuel. - -**Hardware checklist** - -+--------------------------------------------------------+--------------+ -| Item to confirm | Status [tick | -| | if done] | -+========================================================+==============+ -| The Fuel server has an IPMI or out-of-band management | | -| system that you can access. | | -+--------------------------------------------------------+--------------+ -| The Fuel server hardware can boot the Fuel ISO | | -| from a DVD, USB flash drive, or IPMI remote media. | | -+--------------------------------------------------------+--------------+ -| The server on which you plan to install the Fuel Master| | -| node can access all nodes through the L2 management | | -| network. | | -+--------------------------------------------------------+--------------+ -| The Admin (PXE) network does not have a configured DHCP| | -| server. Fuel acts as a DHCP server for Fuel Slave | | -| nodes configured to boot using PXE. | | -+--------------------------------------------------------+--------------+ -| The Spanning Tree Protocol (STP) is disabled on switch | | -| ports connected | | -| to the node servers’ ports or the switch ports are set | | -| to the edge/portfast mode. The edge/portfast mode is | | -| the preferred configuration. It allows the ports to | | -| forward immediately when they are linked up, but | | -| listens for network loops for 15 seconds. | | -+--------------------------------------------------------+--------------+ -| The switch assigned for the Admin network does not have| | -| any tagged VLANs configured. | | -+--------------------------------------------------------+--------------+ -| The node servers are set to network boot using PXE. | | -+--------------------------------------------------------+--------------+ -| The node servers have hardware virtualization | | -| enabled in BIOS. | | -+--------------------------------------------------------+--------------+ -| You have a method to reboot node servers (remotely or | | -| on-site). | | -+--------------------------------------------------------+--------------+ -| The network equipment supports VLANs. | | -+--------------------------------------------------------+--------------+ -| Your network switches support tagged ports. | | -| You need tagged ports in order to | | -| use Neutron with VLAN segmentation. | | -+--------------------------------------------------------+--------------+ -| You have permit rules on TCP ports 22 and 8000 on the | | -| firewall for the Fuel server’s IP address (to access | | -| the Fuel server from your PC).  | | -+--------------------------------------------------------+--------------+ diff --git a/userdocs/fuel-install-guide/preinstall_intro.rst b/userdocs/fuel-install-guide/preinstall_intro.rst deleted file mode 100644 index 6f7aa269d..000000000 --- a/userdocs/fuel-install-guide/preinstall_intro.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. raw:: pdf - - PageBreak oneColumn - -.. _preinstall_intro: - -Pre-installation checklists -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Before you install Fuel, verify that you configured your -environment for the installation. - -This section includes the following topics: - -.. toctree:: - :maxdepth: 3 - - preinstall/preinstall_hardware_checklist diff --git a/userdocs/fuel-install-guide/sysreq/sysreq_additional_components.rst b/userdocs/fuel-install-guide/sysreq/sysreq_additional_components.rst deleted file mode 100644 index 22b313d66..000000000 --- a/userdocs/fuel-install-guide/sysreq/sysreq_additional_components.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. _sysreq_addtional_components: - -Additional components ---------------------- - -If you plan to install additional OpenStack programs, see the system -requirements for additional components: - -* :ref:`sysreq_ironic_prereq` diff --git a/userdocs/fuel-install-guide/sysreq/sysreq_fuel_master_node_hw_requirements.rst b/userdocs/fuel-install-guide/sysreq/sysreq_fuel_master_node_hw_requirements.rst deleted file mode 100644 index 980f50ccd..000000000 --- a/userdocs/fuel-install-guide/sysreq/sysreq_fuel_master_node_hw_requirements.rst +++ /dev/null @@ -1,28 +0,0 @@ -.. _sysreq_master_node_hardware_recs: - -Fuel Master node hardware requirements --------------------------------------- - -When planning hardware for the Fuel Master node, verify that your hardware -meets the following minimum requirements: - -For a production environment: - -* Quad-core CPU -* 4 GB RAM -* 10 Gigabit network port -* Disk size depends on the number of deployed nodes. All nodes send logs - to the Fuel Master node using rsyslog. During installation, Fuel creates - a separate partition for ``/var`` to store the remote logs and allocates 40% - of the disk size to it. Our recommendation for the remote logs partition - is 20 GB per node. If you deploy 10 nodes with Fuel, you need to have a - (20 x 10) x 2.5 = 500 GB disk for the Fuel Master node. -* IPMI access through an independent management network - -For a testing environment: - -* Dual-core CPU -* 2 GB RAM -* 1 Gigabit network port -* 50 GB disk -* Physical console access diff --git a/userdocs/fuel-install-guide/sysreq/sysreq_fuel_master_node_network_reqs.rst b/userdocs/fuel-install-guide/sysreq/sysreq_fuel_master_node_network_reqs.rst deleted file mode 100644 index d9af22a5a..000000000 --- a/userdocs/fuel-install-guide/sysreq/sysreq_fuel_master_node_network_reqs.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. _sysreq_fuel_master_node_network_reqs: - -Fuel Master Node network requirements -------------------------------------- - -To deploy the Fuel Slave nodes on which you will run your Controller, -Compute, Storage or other nodes, the Fuel Master node must have access to the -Internet. - -When you deploy the Fuel Slave nodes, the Fuel Master node connects to the -preconfigured repositories through the Internet and installs the selected -operating system and the OpenStack packages on the nodes. - -For security reasons, you may not want to connect the Fuel Master node to -the Internet. In this case, set up a local repository with the required -installation packages and configure these repositories on the Fuel Master -node. - -.. warning:: You can run only one Fuel Master node in a network set or the - product will behave unexpectedly. - -.. seealso:: - - - :ref:`local-repo` diff --git a/userdocs/fuel-install-guide/sysreq/sysreq_fuel_slave_node_hw_recs.rst b/userdocs/fuel-install-guide/sysreq/sysreq_fuel_slave_node_hw_recs.rst deleted file mode 100644 index 48c064dae..000000000 --- a/userdocs/fuel-install-guide/sysreq/sysreq_fuel_slave_node_hw_recs.rst +++ /dev/null @@ -1,55 +0,0 @@ -.. _sysreq_fuel_slave_node_hw_recs: - -Fuel Slave nodes hardware recommendations ------------------------------------------ - -Determining the appropriate hardware for the slave nodes depends on the node -type, the workloads that you plan to run on the nodes, and whether you combine -different OpenStack components on one node or run them separately. Typically, -you need a two-socket server with the CPU, memory, and disk space that meet -your project requirements. -Read the `OpenStack Architecture Design Guide` for recommendations on how -to plan an OpenStack deployment. - -General guidelines for the Fuel Slave nodes: - -* Controller nodes - Use at least three controller nodes for high availability. - High availability is recommended for all production environments. However, - you can start with a single controller node for testing purposes and add - more nodes later. The controller nodes must form a quorum. Therefore, for - all deployments, the total number of controller nodes must be odd. Further - resource scaling depends on your use case and requires extensive assessment - of your environment and business needs. - -* Compute nodes - The number and hardware configuration of the compute nodes depend on the - following: - - * Number of virtual machines - * Applications that you plan to run on these virtual machines - * Types of workloads - -* Storage nodes - The number and capacity of the storage nodes highly depend on the type of - the storage, redundancy, and workloads that you run on the compute - nodes. Therefore, the storage configuration for every deployment will - vary significantly. - -* Telemetry - MongoDB nodes - Fuel deploys MongoDB version 2.6 with a replica set. To install Telemetry - with the MongoDB database, we recommend that you add three dedicated nodes. - You can also configure one MongoDB role for each controller node. - - Since a MongoDB node is configured in the polling mode, you cannot add - more than seven MongoDB nodes. This is a MongoDB limitation for voting - replica set members, and it is not controlled by Fuel. For more details, - see `MongoDB documenation `_. - -.. seealso:: - - - `OpenStack Architecture Design Guide - `__ - - `OpenStack Operations Guide - `_ - - :ref:`sysreqs_sample_target_node_config` diff --git a/userdocs/fuel-install-guide/sysreq/sysreq_hw_intro.rst b/userdocs/fuel-install-guide/sysreq/sysreq_hw_intro.rst deleted file mode 100644 index 02ac11682..000000000 --- a/userdocs/fuel-install-guide/sysreq/sysreq_hw_intro.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. _sysreq_hw_intro: - -Hardware requirements ---------------------- - -Planning hardware requirements for an OpenStack environment is a complex task -that requires analysis of the applications that you plan to run in your cloud, -as well as understanding how your cloud will expand over time. Therefore, the -hardware requirements for Fuel Slave nodes will differ for each use case. -However, hardware requirements for Fuel Master node are identical for all -deployments. - -.. seealso:: - - - :ref:`sysreq_master_node_hardware_recs` - - :ref:`sysreq_fuel_slave_node_hw_recs` diff --git a/userdocs/fuel-install-guide/sysreq/sysreq_ironic_limitations.rst b/userdocs/fuel-install-guide/sysreq/sysreq_ironic_limitations.rst deleted file mode 100644 index b56c6fd8f..000000000 --- a/userdocs/fuel-install-guide/sysreq/sysreq_ironic_limitations.rst +++ /dev/null @@ -1,63 +0,0 @@ -.. _sysreq_ironic_limitations: - -Bare Metal service limitations ------------------------------- - -When you deploy your environment using Fuel with Ironic, the OpenStack -environment has the following limitations: - -.. list-table:: **Limitation for an OpenStack environment with Ironic** - :widths: 10 25 - :header-rows: 1 - - * - Category - - Description - * - Network - - * Neutron with VLAN segmentation is the only supported networking - option. - * - Storage - - * Ironic does not support attaching or booting from the volumes stored - in Cinder. - - * Ironic requires a swift-compatible object storage. You can use - Swift or RADOS Gateway. - - * - Security - - * No tenant-level network separation is supported for physical machines - on which you deploy instances. All physical machines are visible to - all tenants and to each other on the physical network level. - - * Neutron security groups do not apply to instances deployed on - physical machines. - - * - Virtualization platform - - VMware vCenter as a hypervisor is not supported. - * - Fuel plug-ins - - Ironic supports all Fuel plug-ins as long as their requirements do not - interfere with ironic limitations. For example, if a plug-in requires - you to configure any other networking option but Neutron with VLAN - segmentation, you cannot use this plug-in with ironic. - * - Management - - * Auto-discovery is not supported. - - Ironic cannot automatically discover the physical machines that you - will use to create instances. Therefore, you must have description of - the server hardware available including CPU, RAM, disks, MAC - addresses, and so on to manually discover them. You must also have - information required to configure power and BIOS settings, such as - IPMI address or FQDN, as well as the IPMI user name and password with - administrator privileges for IPMI. - - * Horizon is partially supported. - - Although you can launch an instance on a physical machine using - Horizon, you must perform all other operations with physical nodes - through APIs or CLI. - Many operations that are typically supported for virtual - machines, such as pausing and resuming, are not supported for - physical machines. However, they are still present in the Horizon UI. - - * Only ``admin`` can manage operations with Ironic. - - Only an OpenStack user with the ``admin`` role can operate the - Ironic service. diff --git a/userdocs/fuel-install-guide/sysreq/sysreq_ironic_prereq.rst b/userdocs/fuel-install-guide/sysreq/sysreq_ironic_prereq.rst deleted file mode 100644 index 770d9e4bf..000000000 --- a/userdocs/fuel-install-guide/sysreq/sysreq_ironic_prereq.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _sysreq_ironic_prereq: - -Prerequisites for the OpenStack bare-metal service --------------------------------------------------- - -Before you deploy an OpenStack environment, you must verify that your -environment meets the following network, hardware, and software prerequisites -required to succesfully deploy and use the OpenStack Bare Metal service. - -**Network prerequisites:** - -* Configure a flat network that you will use for the nodes on which you run - ``ironic``. This network will appear as *baremetal* in the Fuel web UI. - -* Prepare the nodes on which you plan to deploy ``ironic`` by configuring the - following: - - * Prepare the *baremetal* network. - - In fuel, the *baremetal* network consists of a virtual subnet range and - a solid subnet range. The virtual subnet range is a part of the OpenStack - Network service and will be mapped to the Fuel private network. Baremetal - servers get their IP addresses from this virtual subnet range in the same - manner as virtual instances. The solid subnet range is similar to the Fuel - management network and is used for communication between Ironic services - (ironic-api, ironic-conductor, ...) and agent that run on baremetal servers. - Therefore, configure the *baremetal* network with care and ensure that the - baremetal servers PXE boot interface are plugged into this network. If you - need to configure this network interface only on some nodes, such as nodes - with ``ironic`` and ``controller`` roles, use network templates. - - * Access to the IPMI network - - Since Ironic provides out-of-band management through Intelligent - Platform Management Interface (IPMI), the nodes on which you deploy - Ironic must have access to the IPMI network with bare-metal servers that - you will use for provisioning. - -* Verify that the network interfaces of the physical servers that connect to - the IPMI network have either static IP addresses or, if you use DHCP, the - DNS service is enabled in the IPMI network and the physical servers have - stable FQDN host names. - -**Hardware prerequisites:** - -Follow the general guidelines for hardware prerequisites described in the -*System Prerequisites* section in the *Fuel Installation Guide*. - -Fuel includes special drivers for Ironic and the default bootstrap images -that Fuel uploads to Glance when you create an OpenStack environment. If you -plan to use these default configurations, the bootstrap images are based on -the image Fuel uses to provision the OpenStack nodes. However, if you plan to -use different drivers and bootstrap images, you must verify that the bootstrap -image contains drivers that support your hardware. - -**Software prerequisites:** - -Each Ironic driver has requirements for the images that you will use to -provision instances on physical machines. If you use default Fuel drivers, see -*Image requirements* in the Fuel User Guide. - -.. seealso:: - - - :ref:`sysreq_ironic_limitations` - - *Using networking templates* in *Fuel User Guide* diff --git a/userdocs/fuel-install-guide/sysreq/sysreq_network_requirements.rst b/userdocs/fuel-install-guide/sysreq/sysreq_network_requirements.rst deleted file mode 100644 index a3f5e0981..000000000 --- a/userdocs/fuel-install-guide/sysreq/sysreq_network_requirements.rst +++ /dev/null @@ -1,167 +0,0 @@ -.. _sysreqs_network_reqs: - -Network requirements --------------------- - -Your OpenStack environment must have an efficient, scalable, and manageable -network infrastructure that addresses your immediate business needs and -future growth. All nodes must communicate with each other through -allocated networks. Network configuration of your Fuel Slave nodes depends -significantly on the network topology that you select. - -Fuel deploys standard network topologies supported by Neutron, as well as -extended Neutron's networking functionality using such plugins as ML2 and so -on. Neutron is a flexible network manager that enables you to create -complex network configurations. Neutron provides both level 2 and 3 -network virtualization, as well as IP address management (IPAM). In addition, -Neutron has multiple open-source and enterprise-class plugins that enable -interoperability with such networking technologies as virtual switches and -software defined networking (SDN). - -.. note:: - Since the introduction of Neutron, nova-network development efforts - have been gradually reduced and may be deprecated in the future - OpenStack releases. Neutron is recommended in all new deployments. - -Fuel can deploy the following Neutron network topologies: - -Neutron with VLAN segmentation - Similar to nova-network VLAN Manager, in Neutron's VLAN segmentation - topology a VLAN is assigned to each tenant. IP subnets and ranges in - different tenants can overlap. This is the default networking option - in Fuel. The disadvantage of this option is that you must configure your - networking equipment, as well as provide the total number of tenants, - before configuring the network. - - If you select Neutron with VLAN segmentation, you must have at least 3 - network interfaces (NICs). - - **Neutron with VLAN segmentation examples:** - - +----------+------------------------+-------------------------+ - | | 3 NICs | 4 NICs | - +----------+------------------------+-------------------------+ - | eth0 | Untagged port for | Port for Administrative | - | | Administrative network | network | - +----------+------------------------+-------------------------+ - | eth1 | Port for the following | Port for the following | - | (br-eth1)| networks: | networks: | - | | | | - | | * Public/Floating | * Public/Floating | - | | * Management | * Management | - | | * Storage | | - +----------+------------------------+-------------------------+ - | eth2 | Port for Private | Port for Private network| - | (br-eth2)| network. The number of | with defined VLAN ID | - | | VLANs depends on the | range | - | | number of tenant | | - | | networks with a | | - | | continuous range. | | - +----------+------------------------+-------------------------+ - | eth3 | N/A | Port for Storage | - | (br-eth3)| | network | - +----------+------------------------+-------------------------+ - -Neutron with tunneling segmentation - You can choose between VXLAN and GRE segmentation, with VXLAN being a - default and preferred option. In both VXLAN and GRE segmentations, - tenant traffic is isolated by encapsulation the traffic in tunnels. - Both VXLAN and GRE segmentation is more flexible in terms of the number - of tenants (supports up to 65534 tenants). Network hardware configuration - is significantly simpler compared to the VLAN segmentation and does not - need to be synchronized with your L2 switch configuration. Both VXLAN - and GRE support subnet overlapping in different tenants. However, the - disadvantage of using GRE segmentation is that GRE encapsulation - decreases the network speed between the instances, as well as increases - the CPU usage on the compute and controller nodes. - - .. note:: - To use VXLAN segmentation, your network hardware must support VXLAN - segmentation. - - You can configure GRE segmentation using CLI. For more information, see: - *Fuel CLI Reference*. - - **Neutron with GRE segmentation examples:** - - +----------+-------------------+-------------------+---------------------+ - | | 2 NICs | 3 NICs | 4 NICs | - +----------+-------------------+-------------------+---------------------+ - | eth0 | Untagged port for | Untagged port for | Untagged port for | - | | Administrative | Administrative | Administrative | - | | network | network | network | - +----------+-------------------+-------------------+---------------------+ - | eth1 | Port for the | Port for the | Port for Management | - | (br-eth1)| following | following | network | - | | networks: | networks: | | - | | | | | - | | * Public/Floating | * Public/Floating | | - | | * Management | * Management | | - | | * Storage | | | - +----------+-------------------+-------------------+---------------------+ - | eth2 | N/A | Port for Storage | Port for Public/ | - | (br-eth2)| | network | Floating network | - +----------+-------------------+-------------------+---------------------+ - | eth3 | N/A | N/A | Port for Storage | - | (br-eth3)| | | network | - +----------+-------------------+-------------------+---------------------+ - - Routing recommendations for Neutron networking topologies: - - * Public network: use the default routing through the router. - * Management network: use management network to access your management - infrastructure (L3 connectivity, if necessary). - * Administrative network or only the Fuel Master node: must have the Internet - access through a dedicated NIC. - * Storage and Private networks (VLANs): isolate from other networks. - -Fuel creates the *default* node network group that includes the Public, -Storage, Management, and Baremetal networks if you installed -the OpenStack Bare Metal service. - -The Private network appears in the Network Settings tab if the -environment networking segmentation type is tunneling segmentation. -It does not appear in the Network Settings tab in case of VLAN segmentation -as it has no L3 settings. - -The Private network will (always) appear in the Node Interfaces Configuration -tab, regardless of the segmentation type. The Private network will always -be accessible through API as well. - -The requirements for Public, Storage, and Management networks are: - -* For Public network - - * Floating IP range must fit into Public network CIDR of any - of the node network groups in the environment and share that - CIDR with Public IP ranges of that network. - * Each deployed Controller node requires one IP address from the Public IP range. - * If you set :guilabel:`Assign public network to all nodes` option - in the Settings tab, then each deployed node requires one IP. - * Virtual IPs and the default gateway require three additional IP addresses for - the environment: two IP addresses for Virtual IPs and one IP address for - the default gateway. - * If the Neutron DVR feature is enabled, the DVR requires one additional IP address - for each Compute node in case you plan to use Floating IPs in the deployment. - * If you install plugins, refer to the plugin guides for Public IP requirements. - -* For Storage and Management networks - - * These are internal networks and, hence, the address range should be private, - not globally routable. - -Neutron L2 and L3 requirements are: - -* Each project's network requires one unique VLAN ID (using VLAN segmentation) or - unique segmentation ID (using GRE or VxLAN) -* Admin project network is isolated from both private and public networks for - security reasons. -* For floating network each defined project, including the Admin project, - requires one IP address from the floating IP address range. - This IP address goes to the virtual interface of the project's virtual router. -* Direct connection to the external network requires one IP address from the - floating IP range for each VM. -* The floating IP address range should not intersect with the Public network - address ranges. -* Specify addresses for the guest OS DNS servers if you do not want to use - the default DNS servers. diff --git a/userdocs/fuel-install-guide/sysreq/sysreq_sample_configuration.rst b/userdocs/fuel-install-guide/sysreq/sysreq_sample_configuration.rst deleted file mode 100644 index 1e68e4f77..000000000 --- a/userdocs/fuel-install-guide/sysreq/sysreq_sample_configuration.rst +++ /dev/null @@ -1,145 +0,0 @@ -.. _sysreqs_sample_target_node_config: - -Sample hardware configuration for Fuel Slave nodes --------------------------------------------------- - -The example provided in this section is a general-purpose medium-size -hardware configuration that you can use for a variety of OpenStack -installations and later moderately scale to accommodate -growing requirements of your environment. - -.. note:: - This example is not a best practice document of how to design an - OpenStack environment. The purpose of the example is to help - OpenStack administrators to understand how to plan an installation - and demonstrate how an OpenStack environment may look. - -The sample OpenStack environment includes: - -+--------------------------+-----------------------------+ -| Number of servers | 12 | -| | The servers include: | -| | | -| | * 1 Fuel Master node | -| | * 3 Controller nodes | -| | * 3 Storage nodes | -| | * 5 Compute nodes | -+--------------------------+-----------------------------+ -| Network | Neutron, using VLAN or GRE | -| | topology | -+--------------------------+-----------------------------+ -| Storage | Ceph as back end for Cinder | -| | Glance and Nova (ephemeral | -| | storage) | -+--------------------------+-----------------------------+ -| Additional Components | No additional components. | -| | If you want to install | -| | Ceilometer with the MongoDB | -| | database, you must add three| -| | more servers. | -+--------------------------+-----------------------------+ - - -.. _sysreqs_sample_target_node_config_controller: - -Controller nodes -++++++++++++++++ - -In this example, we use Ceph as a back end for ephemeral storage. -Therefore, in addition to the basic OpenStack components and a MySQL -database, -controller nodes require sufficient resources to run Ceph monitors. - -Each controller node must include: - -+--------------+-----------------------------------+ -| CPU | 2 CPUs with at least six physical | -| | cores each | -+--------------+-----------------------------------+ -| RAM | * For testing: 2 GB | -| | * For production: | -| | | -| | * 24 GB (minimum) | -| | * 64 GB for deployments of | -| | 1000 VMs or more | -+--------------+-----------------------------------+ -| Network | * For testing: 2 x 1 Gbit/s NICs | -| | * For production: 2 x 10 Gbit/s | -| | NICs | -+--------------+-----------------------------------+ -| Storage | Hardware RAID 1 with at least 1 TB| -| | formatted capacity for the host | -| | host operating system disk | -| | | -| | Larger disks may be warranted | -| | depending on the expected database| -| | and log storage requirements. | -+--------------+-----------------------------------+ - - -.. _sysreqs_sample_target_node_config_compute: - -Compute nodes -+++++++++++++ - -Your virtual machines are hosted on the compute nodes; therefore, -you must allocate enough resources to run these virtual machines. - -Each compute node must include: - -+---------------+----------------------------------+ -| CPU | Dual-socket CPU with a minimum | -| | of 4 cores per socket | -+---------------+----------------------------------+ -| RAM | 64 GB | -+---------------+----------------------------------+ -| Storage | Hardware RAID 1 controller with | -| | at least 500 GB capacity for | -| | the host operating system disk | -+---------------+----------------------------------+ -| Network | * For testing: 2 x 1 Gbit/s NICs | -| | * For production: 2 x 10 Gbit/s | -| | NICs | -+---------------+----------------------------------+ - - -.. _sysreqs_sample_target_node_config_storage: - -Storage nodes -+++++++++++++ - -We recommend that you separate Ceph nodes for scalability and robustness. -The hardware estimate provided below is based on the requirement of 0.5 cores -per Ceph-OSD CPU and 1 GB of RAM per 1 TB of Ceph-OSD space. You can -configure -all Ceph storage and journal hard disks in JBOD (Just a Bunch of Disks) mode -on the RAID controller or plug them directly to the available SATA or SAS -ports -on the mainboard. - -Each storage node must include: - -+------------------------+---------------------------------+ -| CPU | Single-socket CPU with at least | -| | 4 physical cores | -+------------------------+---------------------------------+ -| RAM | 24 GB | -+------------------------+---------------------------------+ -| Storage | RAID 1 controller with at least | -| | 500 GB capacity for the host | -| | operating system disk | -| | | -| | For production installations, | -| | set the Ceph object replication | -| | factor to 3 or greater. | -+------------------------+---------------------------------+ -| Network | * For testing: 2 x 1 Gbit/s NICs| -| | * For production: 2 x 10 Gbit/s | -| | NICs | -+------------------------+---------------------------------+ -| Storage | * 18 TB for Ceph storage | -| | (6 x 3 TB) | -| | * 1-2 x 64 GB SSDs or more, for | -| | the Ceph journal | -+------------------------+---------------------------------+ - diff --git a/userdocs/fuel-install-guide/sysreq/sysreq_storage_reqs.rst b/userdocs/fuel-install-guide/sysreq/sysreq_storage_reqs.rst deleted file mode 100644 index 2b1f19da4..000000000 --- a/userdocs/fuel-install-guide/sysreq/sysreq_storage_reqs.rst +++ /dev/null @@ -1,37 +0,0 @@ -.. _sysreq_storge_reqs: - -Storage requirements --------------------- - -When planning storage for your OpenStack environment, understand the -difference between the two types of storage that OpenStack uses: -persistent and ephemeral. - -The nova-compute service manages ephemeral storage that is used as temporary -storage for the operating system of virtual machine instances. When you -delete an instance, nova-compute deletes the ephemeral storage as well. -If you do not select any additional storage options, the virtual machine -volumes will be stored on the local disks of the compute nodes, in the -virtual storage partition. However, if you enable Ceph RBD back end for -ephemeral volumes, nova-compute stores virtual machine volumes in Ceph. - -Persistent storage is the storage that exists outside an instance, in contrast -to ephemeral storage. - -Fuel deploys storage for the following types of persistent data: - -* Glance, for image data, which can use either Swift or Ceph RBD as a - storage back end. -* Cinder, for block data, which can use either LVM or Ceph RBD as a - storage back end. -* Ceph RadosGW, for object storage, with Ceph RBD as storage back end. - -.. note:: - Fuel plugins may provide additional storage options. For more information, - see the - `OpenStack Driverlog for the Fuel project `_. - -.. seealso:: - - - `Storage Decisions - `_ diff --git a/userdocs/fuel-install-guide/sysreq_intro.rst b/userdocs/fuel-install-guide/sysreq_intro.rst deleted file mode 100644 index 7aa9b744d..000000000 --- a/userdocs/fuel-install-guide/sysreq_intro.rst +++ /dev/null @@ -1,28 +0,0 @@ -.. _sysreq_intro: - -System requirements -~~~~~~~~~~~~~~~~~~~ - -This section describes how to configure hardware nodes to -accommodate your OpenStack workloads. Since there are many possible use cases -for an OpenStack environment, the number and configurations of your servers -will also vary. While this section provides clear hardware requirements for the -Fuel Master node, it can only provide guidelines on how to configure the Fuel -Slave nodes. For reference, a sample hardware configuration of -a medium-sized OpenStack environment is described at the end of this section. - -This section includes the following topics: - -.. toctree:: - :maxdepth: 3 - - sysreq/sysreq_hw_intro - sysreq/sysreq_fuel_master_node_hw_requirements - sysreq/sysreq_fuel_slave_node_hw_recs - sysreq/sysreq_network_requirements - sysreq/sysreq_fuel_master_node_network_reqs - sysreq/sysreq_storage_reqs - sysreq/sysreq_additional_components - sysreq/sysreq_ironic_prereq - sysreq/sysreq_ironic_limitations - sysreq/sysreq_sample_configuration diff --git a/userdocs/fuel-install-guide/update-fuel.rst b/userdocs/fuel-install-guide/update-fuel.rst deleted file mode 100644 index 9031bb51e..000000000 --- a/userdocs/fuel-install-guide/update-fuel.rst +++ /dev/null @@ -1,73 +0,0 @@ -.. _update_fuel: - -============================ -Update Fuel to latest Mitaka -============================ - -A number of the Fuel Newton features are back-ported to Mitaka after -the Fuel Mitaka release. You can update the Fuel Master node to consume -these features. - -**To update the Fuel Master node from the initially released Mitaka to the latest Mitaka version:** - -#. Log in to the Fuel Master node CLI as root. -#. Verify that the update repository, for example, ``mos-update``, is available - in the list of your repositories: - - .. code-block:: console - - cat /etc/yum.repos.d/mos-updates.repo - - If the update repository is unavailable, run: - - .. code-block:: console - - yum-config-manager --add-repo=http://mirror.fuel-infra.org/mos-repos/centos/mos9.0-centos7/updates/x86_64/ - rpm --import http://mirror.fuel-infra.org/mos-repos/centos/mos9.0-centos7/updates/RPM-GPG-KEY-mos9.0 - -#. Clean the YUM cache: - - .. code-block:: console - - yum clean all - -#. Install a code-based integrity check tool Cudet. This tool also includes - the necessary update commands for ``fuel2``: - - .. code-block:: console - - yum install python-cudet - -#. Prepare the Fuel Master node for the Noop run: - - .. code-block:: console - - update-prepare prepare master - - This command installs new ``fuel-nailgun`` and ``fuel-astute`` - packages on the Fuel Master node. Also, it executes Nailgun ``dbsync`` - and restarts the ``astute`` and ``nailgun`` services. - - If any ``fuel-nailgun`` extension is already installed on the Fuel Master node, the - ``update-prepare`` script does not restart the Nailgun services. - You should restart the Nailgun services manually using the following - command: - - .. code-block:: console - - systemctl restart assassind nailgun oswl_flavor_collectord \ - oswl_image_collectord oswl_keystone_user_collectord \ - oswl_tenant_collectord oswl_vm_collectord oswl_volume_collectord \ - receiverd statsenderd - -#. Update the Fuel Master node packages, services, and configuration: - - .. code-block:: console - - update-prepare update master - - .. warning:: During the update procedure, the Fuel Master node services - will be restarted automatically. - - The script calls ``yum update`` and then runs Puppet tasks to update - the Fuel Master node. \ No newline at end of file diff --git a/userdocs/fuel-install-guide/upgrade/upgrade-internals.rst b/userdocs/fuel-install-guide/upgrade/upgrade-internals.rst deleted file mode 100644 index 20b4dcb70..000000000 --- a/userdocs/fuel-install-guide/upgrade/upgrade-internals.rst +++ /dev/null @@ -1,21 +0,0 @@ -.. _upgrade-internals: - -======== -Overview -======== - -The upgrade is implemented with upgrade engines, which are python -modules: - -* **Host system engine:** - - #. Copies new repositories to Fuel Master node. - #. Installs a package and all the required dependencies such as - Puppet manifests, bootstrap images, provisioning images etc. - -* **OpenStack engine:** - - #. Installs all data required for OpenStack patching. - #. Adds new releases using the Nailgun REST API. - This allows the full list of OpenStack releases to be displayed - in the Fuel web UI. diff --git a/userdocs/fuel-install-guide/upgrade/upgrade-liberty.rst b/userdocs/fuel-install-guide/upgrade/upgrade-liberty.rst deleted file mode 100644 index b84da0150..000000000 --- a/userdocs/fuel-install-guide/upgrade/upgrade-liberty.rst +++ /dev/null @@ -1,36 +0,0 @@ -.. _upgrade_liberty: - -============================== -Upgrade Fuel Liberty to Mitaka -============================== - -You can upgrade the Fuel Master node from Liberty to Mitaka. -After you upgrade Fuel, you can only deploy new environments of the -corresponding Fuel version. Environments deployed using older versions -of Fuel will remain operational. - -**To upgrade the Fuel Master node:** - -#. Verify that no installations are in progress in any of your OpenStack - environments. -#. Back up the Fuel Master node as described in :ref:`back-up-fuel`. -#. Power off the Fuel Master node. -#. Restore the Fuel Master node as described in :ref:`restore-fuel`. -#. If you want to use CentOS-based bootstrap, rebuild the bootstrap image: - - .. code-block:: console - - $ octane update-bootstrap-centos - -#. Reboot all nodes that are in the ``Discover`` status. - -When Fuel completes the upgrade procedure, the *New Release available* -message appears in the :guilabel:`Releases` tab. - -Now, you can update to the latest Mitaka version that includes some features -back-ported from Newton after the Mitaka release. - -.. seealso:: - - * :ref:`update_fuel` - * :ref:`install_configure_bootstrap` \ No newline at end of file diff --git a/userdocs/fuel-install-guide/upgrade_intro.rst b/userdocs/fuel-install-guide/upgrade_intro.rst deleted file mode 100644 index 08c52e48a..000000000 --- a/userdocs/fuel-install-guide/upgrade_intro.rst +++ /dev/null @@ -1,21 +0,0 @@ -.. _upgrade_intro: - -============ -Upgrade Fuel -============ - -If you have a functional Fuel installation, you can upgrade the Fuel software -to the latest version without reinstalling your environments. - -This section includes the following topics. - -.. toctree:: - :maxdepth: 1 - - upgrade/upgrade-internals - upgrade/upgrade-liberty - -.. note:: Fuel does not support upgrades for plugins. The old plugin - versions may not be compatible with the new version of Fuel. - Therefore, you must uninstall the Fuel plugins before - upgrading Fuel. See :ref:`plugins_upgrade_uninstall_plugin`. diff --git a/userdocs/fuel-install-guide/vsphere/vsphere_boot_master.rst b/userdocs/fuel-install-guide/vsphere/vsphere_boot_master.rst deleted file mode 100644 index a106aa85c..000000000 --- a/userdocs/fuel-install-guide/vsphere/vsphere_boot_master.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _vsphere_boot_master: - -Boot the Fuel Master node -------------------------- - -#. When the boot menu appears, press the **Tab** key on the keyboard and - modify the last kernel parameter ``showmenu`` to ``yes``. Press **Enter**. -#. Wait for the Fuel Master node installation to complete. - -To access the Fuel Web UI, your browser must have an access -to the Fuel Master node through the IP gateway that is connected -to the Port Group network that you configured in :ref:`vsphere_configure_network`. - -Proceed to :ref:`vsphere_verify_master`. diff --git a/userdocs/fuel-install-guide/vsphere/vsphere_configure_esxi_networking.rst b/userdocs/fuel-install-guide/vsphere/vsphere_configure_esxi_networking.rst deleted file mode 100644 index aae845881..000000000 --- a/userdocs/fuel-install-guide/vsphere/vsphere_configure_esxi_networking.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. _configure_esxi: - -Configure ESXi host networking ------------------------------- - -To integrate OpenStack with VMware vCenter, you must configure the VMware ESXi -host networking. - -**To configure ESXi host networking**: - -#. In VMware vSphere web-client open the ESXi host page. -#. Select **Manage** > **Networking**. -#. Click **Add network**. - The **Add networking** wizard starts. -#. In the **Add Networking** wizard, select the Virtual Machine Port - group. -#. Select the **Virtual Machine Port Group** option - to ensure that the network is created in vSwitch0. -#. Create a network called **br100**. - - .. note:: - You must name the network ``br100``. Otherwise, Fuel will not - be able to communicate with VMware vSphere. - -#. In the VLAN ID field, type a VLAN Tag. -#. Proceed to :ref:`vsphere_upload_iso`. - diff --git a/userdocs/fuel-install-guide/vsphere/vsphere_configure_network.rst b/userdocs/fuel-install-guide/vsphere/vsphere_configure_network.rst deleted file mode 100644 index 412bda5c2..000000000 --- a/userdocs/fuel-install-guide/vsphere/vsphere_configure_network.rst +++ /dev/null @@ -1,39 +0,0 @@ -.. _vsphere_configure_network: - -Configure networks ------------------- - -To enable inter-node communication, you must configure networks on -VMware vCenter. - -Configure a network for Fuel Admin (PXE) traffic -++++++++++++++++++++++++++++++++++++++++++++++++ - -You must configure a network for the Fuel Admin (PXE) traffic -and enable Promiscuous mode. - -**To configure a network for the Fuel Admin (PXE) traffic:** - -#. Go to the vCenter screen. -#. Choose **Hosts**. -#. Select the host on which you want to run the Fuel Master node. -#. Click the **Networking** button. -#. Click the **Add Host Networking** icon. - -Create a vCenter Port Group network -+++++++++++++++++++++++++++++++++++ - -You must create a Port Group with Promiscuous mode. - -**To create a vCenter Port Group network:** - -#. Choose a Port Group connection type. -#. Choose a switch. -#. Name your network and set the VLAN number. This is optional - and depends on your underlying network infrastructure. -#. After the network is created, select the network on the network map; - then click the **Edit Settings** icon. -#. Click **Security**. -#. Verify that the **Promiscuous mode** is set to **Accept**. -#. Click "OK". -#. Proceed to :ref:`vsphere_create_vm`. diff --git a/userdocs/fuel-install-guide/vsphere/vsphere_create_vm.rst b/userdocs/fuel-install-guide/vsphere/vsphere_create_vm.rst deleted file mode 100644 index c626f68d8..000000000 --- a/userdocs/fuel-install-guide/vsphere/vsphere_create_vm.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. _vsphere_create_vm: - -Create the Fuel Master node virtual machine -------------------------------------------- - -You need to create a new virtual machine with a guest -operating system to run the Fuel Master node on it. - -**To create the Fuel Master node virtual machine:** - -#. On the vCenter screen choose **Virtual Machines**. -#. Click **Create a Virtual Machine**. -#. Click **Create a new virtual machine**. - Do not use templates. -#. Name your new VM and select the datacenter where the Fuel ISO is located. -#. Select a compute resource (ESXi host), storage, and compatibility - for the VM. -#. Select a guest operating system. -#. Proceed to: :ref:`vsphere_mount_iso`. diff --git a/userdocs/fuel-install-guide/vsphere/vsphere_install_master.rst b/userdocs/fuel-install-guide/vsphere/vsphere_install_master.rst deleted file mode 100644 index a3726f6fe..000000000 --- a/userdocs/fuel-install-guide/vsphere/vsphere_install_master.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. _vsphere_install_master: - -Install the Fuel Master node on VMware vSphere ----------------------------------------------- -You need to install the Fuel Master node on the created -virtual machine. - -**To install the Fuel Master node on VMware vSphere:** - -#. At the Virtual Machines screen, select the Fuel VM and run it - by clicking the **Power on** icon. -#. Click the **Open a virtual machine console** icon. -#. When the BIOS appears, use the arrow keys on your keyboard - to navigate to the **Boot** tab. Then move the highlighted selection - to the **CD-ROM drive**. -#. Using the **+** button on the keyboard, move the **CD-ROM Drive** item - to the top level. -#. Navigate to the **Exit** tab, choose **Exit Saving Changes**, - and confirm your decision. -#. Proceed to :ref:`vsphere_boot_master`. diff --git a/userdocs/fuel-install-guide/vsphere/vsphere_mount_iso.rst b/userdocs/fuel-install-guide/vsphere/vsphere_mount_iso.rst deleted file mode 100644 index b3c3af40d..000000000 --- a/userdocs/fuel-install-guide/vsphere/vsphere_mount_iso.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. _vsphere_mount_iso: - -Mount the Fuel ISO ------------------- - -You must mount the Fuel ISO to install the Fuel Master node -on the virtual machine. - -**To mount the Fuel ISO:** - -#. For the CD/DVD drive, choose **Datastore ISO File** from - the dropdown menu on the right. -#. Navigate through the datastore and choose the ISO you uploaded earlier. -#. Enable the CD/DVD drive by clicking the **Connect...** checkbox - opposite the drive. -#. Go to the **VM Options** tab and expand the **Boot Options** submenu. -#. Enable the "Force BIOS setup" item. -#. Click **Next**. -#. Verify the new Virtual Machine settings and proceed. -#. Proceed to :ref:`vsphere_install_master`. diff --git a/userdocs/fuel-install-guide/vsphere/vsphere_prereq.rst b/userdocs/fuel-install-guide/vsphere/vsphere_prereq.rst deleted file mode 100644 index e8853cea0..000000000 --- a/userdocs/fuel-install-guide/vsphere/vsphere_prereq.rst +++ /dev/null @@ -1,22 +0,0 @@ -.. _vmware_prereq: - -VMware vSphere prerequisites ----------------------------- - -Before you install Fuel and use your OpenStack environment in intergration -with vSphere, you must configure all components of VMware vSphere. - -.. note:: - - The vCenter Server supported versions are 5.1, 5.5, and 6.0. - -Complete the following steps: - -* Install ESXi. -* Install vCenter. -* Configure vCenter. -* Create Datacenter. -* Create vCenter cluster. -* Add ESXi hosts to clusters in vCenter. - -For more information, see the VMware vSphere documentation. diff --git a/userdocs/fuel-install-guide/vsphere/vsphere_upload_iso.rst b/userdocs/fuel-install-guide/vsphere/vsphere_upload_iso.rst deleted file mode 100644 index 01760c353..000000000 --- a/userdocs/fuel-install-guide/vsphere/vsphere_upload_iso.rst +++ /dev/null @@ -1,17 +0,0 @@ -.. _vsphere_upload_iso: - -Upload the Fuel ISO to the VMware vSphere datastore ---------------------------------------------------- - -You need to download the `Fuel ISO `_ -and upload it do a vSphere datastore. - -**To upload the Fuel ISO to the VMware vSphere datastore:** - -#. Log into the vSphere web client. -#. Click **vCenter**. -#. Go to the Datastores and choose your datastore. -#. Go to the Actions menu and select **Browse Files**. -#. Click the **Upload Files** icon, browse your filesystem, - and select your Fuel ISO. -#. Proceed to :ref:`vsphere_configure_network`. diff --git a/userdocs/fuel-install-guide/vsphere/vsphere_verify_master.rst b/userdocs/fuel-install-guide/vsphere/vsphere_verify_master.rst deleted file mode 100644 index 983ce0b05..000000000 --- a/userdocs/fuel-install-guide/vsphere/vsphere_verify_master.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. _vsphere_verify_master: - -Verify the Fuel Master node operation -------------------------------------- - -You need to verify that the Fuel Master node operates correctly. - -**To verify the Fuel Master node operation:** - -#. Create a new VM on the same ESXi host. -#. Boot the created VM via PXE. - -If the boot is successful, -the "Total nodes" at the top right of the Fuel Web UI will increase -its value after two to five minutes. - -**To verify that the Fuel bootstrap node runs on ESXi:** - -#. Open the node information window in the Fuel Web UI. -#. Verify that the **Manufacturer** field says **VMWARE**. diff --git a/userdocs/fuel-install-guide/vsphere_intro.rst b/userdocs/fuel-install-guide/vsphere_intro.rst deleted file mode 100644 index b20179a2e..000000000 --- a/userdocs/fuel-install-guide/vsphere_intro.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. raw:: pdf - - PageBreak oneColumn - -.. _vsphere_intro: - -Install Fuel on VMware vSphere -============================== - -This section describes how to configure your VMware vSphere environment -to install Fuel. - -This section includes the following topics: - -.. toctree:: - :maxdepth: 3 - - vsphere/vsphere_prereq - vsphere/vsphere_configure_esxi_networking - vsphere/vsphere_upload_iso - vsphere/vsphere_configure_network - vsphere/vsphere_create_vm - vsphere/vsphere_mount_iso - vsphere/vsphere_install_master - vsphere/vsphere_boot_master - vsphere/vsphere_verify_master diff --git a/userdocs/fuel-user-guide.rst b/userdocs/fuel-user-guide.rst deleted file mode 100644 index 8547c6c98..000000000 --- a/userdocs/fuel-user-guide.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. index:: Fuel User Guide - -.. _fuel-user-guide: - -=============== -Fuel User Guide -=============== - -.. toctree:: - :maxdepth: 3 - - fuel-user-guide/introduction.rst - fuel-user-guide/create-environment.rst - fuel-user-guide/configure-environment.rst - fuel-user-guide/install-additional-components.rst - fuel-user-guide/deploy-environment.rst - fuel-user-guide/post-deployment-conf.rst - fuel-user-guide/next-steps.rst - fuel-user-guide/configure-additional-components.rst - fuel-user-guide/verify-environment.rst - fuel-user-guide/manage-environment.rst - fuel-user-guide/maintain-environment.rst - fuel-user-guide/plugins/hot-plugable.rst - fuel-user-guide/file-ref.rst - fuel-user-guide/cli.rst - fuel-user-guide/troubleshooting.rst \ No newline at end of file diff --git a/userdocs/fuel-user-guide/cli.rst b/userdocs/fuel-user-guide/cli.rst deleted file mode 100644 index d2d15119a..000000000 --- a/userdocs/fuel-user-guide/cli.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. _cli: - -Use the Fuel CLI -================ - -The Fuel CLI is a command-line interface for Fuel that installs automatically -when you install Fuel. Using the Fuel CLI you can: - -* Operate your OpenStack environments using Fuel text commands, as well as - using standard Linux commands. -* Apply advanced configurations through configuration files that you cannot - modify using the Fuel Web UI. - -.. warning:: - We recommend using Fuel CLI only to experienced users as it may break - your environment if not used carefully. - -Modifications that you make using the Fuel CLI take precedence over the -settings applied from the Fuel web UI. If a change has been applied using -the Fuel CLI, Fuel displays the corresponding message in the Fuel web UI. - -This section includes the following topics: - -.. toctree:: - :maxdepth: 3 - - cli/cli_comparison_matrix.rst - cli/cli_acronyms.rst - cli/cli_basic_usage.rst - cli/cli_client_config_file.rst - cli/cli_management.rst - cli/cli_environment.rst - cli/cli_provision.rst - cli/cli_deploy.rst - cli/cli_network.rst - cli/cli_network_group.rst - cli/cli_network_template.rst - cli/cli_vip.rst - cli/cli_nodes.rst - cli/cli_node_group.rst - cli/cli_roles.rst - cli/cli_nodes_empty_role.rst - cli/cli_plugins.rst - cli/cli_workflows.rst - cli/cli_config_openstack.rst - cli/cli_config_openstack_services_workflow.rst - cli/cli_change_ip_range.rst - cli/cli_modify_environment.rst - cli/cli_noop.rst - cli/cli_manage_gitrepo.rst - cli/cli_audit_enforce.rst diff --git a/userdocs/fuel-user-guide/cli/cli_acronyms.rst b/userdocs/fuel-user-guide/cli/cli_acronyms.rst deleted file mode 100644 index 6a088ee59..000000000 --- a/userdocs/fuel-user-guide/cli/cli_acronyms.rst +++ /dev/null @@ -1,106 +0,0 @@ -.. _cli-acronyms: - -=========================================== -Interpretation of acronyms in Fuel commands -=========================================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -Fuel CLI commands contain a number of acronyms. For a better understanding of -those, see the example command output below. - -.. note:: Nailgun populates the database - with hardware configuration information - about all the managed nodes it discovers - as well as the configuration and status of each node. - -The :command:`fuel node list` command is used on the Fuel Master node to list out -the current information about the nodes for the environment: - -.. code-block:: console - - [root@fuel ~]# fuel nodes - - id | status | name | cluster | ip | mac | ... - ---|----------|------------------|---------|-----------|-------------------| ... - 4 | ready | Untitled (b0:77) | 1 | 10.20.0.6 | 56:40:fa:cc:cf:45 | ... - 1 | ready | Untitled (ca:9a) | 1 | 10.20.0.4 | ca:03:e6:b1:13:46 | ... - 3 | ready | Untitled (0e:64) | 2 | 10.20.0.7 | 26:1f:eb:91:d8:49 | ... - 2 | ready | Untitled (c1:ef) | 2 | 10.20.0.3 | 22:2a:45:36:5d:42 | ... - 5 | discover | Untitled (e1:c4) | None | 10.20.0.5 | 08:00:27:1a:e1:c4 | ... - - - id | status | name |...| roles | pending_roles | online | group_id - ---|----------|------------------|...|------------|---------------|--------|--------- - 4 | ready | Untitled (b0:77) |...| compute | | True | 1 - 1 | ready | Untitled (ca:9a) |...| controller | | True | 1 - 3 | ready | Untitled (0e:64) |...| compute | | True | 2 - 2 | ready | Untitled (c1:ef) |...| controller | | True | 2 - 5 | discover | Untitled (e1:c4) |...| | | True | None - - -The meaning of these fields is: - -:id: The node identifier, assigned incrementally - when the node is first discovered - (when the Fuel agent - sends its first request to the Fuel Master node). - - This ID is the Primary Key for this record in the database; - it is unique and is never reassigned; - when you delete a node from the environment, - that node's ID is deleted; - the next node added to the environment is assigned - a new ID that is higher than the highest-numbered ID in the database. - -:status: Current state of the node: - - :ready: Node is deployed and provisioned, ready to use - :discover: Node is not deployed and not provisioned - :provisioning: Node is in the process of being provisioned - (operating system is being installed) - :provisioned: Node is provisioned but not deployed - :deploying: Node is being deployed - (OpenStack is being installed and configured) - :error: Deployment/provisiong of the node has failed - -:name: Name of the node as displayed on the screen when you - assign roles. - By default, this is "Untitled" with the final digits - of the MAC address used by the Admin interface for that node. - You can double-click on that title to change the name. - -:cluster: ID of the environment to which the node is assigned. - -:ip: IP address of the admin interface, - which is the IP address for the default route. - -:mac: MAC address of the admin interface, - determined the same way as the IP address. - -:roles: A role of a node; - populated only after deployment. - -The following two columns appear at the right end of this display; -they are not shown here: - -:pending_roles: Before deployment, lists the roles that have been assigned - to this node. When deployment is complete, the contents - of this field are moved to the **roles** column. - - This field can also contain the **primary** value - to indicate that this node is the primary controller node. - The **primary** value is persisted in the database - through the use of the **has_primary** field - in the ``openstack.yaml`` file. - -:online: Status of the node: - - :False: Node is offline. - - :True: Node is available via the Fuel admin network. - -:group_id: The group node identifier. - When you assign roles to your target nodes, - Fuel tries to automatically determine the node's group based on - the DHCP address. diff --git a/userdocs/fuel-user-guide/cli/cli_audit_enforce.rst b/userdocs/fuel-user-guide/cli/cli_audit_enforce.rst deleted file mode 100644 index c30e6c521..000000000 --- a/userdocs/fuel-user-guide/cli/cli_audit_enforce.rst +++ /dev/null @@ -1,33 +0,0 @@ -.. _cli-audit-enforce: - -======================== -Fuel IaC: Audit commands -======================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The following table describes the usage of the :command:`fuel2 audit` -command available in the Fuel CLI. This command is available after you install -the Fuel Infrastructure-as-Code extension. For more information, see: -:ref:`lcm-git-repo`. - -.. list-table:: **Audit commands** - :widths: 7 10 - :header-rows: 1 - - * - Description - - Command - * - Run an audit in an OpenStack environment. - - ``fuel2 audit noop --env || --repo `` - * - List changes in an OpenStack environment. - - ``fuel2 audit list outofsync --task || --env `` - * - Perform an audit, verify changes, and enforce new configuration. - - ``fuel2 audit enforce --env || --repo `` - * - Display the white list for an OpenStack environment. - - ``fuel2 audit whitelist show `` - * - Add a rule to the white list of a specific OpenStack environment. - - ``fuel2 audit whitelist add --task --rule `` - * - Delete a rule or a set of rules from a white list. - - ``fuel2 audit whitelist delete [ ... ]`` - * - Add rules to a white list from a specific ``.yaml`` file. - - ``fuel2 audit whitelist load fromfile `` diff --git a/userdocs/fuel-user-guide/cli/cli_basic_usage.rst b/userdocs/fuel-user-guide/cli/cli_basic_usage.rst deleted file mode 100644 index 89ea43ae2..000000000 --- a/userdocs/fuel-user-guide/cli/cli_basic_usage.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _cli_basic_usage: - -=========== -Basic usage -=========== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -Use the following usage pattern for Fuel commands: - -:: - - fuel [global optional args] [action] - -**Example:** - -:: - - fuel --env-id=1 node set --node-id=1,4,5 --role=controller - -.. list-table:: **Fuel commands parameters** - :widths: 10 10 - :header-rows: 1 - - * - Parameter - - Description - * - ``--env-id=1`` - - A global argument pointing to a specific environment. This is an - optional parameter. - * - ``node`` - - A namespace for all node control functions. - * - ``set`` - - An action that assigns nodes with defined roles to specific - environments. - -To get the list of all global optional arguments and namespaces, run: - -:: - - fuel --help - -To get the list of actions and optional arguments for a namespace, run: - -:: - - fuel --help - diff --git a/userdocs/fuel-user-guide/cli/cli_change_ip_range.rst b/userdocs/fuel-user-guide/cli/cli_change_ip_range.rst deleted file mode 100644 index 874b67043..000000000 --- a/userdocs/fuel-user-guide/cli/cli_change_ip_range.rst +++ /dev/null @@ -1,53 +0,0 @@ -.. _cli_change_ip_range: - -================== -Add network ranges -================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -To add network ranges, edit the network configuration file: -add the IP network range to ``ip_ranges`` and change -``notation`` from ``cidr`` to ``ip_ranges``. - -Step-by-step: - -#. On the Fuel Master node, download the network configuration file:: - - fuel network --env -d - - where is the ID of the environment (a number) that you can - get by issuing the ``fuel env`` command. - - For example:: - - fuel network --env 1 -d - -#. Open the downloaded **/root/network_.yaml** file for editing. -#. Add your list of IP network ranges under the ``ip_ranges`` - parameter. - - Sample:: - - ip_ranges: - - - 192.168.0.1 - - 192.168.0.90 - - - 192.168.0.100 - - 192.168.0.254 - -#. In the same network configuration file, change ``notation: cidr`` - to ``notation: ip_ranges``. - - Sample:: - - meta: - cidr: 192.168.0.0/24 - configurable: true - map_priority: 2 - name: management - notation: ip_ranges - render_addr_mask: internal - -#. Upload the edited network configuration file:: - - fuel network --env -u diff --git a/userdocs/fuel-user-guide/cli/cli_client_config_file.rst b/userdocs/fuel-user-guide/cli/cli_client_config_file.rst deleted file mode 100644 index 34bbe80c7..000000000 --- a/userdocs/fuel-user-guide/cli/cli_client_config_file.rst +++ /dev/null @@ -1,55 +0,0 @@ -.. _cli-client-config-file: - -====================================== -Modify the Fuel CLI configuration file -====================================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The Fuel CLI uses the ``fuel_client.yaml`` file as a source for default -settings. By default, Fuel stores the ``fuel_client.yaml`` file in the -``~/.config/`` directory. - -**To change the default directory:** - -#. Log in to the Fuel CLI. -#. Set the required directory path: - - :: - - $ export XDG_CONFIG_HOME=/path/to/fuel_client.yaml/ - - where ``XDG_CONFIG_HOME`` points to the ``fuel_client.yaml`` file directory. - -**To specify custom settings:** - -#. Log in to the Fuel CLI. -#. Edit the ``fuel_client.yaml`` file. - - Alternatively, create a new YAML-formatted file: - - #. Create a ``.yaml`` file with the required settings. - #. Export the ``FUELCLIENT_CUSTOM_SETTINGS`` variable: - - :: - - $ export FUELCLIENT_CUSTOM_SETTINGS="~/custom.conf" - - where ``"~/custom.conf"`` is the path to the new configuration file. - - #. Optionally, add the export to the ``.bashrc`` file: - - :: - - $ echo 'export FUELCLIENT_CUSTOM_SETTINGS="~/custom.conf"' >> ~/.bashrc - -.. note:: - - Custom settings override the default ones. Top-level values may also be set - as environment variables. - - **Example:** - - :: - - $ export SERVER_PORT=8080 \ No newline at end of file diff --git a/userdocs/fuel-user-guide/cli/cli_comparison_matrix.rst b/userdocs/fuel-user-guide/cli/cli_comparison_matrix.rst deleted file mode 100644 index a6ce5084c..000000000 --- a/userdocs/fuel-user-guide/cli/cli_comparison_matrix.rst +++ /dev/null @@ -1,125 +0,0 @@ -.. _cli_comparison_matrix: - -=================================== -Fuel CLI commands comparison matrix -=================================== - -The Fuel command-line interface has been changed to simplify usage -and improve user experience. Some of the keys and options have been modified -as well. Although the old ``fuel`` commands are still available, we recommend that -you use the new ``fuel2`` commands instead. The following table describes -new ``fuel2`` commands and their alternatives in the ``fuel`` CLI. - -.. csv-table:: **Fuel CLI commands comparison matrix** - :header: Command in ``fuel2`` CLI, Description, Alternative in ``fuel`` CLI - :widths: 8, 7, 7 - - ``fuel2 complete``, Print the completion of a command in CLI, None - ``fuel2 help``, Print a detailed help for all commands, ``fuel --help`` - ``fuel2 env add nodes``, Add nodes to an environment with specified roles, ``fuel node --set`` - ``fuel2 env create``, Create an environment with given attributes, ``fuel env --create`` - ``fuel2 env delete``, Delete an environment with a given ID, ``fuel env --delete`` - ``fuel2 env deploy``, Deploy changes on a specified environment, ``fuel deploy-changes`` - ``fuel2 env deployment-facts delete``, Delete current deployment facts, ``fuel deployment --delete`` - ``fuel2 env deployment-facts download``, Download the user-defined deployment facts, ``fuel deployment --download`` - ``fuel2 env deployment-facts get-default``, Download the default deployment facts, ``fuel deployment --default`` - ``fuel2 env deployment-facts upload``, Upload deployment facts, ``fuel deployment --upload`` - ``fuel2 env extension disable``, Disable specified extensions for an environment with a given ID, None - ``fuel2 env extension enable``, Enable specified extensions for an environment with a given ID, None - ``fuel2 env extension list``, Show a list of all available extensions, None - ``fuel2 env extension show``, Show a list of enabled extensions for an environment with a given ID, None - ``fuel2 env list``, Show a list of all available environments, ``fuel env`` - ``fuel2 env network download``, Download and store network configuration of an environment, ``fuel network --download`` - ``fuel2 env network upload``, Upload network configuration and apply it to an environment, ``fuel network --upload`` - ``fuel2 env network verify``, Run network verification for a specified environment, ``fuel network --verify`` - ``fuel2 env nodes deploy``, Deploy specified nodes for a specified environment, ``fuel node --deploy`` - ``fuel2 env nodes provision``, Provision specified nodes for a specified environment, ``fuel node --provision`` - ``fuel2 env provisioning-facts delete``, Delete current provisioning facts, ``fuel provisioning --delete`` - ``fuel2 env provisioning-facts download``, Download the user-defined provisioning facts, ``fuel provisioning --download`` - ``fuel2 env provisioning-facts get-default``, Download the default provisioning facts, ``fuel provisioning --default`` - ``fuel2 env provisioning-facts upload``, Upload provisioning facts, ``fuel provisioning --upload`` - ``fuel2 env redeploy``, Redeploy changes on a specified environment, ``fuel redeploy-changes`` - ``fuel2 env remove nodes``, Remove nodes from an environment, ``fuel node remove`` - ``fuel2 env reset``, Reset a deployed environment, ``fuel reset`` - ``fuel2 env settings download``, Download and store an environment settings, ``fuel settings --download`` - ``fuel2 env settings upload``, Upload and apply an environment settings, ``fuel settings --upload`` - ``fuel2 env show``, Show information about environment with a given ID, None - ``fuel2 env spawn-vms``, Provision a specified environment, None - ``fuel2 env stop-deployment``, Stop deployment process for a specific environment, ``fuel stop`` - ``fuel2 env update``, Change given attributes for an environment, ``fuel env --set`` - ``fuel2 fuel-version``, Show the current version of Fuel, ``fuel --fuel-version`` - ``fuel2 graph delete``, Delete a deployment graph, None - ``fuel2 graph download``, Download a deployment graph configuration, ``fuel env --deployment-tasks --download`` - ``fuel2 graph execute``, Start a deployment with a given graph type, None - ``fuel2 graph list``, List deployment graphs, None - ``fuel2 graph upload``, Upload a deployment graph configuration, ``fuel env --deployment-tasks --upload`` - ``fuel2 health list``, List all available test sets for a given environment, ``fuel health --list`` - ``fuel2 health restart``, Restart a test set with a given ID, None - ``fuel2 health start``, Run specified test sets for a given environment, ``fuel health --check`` - ``fuel2 health status list``, Show a list of statuses of all test sets that have ever been executed, None - ``fuel2 health status show``, Show status of a test set with a given ID, None - ``fuel2 health stop``, Stop executing a test set with a given ID, None - ``fuel2 network-group create``, Create a new network group, ``fuel network-group --create`` - ``fuel2 network-group delete``, Delete a specified network group, ``fuel network-group --delete`` - ``fuel2 network-group list``, List all network groups, ``fuel network-group`` - ``fuel2 network-group show``, Show a specified network group, None - ``fuel2 network-group update``, Set parameters for a specified network group, ``fuel network-group --set`` - ``fuel2 network-template delete``, Delete the network template of a specified environment, ``fuel network-template --delete`` - ``fuel2 network-template download``, Download the network configuration for a specified environment, ``fuel network-template --download`` - ``fuel2 network-template upload``, Upload the network configuration for a specified environment, ``fuel network-template --upload`` - ``fuel2 node ansible-inventory``, Generate an ansible inventory file based on the nodes list, None - ``fuel2 node attributes-download``, Download attributes of a specified node, None - ``fuel2 node attributes-upload``, Upload attributes of a specified node, None - ``fuel2 node create-vms-conf``, Create the VMs configuration in metadata for a specified node, None - ``fuel2 node disks download``, Download and store configuration of disks for a node to a file, ``fuel node --disk --download`` - ``fuel2 node disks get-default``, Download the default configuration of disks for a node to a file, ``fuel node --disk --default`` - ``fuel2 node disks upload``, Upload a stored configuration of disks for a node from a file, ``fuel node --disk --upload`` - ``fuel2 node interfaces download``, Download and store a configuration of interfaces for a node to a file, ``fuel node --network --download`` - ``fuel2 node interfaces get-default``, Download the default configuration of interfaces for a node to a file, ``fuel node --network --default`` - ``fuel2 node interfaces upload``, Upload the stored configuration of interfaces for a node from a file, ``fuel node --network --download`` - ``fuel2 node label delete``, Delete specific labels on nodes, None - ``fuel2 node label list``, Show a list of all labels, None - ``fuel2 node label set``, Create or update specific labels on nodes, None - ``fuel2 node list``, Show a list of all available nodes, ``fuel node`` - ``fuel2 node list-vms-conf``, Show a list of VMs for a node, None - ``fuel2 node show``, Show information about a node with a given ID, None - ``fuel2 node undiscover``, Remove nodes from a database, ``fuel node --delete-from-db`` - ``fuel2 node update``, Change a node name and/or host name, ``fuel node --name `` and/or ``fuel node --hostname `` - ``fuel2 openstack-config delete``, Delete an OpenStack configuration with a given ID, ``fuel openstack-config --delete`` - ``fuel2 openstack-config download``, Download a specified OpenStack configuration file, ``fuel openstack-config --download`` - ``fuel2 openstack-config execute``, Execute an OpenStack configuration deployment, ``fuel openstack-config --execute`` - ``fuel2 openstack-config list``, List all OpenStack configurations, ``fuel openstack-config --list`` - ``fuel2 openstack-config upload``, Upload a new OpenStack configuration from file, ``fuel openstack-config --upload`` - ``fuel2 plugins list``, Show a list of all available plugins, ``fuel plugins --list`` - ``fuel2 plugins sync``, Synchronize plugins on a file system with plugins in the API service, ``fuel plugins --sync`` - ``fuel2 release component list``, Show a list of components for a given release, None - ``fuel2 release list``, Show a list of all available releases, ``fuel release`` - ``fuel2 release repos list``, Show repositories for a given release, None - ``fuel2 release repos update``, Update repositories for a given release, None - ``fuel2 role create``, Create a role from a file description, ``fuel role --rel 1 --create`` - ``fuel2 role delete``, Delete a role from an OpenStack release, ``fuel role --delete`` - ``fuel2 role download``, Download a full role description to a file, ``fuel role --file`` - ``fuel2 role list``, Show a list of all available roles for a release, ``fuel role`` - ``fuel2 role update``, Update a role description from a file, ``fuel role --update`` - ``fuel2 sequence create``, Create a new deployment sequence, None - ``fuel2 sequence upload``, Upload a new deployment sequence, None - ``fuel2 sequence download``, Download a deployment sequence data, None - ``fuel2 sequence delete``, Delete an existing sequence, None - ``fuel2 sequence update``, Update an existing sequence, None - ``fuel2 sequence list``, Show a list of all existing sequences, None - ``fuel2 sequence show``, Display information about a sequence, None - ``fuel2 sequence execute``, Execute a sequence on a specified environment, None - ``fuel2 snapshot create``, Generate a diagnostic snapshot, ``fuel snapshot`` - ``fuel2 snapshot create -c/--config``, Generate a diagnostic snapshot with a custom configuration, ``fuel snapshot < config_file.yml`` - ``fuel2 snapshot get-default-config``, Download the default configuration to generate a custom diagnostic snapshot, ``fuel snapshot --conf > config_file.yml`` - ``fuel2 snapshot get-link``, Show the link to download diagnostic snapshot, None - ``fuel2 task delete``, Delete a task with a given ID, ``fuel task --delete`` - ``fuel2 task deployment-info download``, Save a task deployment information to a file, None - ``fuel2 task history show``, Show a deployment history about a task with a given ID, None - ``fuel2 task list``, Show a list of all available tasks, None - ``fuel2 task network-configuration download``, Save a task network configuration to a file, None - ``fuel2 task settings download``, Download and save a task settings to a file, None - ``fuel2 task show``, Show information about a task with a given ID, None - ``fuel2 vip create``, Create a VIP, ``fuel vip --create`` - ``fuel2 vip download``, Download a configuration of VIPs, ``fuel vip --download`` - ``fuel2 vip upload``, Upload a new configuration of VIPs from a file, ``fuel vip --upload`` diff --git a/userdocs/fuel-user-guide/cli/cli_config_openstack.rst b/userdocs/fuel-user-guide/cli/cli_config_openstack.rst deleted file mode 100644 index d13789516..000000000 --- a/userdocs/fuel-user-guide/cli/cli_config_openstack.rst +++ /dev/null @@ -1,119 +0,0 @@ -.. _cli-config-openstack-services: - -================================================== -Modify the configuration of the OpenStack services -================================================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -You can customize the hardcoded, or provided by Nailgun, -configuration values, as well as introduce new configuration options -for the OpenStack services, such as Nova, Neutron, and Keystone using CLI. - -You can change the Nova, Neutron, and Keystone configuration for a single -node, all nodes with a specific role, or a whole OpenStack environment. - -Changes to the OpenStack services configuration can be applied before -or after you deploy an OpenStack environment. - -After you apply changes, the services will be automatically restarted. - -The ``override_resources`` Puppet resource applies changes to the existing -configuration resources and creates the new ones that were not previously -defined. - -**To modify the configuration of the OpenStack services:** - -#. Log in to the Fuel Master node. -#. Edit the ``.yaml`` file with the configuration options of the services that - you want to change. - - **Example:** - - .. code-block:: yaml - - configuration: - nova_config: - DEFAULT/debug: - value: True - DEFAULT/amqp_durable_queues: - value: False - keystone_config: - DEFAULT/default_publisher_id: - ensure: absent - DEFAULT/crypt_strength: - value: 6000 - -#. Upload the ``.yaml`` file: - - * To upload the changes for an OpenStack environment: - - .. code-block:: console - - fuel openstack-config --env --upload file.yaml - - * To upload the changes for all nodes with a specific role: - - .. code-block:: console - - fuel openstack-config --env --role compute \ - --upload - - * To upload the changes for selected nodes: - - .. code-block:: console - - fuel openstack-config --env --node 1,2,3 \ - --upload - -#. Apply the changes: - - * To apply the changes for the environment: - - .. code-block:: console - - fuel openstack-config --env --execute - - * To apply the changes for all nodes with a role: - - .. code-block:: console - - fuel openstack-config --env --role compute --execute - - * To apply the changes for certain nodes: - - .. code-block:: console - - fuel openstack-config --env --node 1,2,3 --execute - - The services will restart automatically. - -#. Optionally, run these additional commands: - - #. List the configuration changes history: - - .. code-block:: console - - fuel openstack-config --env --list - - .. note:: The :option:`--list` parameter shows historical data only - for the active configuration. - - #. Download the previously uploaded ``.yaml`` file with the configuration - changes: - - #. Obtain the record number from the changes history: - - .. code-block:: console - - fuel openstack-config --env --list - - #. Download the ``.yaml`` file: - - .. code-block:: console - - fuel openstack-config --id --download - -.. seealso:: - - - :ref:`cli-config-openstack-services-workflow` diff --git a/userdocs/fuel-user-guide/cli/cli_config_openstack_services_workflow.rst b/userdocs/fuel-user-guide/cli/cli_config_openstack_services_workflow.rst deleted file mode 100644 index 64540ba3d..000000000 --- a/userdocs/fuel-user-guide/cli/cli_config_openstack_services_workflow.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _cli-config-openstack-services-workflow: - -Workflow of the configuration change override ---------------------------------------------- - -The ``override_resources`` Puppet resource overrides the already existing -resources and creates the resources that have not been defined previously. - -.. note:: ``override_resources`` must always be used as the first resource - in manifests. - -Example: - -.. code-block:: puppet - - keystone_config { - 'DEFAULT/debug': {value => True} - } - override_resource {'keystone_config': - data => { - 'DEFAULT/debug': {'value' => False}, - 'DEFAULT/max_param_size': {'value' => 128} - } - } - -The Nova, Keystone, and Neutron top-level granular tasks use -``override_resources``. The new parameter hash used in the Puppet resources -is passed to ``override_resources`` from Hiera. - -The following Hiera files cover the hierarchical configuration -overrides: - -- ``/etc/hiera/override/config/%{::fqdn}`` -- ``/etc/hiera/override/config/role`` -- ``/etc/hiera/override/config/cluster`` - -Hiera delivers the hierarchical structure of data. - -The top-level granular tasks used to override the configuration have -the ``refresh_on`` parameter. - -**Example:** - -.. code-block:: yaml - - - id: keystone - type: puppet - groups: [primary-controller, controller] - required_for: [openstack-controller] - requires: [openstack-haproxy, database, rabbitmq] - refresh_on: [keystone_config] - parameters: - puppet_manifest: - /etc/puppet/modules/osnailyfacter/modular/keystone/keystone.pp - puppet_modules: /etc/puppet/modules - timeout: 3600 - test_pre: - cmd: ruby - /etc/puppet/modules/osnailyfacter/modular/keystone/keystone_pre.rb - test_post: - cmd: ruby - /etc/puppet/modules/osnailyfacter/modular/keystone/keystone_post.rb - -Nailgun uses the ``refresh_on`` parameter to run the respective -task when you change the OpenStack configuration. diff --git a/userdocs/fuel-user-guide/cli/cli_deploy.rst b/userdocs/fuel-user-guide/cli/cli_deploy.rst deleted file mode 100644 index 0d6161f5c..000000000 --- a/userdocs/fuel-user-guide/cli/cli_deploy.rst +++ /dev/null @@ -1,31 +0,0 @@ -.. _cli-deploy: - -=================== -Deployment commands -=================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The following table describes the usage of the :command:`fuel deployment` -command available in the Fuel CLI. - -.. list-table:: **Deployment commands** - :widths: 7 10 - :header-rows: 1 - - * - Description - - Command - * - Delete current deployment data - - ``fuel --env deployment --delete`` - * - Download current deployment data - - ``fuel --env deployment --download`` - * - Download default deployment data - - ``fuel --env deployment --default`` - * - Get default deployment information for specific nodes - - ``fuel --env deployment --default --node `` - * - Upload provisioning deployment to a specific directory - - ``fuel --env deployment -u --dir path/to/directory`` - * - Download deployment information to a specific directory - - ``fuel --env deployment -d --dir path/to/directory`` - - diff --git a/userdocs/fuel-user-guide/cli/cli_environment.rst b/userdocs/fuel-user-guide/cli/cli_environment.rst deleted file mode 100644 index d6ab5bd3f..000000000 --- a/userdocs/fuel-user-guide/cli/cli_environment.rst +++ /dev/null @@ -1,46 +0,0 @@ -.. _cli-environment: - -==================== -Environment commands -==================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The following table describes environment management commands -available in the Fuel CLI. - -.. list-table:: **Environment commands** - :widths: 10 10 20 - :header-rows: 1 - - * - Description - - Command - - Example - * - View the list of environments. - - ``fuel env`` - - - * - Create an environment. - - ``fuel env create --name --rel `` - - By default, Fuel creates an OpenStack environment in the - ``multinode`` mode, and the ``nova`` network mode. - To specify other modes, you can add optional arguments: - - .. code-block:: console - - fuel env create --name --rel \ - --mode ha --network-mode neutron --net-segment-type vlan - - Use the ``set`` action to change the name, mode, or network mode - for an OpenStack environment: - - .. code-block:: console - - fuel --env env set --name --mode ha_compact - - * - Delete an OpenStack environment. - - ``fuel --env env delete`` - - - * - Update the OpenStack environment to a newer version. To roll back a - failed update, use the same command with the previous release number. - - ``fuel env --update --env --rel `` - - diff --git a/userdocs/fuel-user-guide/cli/cli_manage_gitrepo.rst b/userdocs/fuel-user-guide/cli/cli_manage_gitrepo.rst deleted file mode 100644 index 5ca57dd68..000000000 --- a/userdocs/fuel-user-guide/cli/cli_manage_gitrepo.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. _cli-manage-gitrepo: - -============================================ -Fuel IaC: Git repository management commands -============================================ - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The following table describes the usage of the :command:`fuel2 gitrepo` -command available in the Fuel CLI. This command is available after you -install the Fuel Infrastructure-as-Code extension. For more information, see: -:ref:`lcm-git-repo`. - -.. list-table:: **Repository management commands** - :widths: 7 10 - :header-rows: 1 - - * - Description - - Command - * - Associate an OpenStack environment with a Git repository. - - ``fuel gitrepo create [-h] --env --name --url - --ref [--key ]`` - - **Example:** - - :: - - fuel2 gitrepo create --env 1 --name test --url \ - git@github.com:user/test.git --ref master --key .ssh/id_rsa - - - * ``--env`` - an OpenStack environment ID. - * ``--name`` - the name of the Git repository. It will be used - as a directory name for the repository. - * ``--url`` - URL to the Git repository. For example, - ``git@github.com:user/repo.git``. - * ``ref`` - a Git reference, such as a branch or Gerrit refspec. - * ``key`` - a path to the private SSH key. - - * - Download configuration files from an OpenStack environment and upload - them to the configured Git repository. - - ``fuel2 gitrepo get configs [-h] [--env ] [--key_path ] - [--repo_dir ]`` - - * ``--env`` - an OpenStack environment ID. - * ``--key_path`` - a path to the private SSH key file on the selected - node. - * ``--repo_dir`` - a directory in the Git repository to upload the - files. diff --git a/userdocs/fuel-user-guide/cli/cli_management.rst b/userdocs/fuel-user-guide/cli/cli_management.rst deleted file mode 100644 index 49cd17ec0..000000000 --- a/userdocs/fuel-user-guide/cli/cli_management.rst +++ /dev/null @@ -1,43 +0,0 @@ -.. _cli-management: - -======================== -Fuel management commands -======================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The following table describes basic management commands -available in the Fuel CLI. - -.. list-table:: **Management and help commands** - :widths: 10 10 20 - :header-rows: 1 - - * - Description - - Command - - Example - * - View the list of all global optional arguments and namespaces. - - ``fuel --help`` - - View the list of actions and optional arguments for a namespace: - - .. code-block:: console - - fuel --help - * - View the list of all available releases - - ``fuel release`` - - ``fuel rel`` - - View the information about a specific release: - - .. code-block:: console - - fuel rel --rel - - * - Get the information about the Fuel version. - - ``fuel fuel-version`` - - - * - Change the Fuel password. You can use the ``--user=admin`` and - ``--password=test`` flags to provide user name and password with - all Fuel CLI commands. - - ``fuel user --change-password --new-pass=`` - - diff --git a/userdocs/fuel-user-guide/cli/cli_modify_environment.rst b/userdocs/fuel-user-guide/cli/cli_modify_environment.rst deleted file mode 100644 index 5645cc205..000000000 --- a/userdocs/fuel-user-guide/cli/cli_modify_environment.rst +++ /dev/null @@ -1,106 +0,0 @@ -.. _cli-modify-env: - -========================================= -Modify an Openstack environment using CLI -========================================= - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -You can modify your OpenStack environment after deployment -by downloading the ``.yaml`` configuration files, editing settings, and -then uploading the configuration files back to the Nailgun -server. After uploading the files, you must redeploy your OpenStack -environment. - -Before modifying any settings, back up your OpenStack environment -configuration. - -If you upload any changes for provisioning or deployment operations, -you freeze the configuration for the entire environment; -any changes you later make to the networks, cluster, -or disk configurations using the Fuel web UI will not be implemented. -To modify these parameters, you must edit the appropriate section of -each node's configuration file and then apply the changes using Fuel CLI. - -You can download the following configurations: - -* ``network`` -* ``settings`` -* ``node --disk`` -* ``node --network`` -* ``provisioning`` -* ``deployment`` - -When performing operations with nodes using :command:`fuel deployment` and -:command:`fuel provisioning` commands, you can indicate specific nodes. -For example: - -.. code-block:: console - - fuel --env 1 deployment --node 1,2,3 - -When downloading configurations using :command:`fuel deployment` and -:command:`fuel provisioning` commands, Fuel automatically generates -the following files: - -* For deployment: - - ``master.yaml`` - Includes details about the Fuel Master node configuration for a specified - OpenStack environment. - - ``.yaml`` - Includes details about the node deployment. The ``.yaml`` file - contains deployment details and is identical to the ``astute.yaml`` file - stored on a specific node. The deployment tasks consume parameters - included in ``.yaml`` through hiera. - -* For provisioning: - - ``engine.yaml`` - Includes credentials for the provisioning service (Cobbler) engine. - - ``node-.yaml`` - Includes details about provisioning for each node. - -.. seealso:: - - * :ref:`file-ref` - * :ref:`cli-provision` - * :ref:`cli-deploy` - -**To modify an OpenStack environment using CLI:** - -#. Back up your configuration. -#. Download the ``.yaml`` configuration file(s). - - **Example** - - :: - - fuel --env 1 network download - fuel --env 1 settings download - fuel --env 1 deployment default - fuel --env 1 provisioning download - fuel node --node-id 2 --disk --download - -#. Modify the downloaded file(s). -#. Save the changes. -#. Upload the files to the Nailgun server: - - **Example:** - - :: - - fuel --env 1 provisioning upload - fuel node --node-id 2 --disk --upload - -#. Redeploy your OpenStack environment -#. Create a backup of the updated OpenStack environment. - - .. note:: - You may want to delete the downloaded ``.yaml`` - files, as they may contain unencrypted passwords. This - may pose a security threat. - - diff --git a/userdocs/fuel-user-guide/cli/cli_network.rst b/userdocs/fuel-user-guide/cli/cli_network.rst deleted file mode 100644 index 95d093be7..000000000 --- a/userdocs/fuel-user-guide/cli/cli_network.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _cli-network: - -================ -Network commands -================ - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -You can manage network configurations using the following command: - -.. code-block:: console - - fuel --env network --dir - -.. list-table:: - :widths: 10 10 - :header-rows: 0 - - * - Value - - Description - * - ```` - - ID of an OpenStack environment - * - ```` - - Path to directory - * - ```` - - Action that will be performed for the network configuration. - -The following table describes network management commands -available in the Fuel CLI. - -.. list-table:: **Network management commands** - :widths: 10 10 20 - :header-rows: 1 - - * - Command - - Description - - Example - * - ``fuel --env network --download --dir `` - - Download network configuration for a specific environment. - - Download network configuration for - the environment with ID ``1`` to the current directory: - - .. code-block:: console - - fuel --env 1 network --download - - * - ``fuel --env network --upload --dir `` - - Upload network configuration for a specific environment. - - Upload network configuration for the environment with - ID ``1`` from the current directory: - - .. code-block:: console - - fuel --env 1 network --upload - - .. note:: - The :command:`fuel network` command can update configuration of - all networks in an OpenStack environment, as well as corresponding - Neutron parameters. However, you must update the related VIPs - and network templates separately using the corresponding Fuel - CLI commands. - * - ``fuel --env network --verify --dir `` - - Verify network configuration. Verification does not work for - multiple cluster networks, when an environment has more than one - node group. - - Verify network configuration of the OpenStack environment with ID ``1`` - from the current directory: - - .. code-block:: console - - fuel --env 1 network --verify - -To view interaction with the Nailgun API, run the corresponding command with -the :option:`--debug` option. - -**Example:** - -.. code-block:: console - - fuel --env network --download --dir --debug diff --git a/userdocs/fuel-user-guide/cli/cli_network_group.rst b/userdocs/fuel-user-guide/cli/cli_network_group.rst deleted file mode 100644 index ca04ba7b2..000000000 --- a/userdocs/fuel-user-guide/cli/cli_network_group.rst +++ /dev/null @@ -1,73 +0,0 @@ -.. _cli-network-group: - -================================= -Network group management commands -================================= - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The following table describes network group management commands -available in the Fuel CLI. - -.. list-table:: **Network group management commands** - :widths: 10 10 20 - :header-rows: 1 - - * - Description - - Command - - Example - * - List all available network groups. - - ``fuel network-group`` - - - * - List network groups in a particular node group. - - ``fuel network-group --node-group `` - - .. code-block:: console - - fuel network-group --node-group 1 - * - Create a new network group. - - Variables: - - * ```` - an ID of a node group - * ```` - a name of a new network group - * ```` - a release ID this network group belongs to - * ```` - a VLAN of a network - * ```` - a CIDR of a network - * ```` - a gateway of a network - * ```` - meta information in JSON format - - - ``fuel network-group --create --node-group --name \ - --release --vlan --cidr --gateway \ - --meta `` - - .. code-block:: console - - fuel network-group --create --node-group 2 --name "new network" \ - --release 2 --vlan 100 --cidr 10.0.0.0/24 --gateway 10.0.0.1 \ - --meta 'meta information in JSON format' - * - Set parameters for a network group. - - Variables: - - * ```` - an ID of a network group - * ```` - a parameter you want to set or update. - See the ``fuel network-group --create`` command for the - list of parameters. - * ```` - a new value for the specified parameter - - ``fuel network-group --set --network -- `` - - .. code-block:: console - - fuel network-group --set --network 1 --name new_name - - * - Delete a network group. - - ``fuel network-group --delete --network `` - - Delete a single network group: - - .. code-block:: console - - fuel network-group --delete --network 1 - - Delete multiple network groups: - - .. code-block:: console - - fuel network-group --delete --network 2,3,4 diff --git a/userdocs/fuel-user-guide/cli/cli_network_template.rst b/userdocs/fuel-user-guide/cli/cli_network_template.rst deleted file mode 100644 index 111a2d5c3..000000000 --- a/userdocs/fuel-user-guide/cli/cli_network_template.rst +++ /dev/null @@ -1,34 +0,0 @@ -.. _cli-network-template: - -==================================== -Network template management commands -==================================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The following table describes network template management commands -available in the Fuel CLI. - -.. list-table:: **Network template management commands** - :widths: 10 10 20 - :header-rows: 1 - - * - Description - - Command - - Example - * - Upload a network template. - - ``fuel --env network-template --upload --dir `` - - .. code-block:: console - - fuel --env 1 network-template --upload --dir /home/stack/ - - * - Download a network template to the current directory. - - ``fuel --env network-template --download`` - - .. code-block:: console - - fuel --env 1 network-template --download - * - Delete a network template. - - ``fuel --env network-template --delete`` - - .. code-block:: console - - fuel --env 1 network-template --delete diff --git a/userdocs/fuel-user-guide/cli/cli_node_group.rst b/userdocs/fuel-user-guide/cli/cli_node_group.rst deleted file mode 100644 index 907cf1b77..000000000 --- a/userdocs/fuel-user-guide/cli/cli_node_group.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _cli-node-group: - -Node group management commands ------------------------------- - -The following table describes node group management commands -available in the Fuel CLI. - -.. list-table:: **Node group management commands** - :widths: 10 10 20 - :header-rows: 1 - - * - Description - - Command - - Example - * - List all available node groups. - - ``fuel nodegroup`` - - List node groups for a specific OpenStack environment: - - :: - - fuel --env nodegroup - - * - Create a node group. - - ``fuel --env nodegroup --create --name "group_name"`` - - :: - - fuel --env nodegroup --create --name "group 1" - * - Delete a node group. - - ``fuel --env nodegroup --delete --group `` - - - * - Assign a node to a specific node group. - - ``fuel --env nodegroup --assign --node --group - `` - - diff --git a/userdocs/fuel-user-guide/cli/cli_nodes.rst b/userdocs/fuel-user-guide/cli/cli_nodes.rst deleted file mode 100644 index fb802fd9c..000000000 --- a/userdocs/fuel-user-guide/cli/cli_nodes.rst +++ /dev/null @@ -1,55 +0,0 @@ -.. _cli-nodes: - -======================== -Node management commands -======================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The following table describes node management commands -available in the Fuel CLI. - -.. list-table:: **Node management commands** - :widths: 10 10 20 - :header-rows: 1 - - * - Description - - Command - - Example - * - List all available nodes. - - ``fuel node list`` - - List nodes for a specific environment: - - :: - - fuel --env-id node list - * - Assign nodes with specific roles to an OpenStack environment. - - ``fuel node set --node --role --env `` - - :: - - fuel node set --node --role controller --env - - :: - - fuel node set --node ,, \ - --role compute,cinder --env - * - Remove nodes from an OpenStack environment. - - ``fuel node remove --node , --env `` - - Remove nodes without specifying an OpenStack environment: - - :: - - fuel node remove --node , - - Remove all nodes from a specific OpenStack environment: - - :: - - fuel node remove --env - * - Delete nodes with the *offline* status from the Fuel database. - - ``fuel node --node-id --delete-from-db`` - - Delete nodes with any status from the Fuel database: - - :: - - fuel node --node-id --delete-from-db --force diff --git a/userdocs/fuel-user-guide/cli/cli_nodes_empty_role.rst b/userdocs/fuel-user-guide/cli/cli_nodes_empty_role.rst deleted file mode 100644 index ae90ca2a1..000000000 --- a/userdocs/fuel-user-guide/cli/cli_nodes_empty_role.rst +++ /dev/null @@ -1,148 +0,0 @@ -.. _cli-nodes-empty-role: - -================================ -Deploy a node with an empty role -================================ - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -You may need to deploy a node with an operating system installed only, -that is an empty role, where you can further deploy your own service -out of Fuel control. - -**To deploy a node with an empty role:** - -#. Verify available operating systems: - - .. code-block:: console - - fuel release - - **Example of system response:** - - .. code-block:: console - - id | name | state | operating_system | version - ---|----------------------------|-------------|------------------|----------- - 2 | Mitaka on Ubuntu 14.04 | available | Ubuntu | mitaka-9.0 - 3 | Mitaka on Ubuntu+UCA 14.04 | available | Ubuntu | mitaka-9.0 - 1 | Mitaka on CentOS 6.5 | unavailable | CentOS | mitaka-9.0 - - - Note down the operating system ``id`` you need to install on the node. - -#. Verify available nodes: - - .. code-block:: console - - fuel node - - **Example of system response:** - - .. code-block:: console - - id | status | name | cluster | ip | mac | roles | pending_roles | online | group_id - ---|----------|------------------|---------|-----------|-------------------|-------|---------------|--------|--------- - 2 | discover | Untitled (90:9b) | None | 10.20.0.4 | 08:00:27:f5:90:9b | | | True | None - 3 | discover | Untitled (53:f1) | None | 10.20.0.5 | 08:00:27:14:53:f1 | | | True | None - 1 | discover | Untitled (7c:11) | None | 10.20.0.3 | 08:00:27:72:7c:11 | | | True | None - - -#. Create a new environment if you do not have one: - - .. code-block:: console - - fuel env create --name --release 2 - - **Example of system response:** - - .. code-block:: console - - Environment `` with id=1 was created! - -#. Verify that the environment has been created: - - .. code-block:: console - - fuel env - - **Example of system response:** - - .. code-block:: console - - id | status | name | release_id - ---|--------|------------|----------- - 1 | new | | 2 - - Note down the ``id`` of the environment. - -#. Verify available roles: - - .. code-block:: console - - fuel role --release 2 - - **Example of system response:** - - .. code-block:: console - - name - ------------------- - compute-vmware - compute - cinder-vmware - virt - base-os - controller - ceph-osd - ironic - cinder - cinder-block-device - mongo - - The role that you need is ``base-os``. - -#. Add one of the discovered nodes to the environment with the ``base-os`` role assigned: - - .. code-block:: console - - fuel node set --env 1 --node 1 --role base-os - - **Example of system response:** - - .. code-block:: console - - Nodes [1] with roles ['base-os'] were added to environment 1 - -#. Verify the status of the nodes: - - .. code-block:: console - - fuel node - - **Example of system response:** - - .. code-block:: console - - id | status | name | cluster | ip | mac | roles | pending_roles | online | group_id - ---|----------|------------------|---------|-----------|-------------------|-------|---------------|--------|--------- - 1 | discover | Untitled (7c:11) | 1 | 10.20.0.3 | 08:00:27:72:7c:11 | | base-os | True | 1 - 2 | discover | Untitled (90:9b) | None | 10.20.0.4 | 08:00:27:f5:90:9b | | | True | None - 3 | discover | Untitled (53:f1) | None | 10.20.0.5 | 08:00:27:14:53:f1 | | | True | None - - -Your node with an empty role has been added to the environment. - -.. note:: - - By default, Fuel does not apply network configuration. - To set up network configuration, run the ``netconfig`` puppet manifests - that comes with ``fuel-library``. - Fuel automatically executes the following tasks on ``base-os`` nodes only: - - * ``hiera`` - * ``globals`` - * ``logging`` - - See the `tasks.yaml `__ - configuration file diff --git a/userdocs/fuel-user-guide/cli/cli_noop.rst b/userdocs/fuel-user-guide/cli/cli_noop.rst deleted file mode 100644 index 0a879e07d..000000000 --- a/userdocs/fuel-user-guide/cli/cli_noop.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. _cli_noop: - -======================================================== -Detect custom configurations in an OpenStack environment -======================================================== - -Before you redeploy, update, or upgrade your OpenStack environment, ensure -that next Fuel tasks run will not override important changes that had been -applied to a whole OpenStack environment or a particular OpenStack node. -This procedure should only be applied to OpenStack nodes with the ``ready`` -statuses or to OpenStack environments with the ``operational`` statuses. - -**To detect custom configurations using the Fuel task graphs:** - -#. Select from the following options: - - * If you want to check that an environment has customizations using - a specific graph, execute the graph in the ``noop`` mode: - - .. code-block:: console - - fuel2 graph execute --env --type --noop --force - - * If you want to check that particular OpenStack nodes have customizations - using a specific graph, execute this graph in the ``noop`` mode: - - .. code-block:: console - - fuel2 graph execute --env --type -n --noop --force - - .. note:: The Puppet Noop run for any OpenStack environment or node - does not change their statuses. The Noop run is an additional - check rather than a part of the deployment process. - - * If you want to view the Puppet Noop run reports for a particular task graph, - type one of the following: - - .. code-block:: console - - fuel deployment-tasks --tid --task-name --include-summary - - .. code-block:: console - - fuel2 task history show --include-summary - - Reports for each Puppet Noop run are stored on all OpenStack nodes in - the ``/var/lib/puppet/reports//.yaml`` directory - and include details about the changes that were applied to the Fuel task - graphs. \ No newline at end of file diff --git a/userdocs/fuel-user-guide/cli/cli_plugins.rst b/userdocs/fuel-user-guide/cli/cli_plugins.rst deleted file mode 100644 index 803af762f..000000000 --- a/userdocs/fuel-user-guide/cli/cli_plugins.rst +++ /dev/null @@ -1,59 +0,0 @@ -.. _cli_plugins: - -========================== -Plugin management commands -========================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The following table describes the plugin management commands -available in the Fuel CLI. - -.. note:: - To view the list of all available options, use the - ``fuel plugins --help`` command. - -.. list-table:: **Plugin management commands** - :widths: 10 10 20 - :header-rows: 1 - - * - Description - - Command - - Example - * - Install a Fuel plugin from an ``.fp`` package. - - ``fuel plugins --install `` - - - * - Install a Fuel plugin from an ``.rpm`` package. - - ``yum install `` - - - * - Register a Fuel plugin installed using - ``yum install`` from an ``.rpm`` package in Nailgun. - - ``fuel plugins --register ==`` - - - * - View the list of installed plugins. - - ``fuel plugins --list`` - - :: - - fuel plugins --list - - **System response:** - - :: - - id | name | version | package_version - ---|---------------------------|----------|---------------- - 1 | | 1.0.0 | 2.0.0 - - * - Remove a plugin. - - ``fuel plugins --remove ==`` - - - * - Upgrade a Fuel plugin installed from the ``.rpm`` package. - - .. note:: - Upgrades are not supported for major versions of plugins installed - from the ``.rpm`` package, as well as for plugins installed from the - ``.fp`` packages. For example, you can only upgrade a Fuel plugin - installed from an ``.rpm`` package from version - 1.0.0 to 1.0.1. - - ``fuel plugins --update `` - - diff --git a/userdocs/fuel-user-guide/cli/cli_provision.rst b/userdocs/fuel-user-guide/cli/cli_provision.rst deleted file mode 100644 index 9c7575d18..000000000 --- a/userdocs/fuel-user-guide/cli/cli_provision.rst +++ /dev/null @@ -1,29 +0,0 @@ -.. _cli-provision: - -===================== -Provisioning commands -===================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The following table describes the usage of the :command:`fuel provisioning` -command available in the Fuel CLI usage. - -.. list-table:: **Provisioning commands** - :widths: 7 10 - :header-rows: 1 - - * - Description - - Command - * - Delete current provisioning data - - ``fuel --env provisioning --delete`` - * - Download current provisioning data - - ``fuel --env provisioning --download`` - * - Download default provisioning data - - ``fuel --env provisioning --default`` - * - Get default provisioning information for specific nodes - - ``fuel --env provisioning --default --node `` - * - Upload provisioning information to a specific directory - - ``fuel --env provisioning -u --dir path/to/directory`` - * - Download provisioning information to a specific directory - - ``fuel --env provisioning -d --dir path/to/directory`` \ No newline at end of file diff --git a/userdocs/fuel-user-guide/cli/cli_roles.rst b/userdocs/fuel-user-guide/cli/cli_roles.rst deleted file mode 100644 index b6e254e42..000000000 --- a/userdocs/fuel-user-guide/cli/cli_roles.rst +++ /dev/null @@ -1,91 +0,0 @@ -.. _cli-roles: - -======================== -Role management commands -======================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -Fuel CLI implements standard CRUD for operations on a node role. -The following table describes the role management commands -available in the Fuel CLI. - -.. list-table:: **Role operations commands** - :widths: 10 10 20 - :header-rows: 1 - - * - Description - - Command - - Example - * - List roles. - - ``fuel role --rel `` - - :: - - fuel role --rel 2 - - **System response:** - - :: - - name | id - --------------|--- - controller | 9 - compute | 10 - cinder | 11 - cinder-vmware | 12 - ceph-osd | 13 - mongo | 14 - zabbix-server | 15 - base-os | 16 - - * - Create a new role from the ``.yaml`` file. - - ``fuel role --rel <2> --create --file `` - - #. Create a role in a ``.yaml`` file. - - The following text is an example of a .yaml file for the Swift - role: - - :: - - meta: - description: Installs swift server. - has_primary: true # we need primary-swift and swift during - orchestration - name: Swift - name: swift - volumes_roles_mapping: - - allocate_size: min - id: os - #. Assign the role: - - :: - - fuel role --rel <2> --create --file - - #. View the role: - - :: - - fuel role --rel <2> - - **System response:** - - :: - - name | id - -------- - swift | 17 - - * - Update the role data - - ``fuel role --rel --update --file `` - - :: - - fuel role --rel <2> --update --file - - * - Delete the role. - - ``fuel role --rel --delete --role `` - - :: - - fuel role --rel <2> --delete --role - - line 573 diff --git a/userdocs/fuel-user-guide/cli/cli_vip.rst b/userdocs/fuel-user-guide/cli/cli_vip.rst deleted file mode 100644 index bf6ca297e..000000000 --- a/userdocs/fuel-user-guide/cli/cli_vip.rst +++ /dev/null @@ -1,37 +0,0 @@ -.. _cli-vip: - -============================== -Virtual IP management commands -============================== - -.. include:: /userdocs/snippets/notes/deprecated-cli-v1.rst - -The following table describes virtual IP management commands -available in the Fuel CLI. - -.. list-table:: **Virtual IP management commands** - :widths: 10 10 20 - :header-rows: 1 - - * - Description - - Command - - Example - * - Download a virtual IP (VIP) configuration for a specific environment - to a specified file. - - Variables: - - * ```` - an environment ID - * ```` - a name of the ``yaml`` file where to save a VIP - configuration (optional). - - - ``fuel --env vip --download --file `` - - .. code-block:: console - - fuel --env 1 vip --download --file vip.yaml - * - Upload a VIP configuration for a specific environment from a - specified file. - - ``fuel --env vip --upload --file `` - - .. code-block:: console - - fuel --env 1 vip --upload --file vip.yaml diff --git a/userdocs/fuel-user-guide/cli/cli_workflows.rst b/userdocs/fuel-user-guide/cli/cli_workflows.rst deleted file mode 100644 index 04b80d6f7..000000000 --- a/userdocs/fuel-user-guide/cli/cli_workflows.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. _cli-workflows: - -======================================== -Deployment workflows management commands -======================================== - -The following table describes the deployment workflows management commands -supported by the Fuel CLI. - -.. list-table:: **Deployment workflows management commands** - :widths: 15 20 - :header-rows: 1 - - * - Description - - Command - - * - List deployment workflows. - - Use ``-e ``, ``--cluster``, ``--plugins``, or ``--release`` - flags to specify an environment, cluster-, plugins-, or - release-related workflows. - - * ``fuel2 graph list`` - - * - Upload a specific type of deployment workflows configuration of an - environment, release, or plugin from the ``YAML`` file or the - directory that includes ``tasks.yaml`` and ``metadata.yaml``. - - * ``fuel2 graph upload -e -t (-f YAML_FILE_NAME | -d DIR_NAME)`` - * ``fuel2 graph upload -r -t (-f YAML_FILE_NAME | -d DIR_NAME)`` - * ``fuel2 graph upload -p -t (-f YAML_FILE_NAME | -d DIR_NAME)`` - - * - Download deployment workflows of an environment. - - Use the ``-a``, ``-c``, ``-r``, or ``-p`` flag to specify - the level of the workflows to download. - - * ``fuel2 graph download -e -a [-t ]`` - * ``fuel2 graph download -e -c [-t ]`` - * ``fuel2 graph download -e -r [-t ]`` - * ``fuel2 graph download -e -p [-t ]`` - - The ``-t`` parameter is optional. If not specified, the default - workflow is downloaded. - - The workflows downloaded with the keys ``-a`` and ``-p`` are the - result of other workflows merge. They are not supposed to be edited - and uploaded back, because, in most cases, they will override - further changes in source workflows. - - * - Start a deployment with given workflow types. - - Available for environments only. - - * ``fuel2 graph execute -e -t []`` - - The ``-t`` parameter specifies the types of deployment - workflow in order of execution. - - * - Run any task workflow in the ``noop`` mode to detect customizations. - - * ``fuel2 graph execute -e -t [] --noop --force`` - - The ``--force`` parameter is optional and is necessary for previously - executed workflows or tasks to prevent tasks skipping by Fuel - LCM engine. - - * - Delete deployment workflows. - - Use ``-e ``, ``-p``, or ``-r`` flag to specify - an environment, plugins- or release-related workflows. - - * ``fuel2 graph delete -e -t `` - * ``fuel2 graph delete -r -t `` - * ``fuel2 graph delete -p -t `` diff --git a/userdocs/fuel-user-guide/configure-additional-components.rst b/userdocs/fuel-user-guide/configure-additional-components.rst deleted file mode 100644 index c882979bf..000000000 --- a/userdocs/fuel-user-guide/configure-additional-components.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. raw:: pdf - - PageBreak - -.. _configure-additional-components: - -Configure additional components -=============================== - -If you have installed additional components, such as the OpenStack application -catalog (Murano), the Telemetry service (Ceilometer), the Bare Metal service -(Ironic), or the Hadoop cluster (Sahara), you may need to complete post- -deployment steps that will ensure your OpenStack environment functions -correctly. - -If you installed any of these components, complete the steps described in the -corresponding sections. - -If you installed Ironic, complete the tasks described in the following -sections: - -.. toctree:: - :maxdepth: 3 - - configure-additional-components/ironic_configure.rst - configure-additional-components/ironic_prepare_image.rst - -If you installed Sahara, complete the tasks described in the following -sections: - -.. toctree:: - :maxdepth: 3 - - configure-additional-components/sahara_configure.rst - diff --git a/userdocs/fuel-user-guide/configure-additional-components/ironic_configure.rst b/userdocs/fuel-user-guide/configure-additional-components/ironic_configure.rst deleted file mode 100644 index 7ae93f7a4..000000000 --- a/userdocs/fuel-user-guide/configure-additional-components/ironic_configure.rst +++ /dev/null @@ -1,88 +0,0 @@ - -.. _ironic-configure: - -Configure the Bare Metal service --------------------------------- - -After you deploy an OpenStack environment as described in -:ref:`ironic-install`, you must configure the components required for the -Ironic program. Execute all actions described in this -section as an OpenStack user with administrative privileges. - -**To configure the Bare Metal service:** - -#. Define the memory, CPU, and disk size of physical instances that you will - deploy by creating a nova flavor that matches the server hardware - on which you plan to run instances. Use the following command: - - :: - - nova flavor-create - -#. Optionally, specify additional parameters using the ``nova flavor-key`` - command. - - **Example:** - - :: - - nova flavor-key baremetal-flavor set cpu_arch=x86_64 - -#. View and remember the list of UUIDs for bootstrap images: - - :: - - glance image-list | grep - -#. Enroll the nodes on which you plan to boot instances into the - OpenStack Bare Metal service. - - :: - - ironic node-create [-c ] -d [-i ] [-p - ] [-e ] [-u ] [-n ] - - - .. list-table:: **Fuel drivers** - :widths: 10 25 - :header-rows: 1 - - * - Driver - - Description - * - ``fuel_ssh`` - - Enables communication between the Fuel Master node and other nodes. - * - ``fuel_ipmitool`` - - Enables communication through IPMI. Use with the nodes that require - IPMI, such as nodes that you use for bare-metal deployments. - * - ``fuel-libvirt`` - - Ensures operation of virtual ironic instances hosted on ``libvirt``. - * - ``fake`` - - Used for testing Fuel APIs. - - Use the values from step 1 and step 2. The following text is an example for the - ``fuel_ipmitool`` driver. - - **Example:** - - :: - - ironic node-create [-n ] [-u ] -d fuel_ipmitool - -p memory_mb= -p cpu_arch= - -p local_gb= -p cpus= - -i deploy_kernel= - -i deploy_ramdisk= - -i deploy_squashfs= - -i ipmi_address= - -i ipmi_username= - -i ipmi_password= - -#. Communicate the node's network interface cards to the Bare Metal service by - creating a port with MAC addresses of each network interface: - - :: - - ironic port-create -a -n - -#. Prepare images that you plan to use to deploy physical machines as - described in :ref:`ironic_prepare_image`. diff --git a/userdocs/fuel-user-guide/configure-additional-components/ironic_prepare_image.rst b/userdocs/fuel-user-guide/configure-additional-components/ironic_prepare_image.rst deleted file mode 100644 index 1eb0732ed..000000000 --- a/userdocs/fuel-user-guide/configure-additional-components/ironic_prepare_image.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. _ironic_prepare_image: - -Prepare a physical machine image --------------------------------- - -If you use default Fuel drivers for Ironic, you must build and upload a -physical machine image into Glance, as well as configure the image with -specific parameters. - -**To prepare a physical machine image:** - -#. Build a physical machine image. - - You can build images for a physical machine using a method of your personal - preference. For example, using Disk Image builder (DIB): - - :: - - disk-image-create -a amd64 -p -o - - **Example:** - - :: - - disk-image-create -a amd64 -p grub2-common,grub-pc, \ - grub-gfxpayload-lists,emacs24-nox,parted baremetal ubuntu-minimal - -#. Upload the image to Glance using the ``glance image-create`` command. - - **Example:** - - :: - - glance image-create --name test --disk-format raw --container-format bare - --file test [--visibility public] - -#. Tag the image with the corresponding metadata. - - **Example:** - - :: - - glance image-update --property cpu_arch=x86_64 - --property hypervisor_type="baremetal" - --property fuel_disk_info=DISK_INFO - - The ``DISK_INFO`` value is a structure that describes the partition layout - required by the image. - - **Example:** - - :: - - ‘[{"name": "sda", "extra": [], "free_space": 11000, "type": "disk", - "id": "vda", "size": 11000, "volumes": [{"mount": "/", "type": - "partition", "file_system": "ext4", "size": 10000}]}]’ - - .. warning:: - Only extended file systems are supported! - -.. seealso:: - - - ``glance help image-create`` - - *Disk Image Builder Documentation* diff --git a/userdocs/fuel-user-guide/configure-additional-components/sahara_configure.rst b/userdocs/fuel-user-guide/configure-additional-components/sahara_configure.rst deleted file mode 100644 index 23084857a..000000000 --- a/userdocs/fuel-user-guide/configure-additional-components/sahara_configure.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. _sahara_configure: - -Configure the Hadoop cluster service ------------------------------------- - -After you deploy your OpenStack environment with -the Hadoop cluster service, upload the -Sahara image to Glance. You must use a -pre-built image for a corresponding Linux distribution. You can build -your own image as described -in the OpenStack Sahara documentation or use one of the pre-built images -available at -`docs.openstack.org/developer/Sahara -`_ -If you use a pre-built image, use the corresponding user name provided on -the same page. - -Sahara supports the following Hadoop platforms: - -- Vanilla Apache Hadoop -- Hortonworks Data Platform (HDP) -- Cloudera Hadoop Distribution (CDH) -- Apache Spark -- MapR - -Typically, the Sahara images are provided in the ``qcow2`` format that is -compatible with the default OpenStack hypervisor KVM. -If you install your environment with VMware vSphere, you must convert -the image to an appropriate format before you upload the image to Glance. - -**To configure the Hadoop cluster service:** - -#. Download or build an appropriate image for the Hadoop cluster. -#. Upload the image to Glance. -#. Log in to Horizon. -#. Register the image in the Sahara Image Registry: - - #. Click :menuselection:`Project --> Data processing --> Image Registry`. - #. Click :guilabel:`Register Image`. - #. Specify the username appropriate to the image you use. - #. Specify a correpsonding plugin and version. - #. Click :guilabel:`Add plugin tags`. - #. Add appropriate tags. - -#. Verify that you have an adequate pool of floating IP addresses available: - - - If you run Neutron networking with - **auto_assign_floating_ip** parameter set to ``False``, provide a - floating IP pool in each Node Group Template. diff --git a/userdocs/fuel-user-guide/configure-environment.rst b/userdocs/fuel-user-guide/configure-environment.rst deleted file mode 100644 index 1ac1f15d1..000000000 --- a/userdocs/fuel-user-guide/configure-environment.rst +++ /dev/null @@ -1,46 +0,0 @@ - -.. raw:: pdf - - PageBreak - -.. _configure-env-ug: - -Configure your environment -========================== - -After you create an OpenStack environment as described in -:ref:`create-env-ug`, you must add nodes, assign roles, and verify your -network configuration. Additionally, you can modify some of the settings -you have already configured, as well as configure other important settings, -such as disk partitioning, network interface bonding, and so on. - -This section includes the following topics: - -.. raw:: pdf - - PageBreak - -.. toctree:: - :maxdepth: 1 - - configure-environment/add-nodes.rst - configure-environment/add-label.rst - configure-environment/change-roles.rst - configure-environment/decompose-services.rst - configure-environment/change-hostname-slave-nodes.rst - configure-environment/select-bootable-device.rst - configure-environment/network-settings.rst - configure-environment/nic-bonding-ui.rst - configure-environment/selectable-offload.rst - configure-environment/map-logical-to-physical-nic.rst - configure-environment/verify-networks.rst - configure-environment/network-templates.rst - configure-environment/customize-partitions.rst - configure-environment/config-drive-format.rst - configure-environment/settings.rst - configure-environment/dns-ntp-support.rst - configure-environment/configure-multipath.rst - configure-environment/nfv.rst - configure-environment/workflows.rst - configure-environment/enable-usb-discovery.rst - configure-environment/configure-vmware-vcenter-settings.rst diff --git a/userdocs/fuel-user-guide/configure-environment/add-label.rst b/userdocs/fuel-user-guide/configure-environment/add-label.rst deleted file mode 100644 index 8828d7894..000000000 --- a/userdocs/fuel-user-guide/configure-environment/add-label.rst +++ /dev/null @@ -1,33 +0,0 @@ - -.. _add-label-ug: - -Label an OpenStack node ------------------------ - -In large deployments, sorting nodes by roles may not be efficient. Therefore, -Fuel provides the capability to add custom labels to OpenStack nodes and later -sort and display the nodes with that label. For example, you can label nodes -located in one rack as *rack #1* and so on. Labels can be added and removed -before or after you deploy an OpenStack environment. - -**Label an OpenStack node:** - -#. Log in to the Fuel web UI. -#. Click :guilabel:`Nodes`. -#. Select a node or nodes that you want to label. -#. Click the label icon. -#. Click :guilabel:`Add label`. -#. Type a :guilabel:`Name` and :guilabel:`Value`. - - **Example:** - - * **Name:** Row - * **Value:** 1 - - .. note:: - You can have multiple labels with identical names and different - values. However, you cannot assign labels with identical names - and different values to one node. For example, you cannot assign - label *Row 1* and *Row 2* to one node, but you can assign them to - different nodes. -#. Click :guilabel:`Apply`. diff --git a/userdocs/fuel-user-guide/configure-environment/add-nodes.rst b/userdocs/fuel-user-guide/configure-environment/add-nodes.rst deleted file mode 100644 index 62ef3aaae..000000000 --- a/userdocs/fuel-user-guide/configure-environment/add-nodes.rst +++ /dev/null @@ -1,46 +0,0 @@ - -.. _add-nodes-ug: - -Add a node to an OpenStack environment --------------------------------------- - -To deploy an OpenStack environment using the Fuel web UI, you must add at -least one controller node. However, for a fully functional cloud you must -allocate a sufficient number of compute and storage nodes. - -An OpenStack node, or a node, is a physical or virtual server that you -provision to run a specific set of OpenStack services. - -A role is a functional set of services that Fuel installs as a whole on a -node, usually in its own disk partition. Some roles can be combined in one -node. - -The number of discovered unallocated and total nodes is displayed in the upper -right corner in the Fuel web UI. - -For more information, see -*System Requirements* in *Fuel Installation Guide*. - -**To add a node to an OpenStack environment:** - -#. Log in to the Fuel web UI. -#. In the :guilabel:`Dashboard` tab, click :guilabel:`Add nodes`. -#. Assign a role or roles to the node by selecting the corresponding option. -#. In the list of discovered nodes, select a physical or virtual node to - provision. -#. Optionally, display the node hardware configuration by clicking the - :guilabel:`Settings` icon next to the discovered node. -#. Click :guilabel:`Apply Changes`. -#. Repeat step 2 - step 6 for all nodes that you want to include into this - OpenStack environment. - - After you add nodes, Fuel enables you to deploy your OpenStack environment. - However, you may need to apply additional changes to fully address your - infrastructure requirements. - -.. seealso:: - - - *System requirements* in *Fuel Installation Guide* - - :ref:`add-label-ug` - - :ref:`change-hostname-slave-nodes` - - :ref:`cli-nodes-empty-role` diff --git a/userdocs/fuel-user-guide/configure-environment/change-hostname-slave-nodes.rst b/userdocs/fuel-user-guide/configure-environment/change-hostname-slave-nodes.rst deleted file mode 100644 index 401954fca..000000000 --- a/userdocs/fuel-user-guide/configure-environment/change-hostname-slave-nodes.rst +++ /dev/null @@ -1,50 +0,0 @@ - -.. _change-hostname-slave-nodes: - -Modify the Fuel Slave node host name ------------------------------------- - -You can modify host names of the Fuel Slave nodes before you deploy an -OpenStack environment. This functionality enables you to assign host names -that match your corporate standards or a naming convention of your choice. -You cannot change a host name of a Fuel Slave node after you deploy an -OpenStack environment. - -**To modify the Fuel Slave node host name using Fuel web UI:** - -#. Log in to the Fuel web UI. -#. Click the :guilabel:`Nodes` tab. -#. Click the settings icon next to the corresponding node. -#. Click the edit icon: - - .. image:: /_images/deliverables/scr_change_hostname.png - :width: 60% - -#. Type the new host name. -#. Click :guilabel:`Close`. - -**To modify the Fuel Slave node host name using Fuel CLI:** - -#. Log in to the Fuel Master node CLI. -#. Type: - - .. code-block:: console - - fuel node --node --hostname - - .. list-table:: - :widths: 10 25 - :header-rows: 1 - - * - Value - - Description - * - - - A specific node indentificator. You can get the information about the - node ID by typing: - - .. code-block:: console - - fuel nodes - - * - - - A new host name for the selected node. diff --git a/userdocs/fuel-user-guide/configure-environment/change-roles.rst b/userdocs/fuel-user-guide/configure-environment/change-roles.rst deleted file mode 100644 index 746c7f9c5..000000000 --- a/userdocs/fuel-user-guide/configure-environment/change-roles.rst +++ /dev/null @@ -1,29 +0,0 @@ - -.. _change-roles: - -Change the role of a node --------------------------- - -If you have assigned a wrong role or want to add additional roles to a node, -you can modify this setting before you deploy an OpenStack environment, as -well as after the deployment. - -**To change the role of a node:** - -#. In the Fuel web UI, click :guilabel:`Nodes`. -#. Select a node. - - * If the OpenStack environment is not yet deployed: - - #. Click :guilabel:`Edit Roles`. - #. Modify the role as required. - - * If the OpenStack environment has been already deployed: - - #. Click :guilabel:`Delete`. - - Fuel changes the node's status to *Unallocated*. - - #. Click :guilabel:`Add Node`. - #. Select the node and assign a new role or roles to the node as - described in :ref:`add-nodes-ug`. diff --git a/userdocs/fuel-user-guide/configure-environment/config-drive-format.rst b/userdocs/fuel-user-guide/configure-environment/config-drive-format.rst deleted file mode 100644 index 946e818d1..000000000 --- a/userdocs/fuel-user-guide/configure-environment/config-drive-format.rst +++ /dev/null @@ -1,40 +0,0 @@ -.. _config-drive-format: - -Change the configuration drive format -------------------------------------- - -For legacy reasons, Fuel uses the VFAT configuration drive format which is the -default option for live migration. But as the default format of the -configuration drive for OpenStack environments is ISO 9660, you can change the -VFAT to the ISO 9660 format using the ``config_drive_format`` option. - -**To change the configuration drive format using Fuel CLI:** - -#. Log in to the Fuel Master node CLI. -#. Download the configuration files: - - .. code-block:: console - - fuel --env= deployment --default - - The default deployment information is downloaded to - ``//deployment_``. - -#. Edit *every* ``.yaml`` file: - - #. Find or add the ``compute`` section to the ``.yaml`` file. - #. In this section, add the following parameter: - - .. code-block:: console - - compute: - config_drive_format option: iso9660 - -#. Upload the updated configuration files to the ``//deployment_`` - directory: - - .. code-block:: console - - fuel --env= deployment --upload - - Now, you can proceed with the environment deployment. \ No newline at end of file diff --git a/userdocs/fuel-user-guide/configure-environment/configure-multipath.rst b/userdocs/fuel-user-guide/configure-environment/configure-multipath.rst deleted file mode 100644 index 88f303893..000000000 --- a/userdocs/fuel-user-guide/configure-environment/configure-multipath.rst +++ /dev/null @@ -1,100 +0,0 @@ -.. _configure-multipath: - -Configure an OpenStack environment on nodes with multipath block devices -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can deploy your OpenStack environment on servers with disks provided -by storage systems with multipath I/O. - -The **advantages** of using the multipath disk configuration feature include: - -* Proper discovering of multipath block devices and showing one storage - device on server per a single multipath back-end block device. - -* Mapping multipath block devices to a host operating system, Cinder LVM, - MongoDB storage, and so on. - -* Deploying an OpenStack environment with multiple multipath block devices - attached to a single node. - -* Combining a configuration of multipath block devices with the directly - attached drives within a single node. - -.. note:: - - Fuel supports only multipath block devices provided by Host-Based - Adapter (HBA). - -**To configure an OpenStack environment on nodes with multipath block devices:** - -#. Verify that the default bootable device meets the needs of your - environment. - - By default, Fuel boots the first detected disk. You may need to change - the default settings. For example, when the boot-loader is configured - to boot from ``LUN`` other than ``LUN0``. If you need to specify - the bootable device, complete the steps described in :ref:`select-bootable-device`. - -#. If you need an additional HBA card driver to run in the environment: - - #. Log in to the Fuel Master node. - #. Add the HBA card driver by running: - - .. code-block:: console - - fuel-bootstrap build --package --label fc_bootstrap - - .. note:: - - If the required package is not located in the preconfigured - for bootstrap repositories, specify the required repository by passing - the :option:`--repo 'type uri distribution [components][,priority]'` - argument to the :command:`fuel-bootstrap build` command. - - #. Log in to the Fuel web UI. - #. On the :guilabel:`Nodes` tab, view the disks information on receiving - the ``new node appeared online`` notification. - - The disks` details include the paths that correspond to the underlying - paths to the multipath block devices. - - #. Configure the IBP (image-based provisioning) images for provisioning: - - * Using the Fuel web UI: - - #. Log in to the Fuel web UI. - #. Click the :guilabel:`Settings > Provision` tab. - #. Specify the :guilabel:`Initial packages` to provision. - - * Using the Fuel CLI: - - #. Log in to the Fuel Master node. - #. Download the OpenStack environment configuration file: - - .. code-block:: console - - fuel settings --env-id= --download - - #. Open ``settings_.yaml`` for editing. - #. In the ``editable/provision/packages/value`` section, - change the initial package name. - - .. note:: - - If the required package is located in the repository that is not - included in the list, add the repository details to - ``editable/repo_setup/repos/value`` of the - ``settings_.yaml`` file. - - #. Upload the modified settings to Fuel: - - .. code-block:: console - - fuel settings --env-id= --upload - -#. Deploy your OpenStack environment as described in :ref:`deploy-env`. - -.. seealso:: - - * `Dynamically build Ubuntu-based bootstrap on the Fuel master node - `_ diff --git a/userdocs/fuel-user-guide/configure-environment/configure-vmware-vcenter-settings.rst b/userdocs/fuel-user-guide/configure-environment/configure-vmware-vcenter-settings.rst deleted file mode 100644 index 37a5108b1..000000000 --- a/userdocs/fuel-user-guide/configure-environment/configure-vmware-vcenter-settings.rst +++ /dev/null @@ -1,31 +0,0 @@ -.. _configure-vmware-vcenter-settings: - -================================= -Configure VMware vCenter settings -================================= - -If your environment is integrated with VMware vCenter, you can specify a -Certificate Authority (CA) bundle file to use for verifying the VMware vCenter -server certificate for the OpenStack Compute service, OpenStack Block Storage -service, and OpenStack Image service. - -**To configure the VMware vCenter certificate verification:** - -#. Log in to the Fuel web UI. -#. Navigate to the :guilabel:`VMware` tab. -#. Configure the VMware vCenter certificate verification depending on your - environment needs: - - * If you plan to deploy an environment for testing purposes or want to - speed up the deployment process, disable the certificate - verification by selecting - :guilabel:`Bypass vCenter certificate verification` in the - :guilabel:`VMware vCenter Settings` section. - * If VMware vCenter is using a self-signed certificate: - - #. In the :guilabel:`CA file` section, upload a custom CA certificate. - #. Leave :guilabel:`Bypass vCenter certificate verification` unchecked. - * To use a VMware vCenter server certificate emitted by a known CA, for - example, GeoTrust, leave the :guilabel:`CA file` section empty and the - :guilabel:`Bypass vCenter certificate verification` unchecked. -#. Click :guilabel:`Save Changes`. \ No newline at end of file diff --git a/userdocs/fuel-user-guide/configure-environment/customize-partitions.rst b/userdocs/fuel-user-guide/configure-environment/customize-partitions.rst deleted file mode 100644 index 9803a4985..000000000 --- a/userdocs/fuel-user-guide/configure-environment/customize-partitions.rst +++ /dev/null @@ -1,58 +0,0 @@ - -.. _customize-partitions-ug: - -Configure disk partitioning ---------------------------- - -By default, Fuel allocates a balanced amount of disk space for -all components that will be installed on the corresponding node. -After you assign a role or roles to a node, you can modify the -disk partition as needed. - -If you modify node roles, Fuel resets the disk partition to default settings. - -The following table describes the partition types that you can configure -for each node. - -.. list-table:: **Disk partition types** - :widths: 10 25 - :header-rows: 1 - - * - Type of partition - - Description - * - Base system - - Comprehensive of swap space, includes operating system and basic - software option. - * - Virtual storage - - Storage for virtual instances. - * - Image storage - - Glance stores virtual instance images in this partition. - * - Cinder - - Storage allocated for Cinder. - * - Ceph and Ceph Journal - - Storage allocated for Ceph. - * - MongoDB - - Storage used for Ceilometer information stored in MongoDB. - * - MySQL - - Storage for Zabbix statistics. - -**To configure disk partitioning:** - -#. In the Fuel web UI, click :guilabel:`Nodes`. -#. Select a node or nodes. - - .. note:: - You can select multiple nodes of the same role. The nodes with - the same role must have identical hardware configuration. You cannot - change configuration of multiple nodes with different roles or hardware - in one transaction. - -#. Click :guilabel:`Disk Configuration`. -#. Click on a partition that you want to modify. -#. In the :guilabel:`Volume Groups`, adjust the partition size using the - slider. -#. Alternatively, type the partition size in the corresponding field. - - Fuel adjusts the number you type to satisfy block size boundary - requirements. The display adjusts to show the new allocation. -#. Click :guilabel:`Apply`. diff --git a/userdocs/fuel-user-guide/configure-environment/decompose-services.rst b/userdocs/fuel-user-guide/configure-environment/decompose-services.rst deleted file mode 100644 index b5724dc98..000000000 --- a/userdocs/fuel-user-guide/configure-environment/decompose-services.rst +++ /dev/null @@ -1,184 +0,0 @@ -.. _decompose_services: - -====================================== -Decompose the controller node services -====================================== - -You can run different services on dedicated OpenStack nodes depending on -needs of your OpenStack environment. Using the Fuel CLI you can move -controller node services out of the existing controller role into -custom roles and assign these roles to dedicated nodes. This capability -may be helpful while managing highly-loaded OpenStack environments. - -The services available for decomposition are: - -* Neutron (including L3 agents, LBaaS, and others) -* Keystone -* MySQL DB -* RabbitMQ - -**To decompose the controller node services:** - -#. Log in to the Fuel Master node console. -#. Download the controller's role configuration: - - .. code-block:: console - - fuel role --release 2 --role controller --file controller.yaml - - You will get the configuration file with the following content: - - .. code-block:: yaml - - name: controller - meta: - conflicts: - - compute - description: > - The Controller initiates orchestration activities and provides an - external API. Other components like Glance (image storage), Keystone - (identity management), Horizon (OpenStack dashboard) and Nova-Scheduler - are installed on the controller as well. - group: base - has_primary: true - limits: - min: 1 - overrides: - - condition: settings:neutron_advanced_configuration.neutron_l3_ha.value == true - message: > - Neutron L3 HA requires at least 2 Controller nodes to function - properly. - min: 2 - recommended: 3 - name: Controller - public_for_dvr_required: true - public_ip_required: true - tags: - - controller - - rabbitmq - - database - - keystone - - neutron - update_required: - - compute - - cinder - weight: 10 - volumes_roles_mapping: - - allocate_size: min - id: os - - allocate_size: min - id: logs - - allocate_size: all - id: image - - allocate_size: min - id: mysql - - allocate_size: min - id: horizon - -#. In ``controller.yaml``, remove the tag from the ``tags`` section that - corresponds to the service you need to move to a dedicated node and save - the changes. - - For example, remove the ``database`` tag and save the changes. Now, your - controller role configuration file does not include the ``database`` tag - in the ``tags`` section, and the ``mysql`` record in - the ``volumes_roles_mapping`` section: - - .. code-block:: yaml - :emphasize-lines: 24-28, 33-41 - - name: controller - meta: - conflicts: - - compute - description: > - The Controller initiates orchestration activities and provides an - external API. Other components like Glance (image storage), Keystone - (identity management), Horizon (OpenStack dashboard) and Nova-Scheduler - are installed on the controller as well. - group: base - has_primary: true - limits: - min: 1 - overrides: - - condition: settings:neutron_advanced_configuration.neutron_l3_ha.value == true - message: > - Neutron L3 HA requires at least 2 Controller nodes to function - properly. - min: 2 - recommended: 3 - name: Controller - public_for_dvr_required: true - public_ip_required: true - tags: - - controller - - rabbitmq - - keystone - - neutron - update_required: - - compute - - cinder - weight: 10 - volumes_roles_mapping: - - allocate_size: min - id: os - - allocate_size: min - id: logs - - allocate_size: all - id: image - - allocate_size: min - id: horizon - -#. Upload the updated controller role: - - .. code-block:: console - - fuel role --release 2 --role controller --update --file controller.yaml - -#. Create a new custom role for the service you need to remove from - the controller node: - - #. For example, create and edit ``database.yaml`` specifying the removed - entries from the controller role configuration: - - .. code-block:: yaml - - name: database - meta: - name: Database - description: > - Separated DB from controller. - group: base - conflicts: - - controller - - compute - has_primary: true - limits: - min: 1 - update_required: - - controller - - database - tags: - - database - weight: 100 - volumes_roles_mapping: - - allocate_size: min - id: os - - allocate_size: min - id: mysql - - #. In the Fuel CLI, create the new role based on the ``database.yaml`` - configuration file: - - .. code-block:: console - - fuel role --release 2 --create --file database.yaml - -#. Assign the newly created role using the Fuel web UI or CLI as described - in :ref:`change-roles`. - -#. To apply the changes, deploy your OpenStack environment. - -.. seealso:: - - * :ref:`cli-roles` \ No newline at end of file diff --git a/userdocs/fuel-user-guide/configure-environment/dns-ntp-support.rst b/userdocs/fuel-user-guide/configure-environment/dns-ntp-support.rst deleted file mode 100644 index b5d7fc3f3..000000000 --- a/userdocs/fuel-user-guide/configure-environment/dns-ntp-support.rst +++ /dev/null @@ -1,21 +0,0 @@ - -.. _dns-ntp-support-ug: - -Change the DNS and NTP server settings --------------------------------------- - -If the Fuel Master node does not have access to the Internet -or if you plan to disable Internet access after deployment, you -may want to change the NTP and DNS servers for the nodes and omit -routing through the Fuel Master node. - -**To change the DNS and NTP server settings:** - -#. In the Fuel web UI, click the guilabel:`Networks` tab. -#. Click :guilabel:`Other`. -#. Type the DNS server IP address or NTP server IP address or FQDN. -#. Click :guilabel:`Save Settings`. - - .. note:: - Fuel does not verify if the specified DNS and NTP services are - available. Verify that you specify correct values. diff --git a/userdocs/fuel-user-guide/configure-environment/enable-usb-discovery.rst b/userdocs/fuel-user-guide/configure-environment/enable-usb-discovery.rst deleted file mode 100644 index 8288c992e..000000000 --- a/userdocs/fuel-user-guide/configure-environment/enable-usb-discovery.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _enable-usb-discovery: - -Enable USB devices discovery ----------------------------- - -When Fuel discovers Fuel Slave nodes, it does not automatically detect USB -devices. However, for testing or other purposes you may need to enable -USB devices discovery. - -**To enable USB devices discovery:** - -#. Log in to Fuel Master node CLI. -#. Open the ``/etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml`` file - for editing. -#. Add ``report_usb_block_devices`` to the ``extend_kopts`` string. - - **Example:** - - .. code-block:: console - - extend_kopts: "biosdevname=0 net.ifnames=1 debug ignore_loglevel - log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 report_usb_block_devices" - -#. Rebuild the bootstrap image: - - :: - - fuel-bootstrap build --activate - -#. Reboot all discovered Fuel Slave nodes. - - The nodes boot the new bootstrap image. diff --git a/userdocs/fuel-user-guide/configure-environment/map-logical-to-physical-nic.rst b/userdocs/fuel-user-guide/configure-environment/map-logical-to-physical-nic.rst deleted file mode 100644 index 9450cc33b..000000000 --- a/userdocs/fuel-user-guide/configure-environment/map-logical-to-physical-nic.rst +++ /dev/null @@ -1,23 +0,0 @@ - -.. _map-logical-to-physical: - -Map a logical network to a physical interface ---------------------------------------------- - -You may want to allocate specific network interfaces -to handle different types of network traffic to achieve better -performance in your OpenStack environment. -Fuel enables you to modify mappings for your entire network, except for the -*Admin* network for which you can make changes only during the Fuel -Master node installation. - -Network interface mapping can be modified after you deploy an OpenStack -environment. The ``net-config`` task updates the networking configuration. - -**To map a logical network to a physical interface:** - -#. In the Fuel web UI, click :guilabel:`Nodes`. -#. Select a node. -#. Click :guilabel:`Configure Interfaces`. -#. Drag and drop a logical network to the corresponding physical interface - or bond. diff --git a/userdocs/fuel-user-guide/configure-environment/network-settings.rst b/userdocs/fuel-user-guide/configure-environment/network-settings.rst deleted file mode 100644 index db89d4bf2..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-settings.rst +++ /dev/null @@ -1,72 +0,0 @@ - -.. raw:: pdf - - PageBreak - -.. _network-settings-ug: - -Configure network settings --------------------------- - -After you select a network topology in the deployment -wizard, you can further configure Neutron L2 and L3 settings, -as well as modify the node network group configuration. - -Fuel creates the *default* node network group that includes the Public, -Storage, Management, Private, and Baremetal networks if you installed -the OpenStack Bare Metal service. The ``default`` node group also uses -the shared Admin network. You can modify parameters of the -Admin network for all other node network groups, if any, except the ``default`` -node network group. - -.. note:: - - When you deploy an environment using Fuel, you can exclude - specific IP addresses so that Fuel does not assign them. - This helps to avoid network conflicts in - case these IP addresses were previously reserved by other - network entities. - - To prevent IP address collisions, set the IP address - range to be used by Fuel. For example, - for nodes and VIPs, excluding the reserved IPs. - In addition, you can specify multiple - IP address ranges. If you have an IP address in use in the middle - of the network IP address range, you can split the range to exclude - the IP addresses in use. - -Gateway will be set for all the networks when using multiple -node network groups. - -Additionally, Fuel provides a capability to configure networks using network templates. -You can add or remove a network from a node network group -through API when using network templates. A set of networks -for a particular node network group on the Fuel web UI will be -changed accordingly. - -The :menuselection:`Networks` tab also contains the network verification section -to perform the following checks: - -* L2 connectivity checks between every node in the environment. -* DHCP discovery check on all nodes. -* Packages repository connectivity check from the Fuel Master node. -* Packages repository connectivity check from Fuel Slave nodes - through Public and Admin (PXE) networks. - -**To configure network settings:** - -#. In the Fuel web UI, click the :guilabel:`Network` tab. -#. Select a setting and modify as needed. - -.. note:: - - You can find IP addresses assigned to nodes in the Public and Management networks - in the :guilabel:`Management IP` and :guilabel:`Public IP` fields in the summary - section of a node details pop-up. - -.. seealso:: - - - :ref:`nic-bonding-ui` - - :ref:`selectable-offload` - - :ref:`map-logical-to-physical` - - :ref:`ug-network` \ No newline at end of file diff --git a/userdocs/fuel-user-guide/configure-environment/network-templates.rst b/userdocs/fuel-user-guide/configure-environment/network-templates.rst deleted file mode 100644 index a240e4ea4..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-templates.rst +++ /dev/null @@ -1,31 +0,0 @@ -.. _network-templates-intro: - -Deploy network configurations using network templates -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -By default, Fuel configures the following networks (Linux bridges): Public, -Private, Storage, Admin (PXE), and Management. In addition, if you install the -OpenStack Bare Metal service, Fuel creates the Baremetal network. If you need -to add a custom network or do not need any of the default networks, you can -configure or delete the required networks through network templates. - -Network templates enable you to: - -* Create a custom set of networks. -* Create mappings of network roles to networks. -* Use a network on a specific node only if a corresponding node role is - configured on the node -* Implement custom networking topologies, such as sub-interface bonding, - and so on. - -This section includes the following topics: - -.. toctree:: - :maxdepth: 1 - - network-templates/network-templates-overview.rst - network-templates/network-templates-limitations.rst - network-templates/network-templates-structure.rst - network-templates/network-templates-create.rst - network-templates/network-templates-delete.rst - network-templates/network-templates-examples.rst diff --git a/userdocs/fuel-user-guide/configure-environment/network-templates/examples/one-network.rst b/userdocs/fuel-user-guide/configure-environment/network-templates/examples/one-network.rst deleted file mode 100644 index 75bb5d66d..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-templates/examples/one-network.rst +++ /dev/null @@ -1,29 +0,0 @@ -.. _one-network: - -Configure a single network topology ------------------------------------ - -Fuel supports a single network configuration where one network serves -all OpenStack traffic. This configuration is common in -proof of concept deployments where no additional networks are -available. - -**To configure a single network:** - -#. Save `network template for one network - `_ - as ``network_template_.yaml``. - -#. Upload the network template by typing: - - :: - - # fuel network-template --upload --env - -#. Deploy the OpenStack environment. -#. Allocate the correct floating IP pool to the network. - - #. Clear the gateway from `router04`. - #. Delete the `admin_floating_net__subnet` subnet. - #. Create a new subnet with the floating IP pool from the single network. - #. Set gateway on `router04`. diff --git a/userdocs/fuel-user-guide/configure-environment/network-templates/examples/two-networks.rst b/userdocs/fuel-user-guide/configure-environment/network-templates/examples/two-networks.rst deleted file mode 100644 index 3ca79b497..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-templates/examples/two-networks.rst +++ /dev/null @@ -1,75 +0,0 @@ -.. _two-networks: - -Configure the two-network topology ----------------------------------- - -Fuel supports two-network configuration where one network is -dedicated for PXE traffic and another network for -all other traffic. - -**To configure a two-network topology:** - -1. Create a new network for all non-PXE traffic: - - :: - - # fuel network-group --create --name everything --cidr - --gateway --nodegroup - -2. Set the ``render_addr_mask`` parameter to `internal` for this network by - typing: - - :: - - # fuel network-group --set --network 39 --meta '{"name": - "everything", "notation": "cidr", "render_type": null, "map_priority": 2, - "configurable": true, "use_gateway": true, "render_addr_mask": - "internal", "vlan_start": null, "cidr": "10.108.31.0/24"}' - - This parameter is required by the Fuel library. The Fuel library requires - a value called ``internal_address`` for each node. - This value is set to the node's IP address from a network group which has - ``render_addr_mask`` set to `internal` in its metadata. Therefore, update - ``render_addr_mask`` for this network. - -3. Save `network template for two networks - `_ - as ``network_template_.yaml``. - - .. note:: - Verify that ``nic_mapping`` matches your configuration. - -4. Upload the network template by typing: - - :: - - # fuel network-template --upload --env - -5. Deploy the environment. -6. After Fuel completes the deployment, verify that only one bridge is - configured by typing: - - :: - - # ip -4 a - - **Example of system output:** - - :: - - 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group - default - inet 127.0.0.1/8 scope host lo - valid_lft forever preferred_lft forever - 8: br-fw-admin: mtu 1500 qdisc noqueue - state UP group default - inet 10.108.5.3/24 brd 10.108.5.255 scope global br-fw-admin - valid_lft forever preferred_lft forever - 16: vr-host-base: mtu 1500 qdisc - pfifo_fast state UP group default qlen 1000 - inet 240.0.0.5/30 scope global vr-host-base - valid_lft forever preferred_lft forever - 30: hapr-host: mtu 1500 qdisc pfifo_fast - state UP group default qlen 1000 - inet 240.0.0.1/30 scope global hapr-host - valid_lft forever preferred_lft forever diff --git a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-create.rst b/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-create.rst deleted file mode 100644 index d201247e8..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-create.rst +++ /dev/null @@ -1,128 +0,0 @@ -.. _network-templates-create: - -Create a network template -------------------------- - -You can use one of the network templates provided in -:ref:`network-templates-examples`. -However, if these templates do not meet your networking requirements, -you can create your own. We strongly recommend that you use the -``default.yaml`` network template provided in this documentation to -build your own network template. - -.. note:: - When you configure a network using a network template, you cannot apply - changes to the nodes network configuration using the Fuel web UI. For - example, if you configure an OpenStack environment using network - templates, deploy the OpenStack environment, and later decide to add - new nodes to that environment, you must update network configuration - of these nodes using a network template and do not use the Fuel web UI. - - However, templates do not describe the level 2 and level 3 network - settings. Therefore, you must set them using Fuel web UI, CLI, or API. - -After uploading a network template, you must create and/or -delete networks and node groups using the Fuel CLI to reflect the uploaded -network configuration. Otherwise, the configuration specified in the network -template will not take effect and may result in a malfunction. - -**To create a network template:** - -#. Create a ``.yaml`` file. -#. Specify your network configuration in the ``.yaml`` file following - the conventions described in :ref:`network-templates-structure`. -#. Log in to the Fuel Master node CLI. -#. Display the ID of the environment in which you want to upload the - template: - - :: - - fuel environment - -#. Upload the network template to Fuel: - - :: - - fuel --env network-template --upload --dir - - **Example:** - - :: - - fuel --env 1 network-template --upload --dir /home/stack/ - -#. Add or delete custom networks that you have introduced through - the network template: - - * If you need to delete a network: - - #. View the ID of the network by typing: - - :: - - fuel network-group - - **Example of system response:** - - :: - - id | name | vlan_start | cidr | gateway |group_id - ---+---------------+------------+--------------+----------+-------- - 24 | private | | | | 4 - 23 | private | | | | 5 - 22 | storage | 102 | 10.10.1.0/24 | 10.1.1.1 | 5 - 25 | management | 101 | 10.10.0.0/24 | 10.0.0.1 | 4 - 21 | public | | 10.10.0.0/24 | 10.10.0.1| 4 - - #. Delete the required network using the network ID. - - :: - - fuel network-group --delete --env --network - - - * If you need to add a new network, type: - - :: - - fuel network-group --create --node-group --name - --vlan --cidr - -#. Add or delete custom networks as described in - :ref:`cli-network-group`. - -#. Configure L2 and L3 network settings: - - .. note:: You cannot modify VLAN settings through the Fuel web UI or CLI - Configure VLAN settings in the network template. - - * Using Fuel web UI: - - #. Log in to the Fuel web UI. - #. Click :guilabel:`Networks`. - #. Configure :guilabel:`Network Settings` as required. - - .. note:: If you add additional node network group with different from the - default node network group settings, update the network template - with the required changes. - - * Using Fuel CLI: - - #. Log in to the Fuel CLI. - #. Download network configuration: - - :: - - fuel --env network --download - - #. Make the required changes in the network ``.yaml`` file. - #. Upload the configuration to the Fuel Master node: - - :: - - fuel --env network --upload - -.. seealso:: - - - :ref:`cli-network-group` - - :ref:`cli-network-template` diff --git a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-delete.rst b/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-delete.rst deleted file mode 100644 index f4c920fc5..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-delete.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _network-template-delete: - -Delete a network template -------------------------- - -You can delete a network template that you have previously uploaded. - -.. warning:: - - Do not delete network templates that are used in your OpenStack - environment as it may result in a failure of the whole network - configuration. - -**To delete a network template:** - -#. Log in to the Fuel Master node CLI. -#. Type: - - :: - - fuel --env network-template --delete - - **Example:** - - :: - - fuel --env 1 network-template --delete - -.. seealso:: - - - :ref:`cli-network-group` - - :ref:`cli-network-template` diff --git a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-examples.rst b/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-examples.rst deleted file mode 100644 index 24e46d09d..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-examples.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _network-templates-examples: - -Network template examples -========================= - -This section provides examples of network configurations -using network templates. You can use the default template -and modify it for your requirements or use any of the templates provided -in the `network templates folder `_. - -The following table describes network template examples: - -.. list-table:: **Examples of network templates** - :widths: 10 10 - :header-rows: 1 - - * - Template - - Description - * - ``default.yaml`` - - The default network template deploys the basic configuration that you - can deploy using the Fuel web UI. You can use this template to create - your own network template. Additional information about network - configuration using network templates provided in the file. - * - ``one_network.yaml`` - - A network template that describes a configuration in which one network - serves all traffic. - * - ``two_networks.yaml`` - - A network template that describes a configuration in which all traffic - is served by two networks. - -.. toctree:: - :maxdepth: 1 - - examples/one-network.rst - examples/two-networks.rst diff --git a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-limitations.rst b/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-limitations.rst deleted file mode 100644 index 2b383ec12..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-limitations.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. _network-templates-limitations: - -Network template limitations ----------------------------- - -When using network templates, consider the following limitations: - -* All operations with templates must be performed through CLI or API. - The Fuel web UI does not support network templates. -* The Public network which maps to the External network in OpenStack - cannot be removed. -* When you use network templates, do not download and modify Fuel - deployment configurations using the ``fuel download`` and - ``fuel upload`` commands as it may result in a system malfunction. -* Mapping of network roles to networks, as well as network topology cannot - be configured for individual nodes. They can only be set for a node role - or/and node group. -* Network verification in the Fuel web UI has limited support. diff --git a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-overview.rst b/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-overview.rst deleted file mode 100644 index e6c932585..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-overview.rst +++ /dev/null @@ -1,17 +0,0 @@ -.. _network-templates-overview: - -Overview of network templates ------------------------------ - -A network template is a ``.yaml`` file that contains network configuration -for an OpenStack environment. To apply custom network -configurations, create and configure -the template according to your environment requirements. For your convenience, -use the following :ref:`network-templates-examples`. - -The name of the network template -must follow this convention: ``network_template_.yaml``. Verify the -ID of your OpenStack environment by running the ``fuel environment`` command. - -For example, if the ID of an OpenStack environment is ``1``, the name of the -template is ``network_template_1.yaml``. diff --git a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure.rst b/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure.rst deleted file mode 100644 index ad3843b79..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. _network-templates-structure: - -Structure of network templates ------------------------------- - -You can use the structure described in this section, as well -as the default template, to create a template that meets the -requirements of your configuration. - -Network parameters are defined in the ``adv_net_template`` -section in the ``network_template_.yaml`` file. - -.. toctree:: - :maxdepth: 1 - - network-templates-structure/network_scheme.rst - network-templates-structure/nic_mapping.rst - network-templates-structure/templates_for_node_role.rst - network-templates-structure/network_assignment.rst diff --git a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/network_assignment.rst b/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/network_assignment.rst deleted file mode 100644 index 03c730f72..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/network_assignment.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. _network-assignment: - -network_assignment ------------------- - -**Description** - -Describes mapping between endpoints and network names. The **Example** -section describes the mapping that Fuel configures by default -without using templates. The set of networks can be changed -using API. - -**Example** - -:: - - network_assignments: - storage: - ep: br-storage - private: - ep: br-prv - public: - ep: br-ex - management: - ep: br-mgmt - fuelweb_admin: - ep: br-fw-admin diff --git a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/network_scheme.rst b/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/network_scheme.rst deleted file mode 100644 index 26bbefdab..000000000 --- a/userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/network_scheme.rst +++ /dev/null @@ -1,200 +0,0 @@ -.. _network-scheme: - -network_scheme --------------- - -**Description** - -Defines the name of the network template as well as the following -parameters that are applied to each network that needs to be -configured: - -* ``priority`` - defines the order in which the network templates will - be applied to a node. The values range 0 to 64000. - For example, you can set ``100``, ``200``, ``300`` with ``100`` - being the highest priority template. - -* ``transformations`` - a sequence of actions that builds the required - network configuration. For example: ``add-br`` - add a network - bridge, ``add-port`` - add a network port. The Puppet L23network - module creates network objects described in the ``transformations`` - section that connect physical interfaces with logical endpoints. Order - of commands specified in this section is significant. - - The sequence of commands that create network configuration must - be reflected in the transformation section: - - * For service networks: - - #. Create a Linux bridge. By default, if you do not specify a - provider a Linux bridge is created. - #. Create a network port that connects the Linux bridge and the - physical network interface. - - * For workload networks: - - #. Create an OVS bridge as a first point of connection between - the OpenStack Networking service and the physical network - interface. - - #. Create a Linux bridge. Since an OVS bridge cannot directly connect - to a physical interface, a Linux bridge is required. - - #. Create a patch that connects Linux and OVS bridges. - - #. Create a network port that connects the Linux bridge and the - physical network interface. - - You can specify the following commands in the ``transformation`` - section: - - * ``add-br`` - creates a bridge. By default, creates a Linux - bridge. You can specify the following parameters for this command: - - * ``name`` - name of the network bridge. For example, ``br-admin``. - - * ``provider`` - a network technology such as Open vSwitch (OVS) or - Linux Bridge, that connects physical interface with - the OpenStack Networking service. Default provider is Linux - Bridge. The options are: ``linux``, ``ovs``. - - * ``mtu`` - (optional) enables you to specify MTU for this network bridge. - - * ``add-port`` - create a port that connects a Linux bridge with a - physical network interface. You can specify the following parameters - for this command: - - * ``name`` - name of the network port. - - * ``bridge`` - name of the bridge for which the port is created. - - * ``type`` - (optional) A type of the OVS interface for the port. - Default value is ``internal``. Available options include: - ``internal``, ``system``, ``tap``, ``gre``, ``null``. - See the OVS documentation for more details. Specify - - * ``trunks`` - (optional) a set of 802.1q tags in the form of integers - from 0 to 4095) that are allowed to pass through if the "tag" - option equals 0. Available options include: - - * Empty list - all traffic passes - * 0 - untagged traffic only. - * 2-4095 - traffic with the specified tag passes. - For example, 10,10,20. - - * ``port_properties`` - (optional) a list of additional OVS port - properties to modify them in OVS database. - - * ``interface_properties`` (optional) a list of additional OVS interface - properties to modify them in OVS database. - - * ``add-patch`` - connects network bridges. Available parameters include: - - * ``bridges`` - a pair of bridges to connect. You can specify either - bridges of the same type or of different types. - - * ``peers`` - (optional) abstract names for each end of the patch. - - * ``tags`` - (optional) a pair of integers that represent an - 802.1q tag of traffic that is captured from a corresponding - OVS bridge. Available values include: - - * 0 - only the untagged traffic passes through - * 1-4094 - the bond allows only the traffic with the specific tag. - Specify the tags in the ``trunks`` parameter. - - * ``trunks`` - (optional) a set of 802.1q tags in a form of - integers from 2 to 4095 which are allowed to pass through if the - ``tag`` parameter is set to ``0``. Available values include: - - * Empty list - all traffic passes (default) - * 0 - untagged traffic only - * 2-4095 - traffic with the specified tag passes). For example, 0,10,20. - - * ``add-bond`` - combines two or more network interfaces for redundancy - and creates a network object called bond. You can specify - the following parameters for this command: - - * ``name`` - name of the network port. - - * ``interfaces`` - a set of two or more network interfaces that you - want to bind. For example, ``eth1, eth2``. - - * ``bridge`` - name of the bridge on which the bond must be created. - - * ``tag`` - (optional) a 802.1q tag of traffic which - received from an OVS bridge. Available values include: - - * 0 - the bond ignores the tag and allows all traffic to pass - through. - - * 1 - 4094 - the bond allows only the traffic with the specific tag. - Specify the tags in the ``trunks`` parameter. - - * ``trunks`` - (optional) a set of 802.1q tags in a form of - integers from 2 to 4095 which are allowed to pass through if the - ``tag`` parameter is set to ``0``. Available values include: - - * Empty list - all traffic passes (default) - * 0 - untagged traffic only - * 2-4095 - traffic with the specified tag passes). For example, 0,10,20. - - * ``properties`` - (optional) a list of additional OVS bonded port - properties to modify them in the OVS database. Use this parameter - to set the aggregation mode and balancing strategy, to configure LACP, - and so on. For more informations, see the OVS documentation. - -* ``endpoints`` - lists logical interfaces or bridges - with assigned IP addresses to which you can map one or more network - roles. - -* ``roles`` - mapping of a network traffic to a logical endpoint. When you - apply multiple templates to one node, verify that this parameter - in one template does not contradict this parameter in other templates. - The list of supported network traffics (network roles) is available in the - ``openstack.yaml`` file on the Fuel Master node. If you have Fuel plugins - installed in your environment, you can also map network traffic related - to the plugin. For the list of types of network traffic related to the - plugin, see the corresponding ``network_roles.yaml`` file in the plugin - repository. - The ``roles`` section cannot be empty. If you do not want to specify any - mappings, you must create one fake mapping. For example: - - **Example:** - - :: - - roles: - fake/ext: br-pub-ext - - -**Example** - -:: - - network_scheme: - storage: