diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/arno/enable_docu_gen.rst | 37 | ||||
-rw-r--r-- | docs/arno/index.rst | 2 | ||||
-rw-r--r-- | docs/arno/opnfv-jjb-usage.rst | 5 | ||||
-rw-r--r-- | docs/arno/opnfvdocs_info.rst | 12 | ||||
-rw-r--r-- | docs/arno/other_options_for_docu_gen.rst | 29 | ||||
-rw-r--r-- | docs/etc/conf.py | 35 | ||||
-rw-r--r-- | docs/etc/opnfv-logo.png | bin | 2829 -> 0 bytes | |||
-rw-r--r-- | docs/opnfvsecguide/compute.rst | 4 | ||||
-rw-r--r-- | docs/opnfvsecguide/compute/trust.rst | 8 | ||||
-rw-r--r-- | docs/opnfvsecguide/contribution.rst | 14 | ||||
-rw-r--r-- | docs/opnfvsecguide/getting_started.rst | 12 | ||||
-rw-r--r-- | docs/opnfvsecguide/introduction.rst | 9 | ||||
-rw-r--r-- | docs/opnfvsecguide/introduction/background.rst | 37 | ||||
-rw-r--r-- | docs/opnfvsecguide/network.rst | 2 | ||||
-rw-r--r-- | docs/opnfvsecguide/network/neutron.rst | 2 | ||||
-rw-r--r-- | docs/platformoverview/index.rst | 11 | ||||
-rw-r--r-- | docs/platformoverview/platformoverview.rst | 172 | ||||
-rw-r--r-- | docs/templates/build-instructions.rst | 21 | ||||
-rw-r--r-- | docs/templates/index.rst | 2 | ||||
-rw-r--r-- | docs/templates/installation-instructions.rst | 37 | ||||
-rw-r--r-- | docs/templates/release-notes.rst | 10 | ||||
-rw-r--r-- | docs/userguide/index.rst | 3 |
22 files changed, 350 insertions, 114 deletions
diff --git a/docs/arno/enable_docu_gen.rst b/docs/arno/enable_docu_gen.rst index 6f02cdacd..0340801d3 100644 --- a/docs/arno/enable_docu_gen.rst +++ b/docs/arno/enable_docu_gen.rst @@ -61,7 +61,8 @@ Enter the project settings:: **Create the verify & build scripts** -The scripts are the same for most projects and if you need customizations copy them under your project in releng/jjb/<project>/:: +The scripts are the same for most projects and if you need customizations copy them +under your project in releng/jjb/<project>/:: cp releng/jjb/opnfvdocs/build-docu.sh releng/jjb/<your-project>/ @@ -265,8 +266,11 @@ Variant 2 - custom "node: master" is important here as all documentations are built on Jenkins master node for now. -Please reffer to the releng repository for the correct indentation as JJB is very picky with those and also for the rest of the code that is missing in the example code and replaced by "...". -Also you must have your documentation under docs/ in the repository or gsutil will fail to copy them; for customizations you might need to addapt build-docu.sh as we did for genesis project as different documents need to go into different places. +Please reffer to the releng repository for the correct indentation as JJB is very picky +with those and also for the rest of the code that is missing in the example code and replaced by "...". +Also you must have your documentation under docs/ in the repository or gsutil will fail to copy them; +for customizations you might need to addapt build-docu.sh as we did for genesis project +as different documents need to go into different places. Stage files example:: @@ -302,9 +306,16 @@ http://artifacts.opnfv.org/ **Scrape content from html artifacts on wiki** -This section describes how the html build artifacts can be made visible on Wiki using he scrape method. DokuWiki speeds up browsing through the wiki by caching parsed files1). If a currently cached version of a document exists, this cached copy is delivered instead of parsing the data again. On editing and previewing no cache is used. +This section describes how the html build artifacts can be made visible on Wiki using he scrape method. +DokuWiki speeds up browsing through the wiki by caching parsed files1). +If a currently cached version of a document exists, this cached copy is delivered +instead of parsing the data again. On editing and previewing no cache is used. -To prevent a page from ever being cached, use the NOCACHE tag anywhere in the document. This is useful if the page contains dynamic content, e.g. PHP code that pulls in outside information, where the caching would prevent the most recent information from being displayed. Same applies if documentation artifacts are rebuilt the cached version is shown if the NOCACHE tag is not used. +To prevent a page from ever being cached, use the NOCACHE tag anywhere in the document. +This is useful if the page contains dynamic content, e.g. PHP code that pulls in outside information, +where the caching would prevent the most recent information from being displayed. +Same applies if documentation artifacts are rebuilt the cached version is shown +if the NOCACHE tag is not used. https://www.dokuwiki.org/caching @@ -317,15 +328,22 @@ example:: {{scrape>http://artifacts.opnfv.org/opnfvdocs/docs/enable_docu_gen.html}} -Please try to write documentation as accurate and clear as possible as once reviewed and merged it will be automatically built and displayed on Wiki and everyone would apreciate a good written/nice looking guide. +Please try to write documentation as accurate and clear as possible as once reviewed and +merged it will be automatically built and displayed on Wiki and +everyone would apreciate a good written/nice looking guide. -If you want to see on wiki what code is scraped from the built artifacts click "Show pagesource" in the right (it will appear if you hover over the magnifier icon); this way you know what is written straight on wiki and what is embedded with "scrape". By knowing these details you will be able to prevent damages by manually updating wiki. +If you want to see on wiki what code is scraped from the built artifacts click "Show pagesource" in the right +(it will appear if you hover over the magnifier icon); +this way you know what is written straight on wiki and what is embedded with "scrape". +By knowing these details you will be able to prevent damages by manually updating wiki. **Wiki update - how it works** Edit Wiki page https://wiki.opnfv.org/<page> and look for {{scrape>http://artifacts.opnfv.org/<project>/<folder>/<doc-file>.html}} -Click "Preview" and see if the change you submitted to Git is present; add a short description in "Edit summary" field, then click "Save" to update the page. This extra step is needed as Wiki does not auto update content for now. +Click "Preview" and see if the change you submitted to Git is present; +add a short description in "Edit summary" field, then click "Save" to update the page. +This extra step is needed as Wiki does not auto update content for now. **How to track documentation** @@ -356,7 +374,8 @@ The image will be shown in both .html and .pdf resulting artifacts. NOTE: ------ -In order to generate html & pdf documentation the needed packages are rst2pdf & python-docutils if the Jenkins is CentOS/RHEL; many variants have been tested but this is the cleanest solution found. +In order to generate html & pdf documentation the needed packages are rst2pdf & python-docutils +if the Jenkins is CentOS/RHEL; many variants have been tested but this is the cleanest solution found. For html generation it also supports css styles if needed. diff --git a/docs/arno/index.rst b/docs/arno/index.rst index 994a20d51..f4bd59bba 100644 --- a/docs/arno/index.rst +++ b/docs/arno/index.rst @@ -3,7 +3,7 @@ You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. -.. image:: ../etc/opnfv-logo.png +.. image:: opnfv-logo.png :height: 40 :width: 200 :alt: OPNFV diff --git a/docs/arno/opnfv-jjb-usage.rst b/docs/arno/opnfv-jjb-usage.rst index aabfda7ae..6b3bc93ce 100644 --- a/docs/arno/opnfv-jjb-usage.rst +++ b/docs/arno/opnfv-jjb-usage.rst @@ -32,7 +32,10 @@ Job Types * Trigger: **remerge** -The verify and merge jobs are retriggerable in Gerrit by simply leaving a comment with one of the keywords listed above. This is useful in case you need to re-run one of those jobs in case if build issues or something changed with the environment. +The verify and merge jobs are retriggerable in Gerrit by simply leaving a comment +with one of the keywords listed above. +This is useful in case you need to re-run one of those jobs in case if build issues or +something changed with the environment. You can add below persons as reviewers to your patch in order to get it reviewed and submitted. diff --git a/docs/arno/opnfvdocs_info.rst b/docs/arno/opnfvdocs_info.rst index 1c78eeaf0..30bd4f035 100644 --- a/docs/arno/opnfvdocs_info.rst +++ b/docs/arno/opnfvdocs_info.rst @@ -22,7 +22,8 @@ Project description: Scope: ------- -- Set up a structure, and a template, for document development with source control (same as source code). Leveraging upstream documentation structure and tools. +- Set up a structure, and a template, for document development with source control + (same as source code). Leveraging upstream documentation structure and tools. - Following as close as possible the same contribution process & tools as our source code - Structure OPNFV documentation logically - Develop initial set of release documents: @@ -33,7 +34,8 @@ Scope: - API reference (if there is content in release 1) - Interface specification (if there is content in release 1) -- Provide language options for documentation where applicable: In first release English only, Wiki (via HTML scraping from Gerrit), and PDF. +- Provide language options for documentation where applicable: In first release English only, + Wiki (via HTML scraping from Gerrit), and PDF. - Provide tooling and processes for OPNFV projects to implement and follow for consistency Dependencies: @@ -41,7 +43,8 @@ Dependencies: - All OPNFV projects participating in a release. - Upstream project documentation to be referenced -- Where there are external fora or standard development organization dependencies, list informative and normative references & specifications. +- Where there are external fora or standard development organization dependencies, + list informative and normative references & specifications. Committers and Contributors: @@ -69,7 +72,8 @@ Committers and Contributors: Description of roles in the documentation project: - Committers (Editors): has overall responsibility of document structure, editing, style and toolchains -- opnfvdocs contributors: individual section will have contributors who are domain experts in those areas, other contributors may simply help out working on the documentation and tools as needed. +- opnfvdocs contributors: individual section will have contributors who are domain experts in those areas, + other contributors may simply help out working on the documentation and tools as needed. - other projects: Committers will be responsible for maintaining documentation artifacts in project repositories. Planned deliverables diff --git a/docs/arno/other_options_for_docu_gen.rst b/docs/arno/other_options_for_docu_gen.rst index ea6ad2598..596f39429 100644 --- a/docs/arno/other_options_for_docu_gen.rst +++ b/docs/arno/other_options_for_docu_gen.rst @@ -14,31 +14,39 @@ Description: This was the first discovered method * Pros: - standard tools: doxygen, html publisher, LaTeX suite - - doxygen plugin available in Jenkins, you just need to install it; html publisher plugin available in Jenkins, you just need to install it + - doxygen plugin available in Jenkins, you just need to install it; + html publisher plugin available in Jenkins, you just need to install it - destination files are generated fast - standard reStructuredText or Markdown * Cons: - - takes some time to customize the output in matters of template, requires custom html header/footer + - takes some time to customize the output in matters of template, + requires custom html header/footer - latex suite is quite substantial in amount of packages and consumed space (around 1.2 GB) * Tested: roughly, functional tests only **Maven & clouddocs-maven-plugin (actually used to generate openstack-manuals)** -Description: It represents the standard tool to generate Openstack documentation manuals, uses maven, maven plugins, clouddocs-maven-plugins; location of finally generated files is the object of a small Bash script that will reside as Post-actions +Description: It represents the standard tool to generate Openstack documentation manuals, +uses maven, maven plugins, clouddocs-maven-plugins; +location of finally generated files is the object of a small Bash script +that will reside as Post-actions * Input files: .xml * Output: .html & .pdf * Pros: - quite easy for initial setup - - uses openstack documentation generation flows as for openstack-manuals (clouddocs-maven-plugin), maven installs all you need generate the documentation + - uses openstack documentation generation flows as for + openstack-manuals (clouddocs-maven-plugin), + maven installs all you need generate the documentation * Cons: - - could be tricky to generate a custom layout, knowledge about Maven plugins required, .pom editing + - could be tricky to generate a custom layout, + knowledge about Maven plugins required, .pom editing - dependent of multiple maven plugins - input files are .xml and xml editing knowledge is required @@ -46,7 +54,10 @@ Description: It represents the standard tool to generate Openstack documentation **Sphinx & LaTeX suite** -Description: The easiest to install, the cleanest in matter of folder & files structure, uses standard tools available in repositories; location of finally generated files is the object of a small Bash script that will reside as Post-actions +Description: The easiest to install, the cleanest in matter of folder & files structure, +uses standard tools available in repositories; +location of finally generated files is the object of a small Bash script that will +reside as Post-actions * Input files: .rst as default * Output: .html & .pdf @@ -55,9 +66,11 @@ Description: The easiest to install, the cleanest in matter of folder & files st - standard tools: Python Sphinx, LaTeX suite - destination files are generated fast - standard reStructuredText as default; other inputs can be configured - - Sphinx's installation is very clean in matters of folder structure; the cleanest from all tested variants + - Sphinx's installation is very clean in matters of folder structure; + the cleanest from all tested variants - latex suite is also easy to install via yum/apt and available in general repos - - everyone is migration from other tools to Spinx lately; it provides more control and better looking documentation + - everyone is migration from other tools to Spinx lately; + it provides more control and better looking documentation - can be used also for source-code documentation, specially if you use Python * Cons: diff --git a/docs/etc/conf.py b/docs/etc/conf.py deleted file mode 100644 index cff2d96da..000000000 --- a/docs/etc/conf.py +++ /dev/null @@ -1,35 +0,0 @@ -import datetime -import sys -import os - -try: - __import__('imp').find_module('sphinx.ext.numfig') - extensions = ['sphinx.ext.numfig'] -except ImportError: - # 'pip install sphinx_numfig' - extensions = ['sphinx_numfig'] - -# numfig: -number_figures = True -figure_caption_prefix = "Fig." - -source_suffix = '.rst' -master_doc = 'index' -pygments_style = 'sphinx' -html_use_index = False -html_theme = 'sphinx_rtd_theme' - -pdf_documents = [('index', u'OPNFV', u'OPNFV Project', u'OPNFV')] -pdf_fit_mode = "shrink" -pdf_stylesheets = ['sphinx','kerning','a4'] -#latex_domain_indices = False -#latex_use_modindex = False - -latex_elements = { - 'printindex': '', -} - -project = u'OPNFV: Template documentation config' -copyright = u'%s, OPNFV' % datetime.date.today().year -version = u'1.0.0' -release = u'1.0.0' diff --git a/docs/etc/opnfv-logo.png b/docs/etc/opnfv-logo.png Binary files differdeleted file mode 100644 index 1519503eb..000000000 --- a/docs/etc/opnfv-logo.png +++ /dev/null diff --git a/docs/opnfvsecguide/compute.rst b/docs/opnfvsecguide/compute.rst index ee8d782a7..d6c1a0159 100644 --- a/docs/opnfvsecguide/compute.rst +++ b/docs/opnfvsecguide/compute.rst @@ -4,5 +4,5 @@ Compute Security .. toctree:: :maxdepth: 2 - compute/dacmaccontrols - compute/trust
\ No newline at end of file + compute/dacmaccontrols.rst + compute/trust.rst diff --git a/docs/opnfvsecguide/compute/trust.rst b/docs/opnfvsecguide/compute/trust.rst index 50ee2a10e..2c5cc63a6 100644 --- a/docs/opnfvsecguide/compute/trust.rst +++ b/docs/opnfvsecguide/compute/trust.rst @@ -1,6 +1,10 @@ Trusted Compute --------------- -Compute security relates to the compute nodes in an OPNFV deployment. Compute nodes host various componants such as the hypervisor itself KVM-QEMU, and its serving eco-system, such as Nova (which interacts with the hypervisor using libvirt driver). +Compute security relates to the compute nodes in an OPNFV deployment. +Compute nodes host various componants such as the hypervisor itself KVM-QEMU, +and its serving eco-system, such as Nova (which interacts with the hypervisor using libvirt driver). -We also cover other aspects of what is considered compute security, such as trusted boot / pools, although of course, these can be extended to other actors such as neutron etworking nodes.
\ No newline at end of file +We also cover other aspects of what is considered compute security, +such as trusted boot / pools, although of course, +these can be extended to other actors such as neutron etworking nodes. diff --git a/docs/opnfvsecguide/contribution.rst b/docs/opnfvsecguide/contribution.rst index 954c5785e..683aa2d14 100644 --- a/docs/opnfvsecguide/contribution.rst +++ b/docs/opnfvsecguide/contribution.rst @@ -1,19 +1,22 @@ How to Contribute ----------------- -Anyone is welcome to make additions, raise bugs, and fix issues within this Documentation. To do so, you will however need to first get an enviroment set up. +Anyone is welcome to make additions, raise bugs, and fix issues within this Documentation. +To do so, you will however need to first get an enviroment set up. Development Environment ####################### -All project data such as formatting guidelines, and upstream mapping is documented via sphinx which uses reStructuredText +All project data such as formatting guidelines, and upstream mapping is documented via sphinx +which uses reStructuredText -It is recommended that you use a python virtualenv to keep things clean and contained. +It is recommended that you use a python virtualenv to keep things clean and contained. VirtualEnv ********** -Use of a virtual environment is recommended, as not only is it a quick easy form of getting the needed modules in place, it isolates the module versions to a project. +Use of a virtual environment is recommended, as not only is it a quick easy form of +getting the needed modules in place, it isolates the module versions to a project. From within your inspector directory, set up a new virtualenv:: @@ -38,4 +41,5 @@ To compile changes: make html -From here you can run a basic python web server or just navigate to the file:///<repo>/opnfv-security-guide/build/html/index.html in your browser
\ No newline at end of file +From here you can run a basic python web server or just navigate to the +file:///<repo>/opnfv-security-guide/build/html/index.html in your browser diff --git a/docs/opnfvsecguide/getting_started.rst b/docs/opnfvsecguide/getting_started.rst index cfa8b2f6b..e09507dd2 100644 --- a/docs/opnfvsecguide/getting_started.rst +++ b/docs/opnfvsecguide/getting_started.rst @@ -4,12 +4,14 @@ Getting Started Development Environment ####################### -All project data such as formatting guidelines, and upstream mapping is documented via sphinx which uses reStructuredText +All project data such as formatting guidelines, and upstream mapping is documented via sphinx +which uses reStructuredText VirtualEnv ********** -Use of a virtual environment is recommended, as not only is it a quick easy form of getting the needed modules in place, it isolates the module versions to a project. +Use of a virtual environment is recommended, as not only is it a quick easy form of +getting the needed modules in place, it isolates the module versions to a project. From within your inspector directory, set up a new virtualenv:: @@ -26,7 +28,8 @@ Install requirements:: Sphinx Basics ************* -To get started with sphinx, visit the main tutorial which will provide a primer `http://sphinx-doc.org/tutorial.html` +To get started with sphinx, visit the main tutorial which will provide a primer +`http://sphinx-doc.org/tutorial.html` Hack your changes into opnfv-security-guide/source @@ -34,4 +37,5 @@ To compile changes: make html -From here you can run a basic python web server or just navigate to the file:///<repo>/opnfv-security-guide/build/html/index.html in your browser
\ No newline at end of file +From here you can run a basic python web server or just navigate to the +file:///<repo>/opnfv-security-guide/build/html/index.html in your browser diff --git a/docs/opnfvsecguide/introduction.rst b/docs/opnfvsecguide/introduction.rst index 224b498a9..ad8083197 100644 --- a/docs/opnfvsecguide/introduction.rst +++ b/docs/opnfvsecguide/introduction.rst @@ -1,12 +1,15 @@ Introduction --------------- -The OPNFV Security Guide is the collaborative work of many individuals, involved in both the OPNFV Security Group and the wider OPNFV community. +The OPNFV Security Guide is the collaborative work of many individuals, +involved in both the OPNFV Security Group and the wider OPNFV community. -The purpose of this guide is to provide the best practice security guidelines for deploying the OPNFV platfornm. It is a living document that is updated as new changes are merged into it's repository. +The purpose of this guide is to provide the best practice security guidelines for +deploying the OPNFV platfornm. It is a living document that is updated as +new changes are merged into it's repository. .. toctree:: :maxdepth: 2 introduction/background - introduction/acknowledgements
\ No newline at end of file + introduction/acknowledgements diff --git a/docs/opnfvsecguide/introduction/background.rst b/docs/opnfvsecguide/introduction/background.rst index 7766b36fa..bd7e44d01 100644 --- a/docs/opnfvsecguide/introduction/background.rst +++ b/docs/opnfvsecguide/introduction/background.rst @@ -1,19 +1,38 @@ Background ---------- -Pre-virtualization security protection was largely centered on the network. Malicious attacks from hostile machines, would seek to exploit network based operating systems and applications, with the goal of compromising their target node. - -Physical security had always been a much simpler business, with most focus on the secure access of the data center hardware. -In-turn security was built up in layers (defense in depth) where machines would be daisy chained with network cables via security appliances to provide controlled segmentation and isolation. This form of security was built upon the principle of an ‘air gap’ being present, whereby machines were separate physical units, joined largely by the network stack. - -With the advent of virtualization (namely the hypervisor), new attack vectors have surfaced as the ‘air-gap’ is no longer key design aspect for security. Further to this elements orchestation nodes and network controllers lead to an even wider attack surface: +Pre-virtualization security protection was largely centered on the network. +Malicious attacks from hostile machines, would seek to exploit network based +operating systems and applications, with the goal of compromising their +target node. + +Physical security had always been a much simpler business, with most focus on +the secure access of the data center hardware. +In-turn security was built up in layers (defense in depth) where machines +would be +daisy chained with network cables via security appliances to provide +controlled segmentation and isolation. +This form of security was built upon the principle of an 'air gap' +being present, +whereby machines were separate physical units, joined largely by the +network stack. + +With the advent of virtualization (namely the hypervisor), new attack +vectors have +surfaced as the 'air-gap' is no longer key design aspect for security. +Further to this elements orchestation nodes and network controllers +lead to an even wider attack surface: * Guests breaking isolation of the hypervisor. * Unauthorized access and control of supporting orchestration nodes. -* Unauthorized access and control of supporting overlay network control systems. +* Unauthorized access and control of supporting overlay network control systems. -The hypervisor and the overlay network have now become the ‘Achilles heel’ whereby all tenant data isolation is enforced within the hypervisor and its abstraction of hardware and the virtualized overlay network. +The hypervisor and the overlay network have now become the 'Achilles heel' +whereby all tenant data isolation is enforced within the hypervisor and its +abstraction +of hardware and the virtualized overlay network. -This guide has been formulated, in order to assist users of the OPNFV platform in securing an Telco NFV / SDN environment.
\ No newline at end of file +This guide has been formulated, in order to assist users of the OPNFV platform +in securing an Telco NFV / SDN environment. diff --git a/docs/opnfvsecguide/network.rst b/docs/opnfvsecguide/network.rst index 614e3c333..b1744796c 100644 --- a/docs/opnfvsecguide/network.rst +++ b/docs/opnfvsecguide/network.rst @@ -5,4 +5,4 @@ Network Security .. toctree:: :maxdepth: 2 - network/neutron
\ No newline at end of file + network/neutron diff --git a/docs/opnfvsecguide/network/neutron.rst b/docs/opnfvsecguide/network/neutron.rst index 6eba4e3e1..e7ca06075 100644 --- a/docs/opnfvsecguide/network/neutron.rst +++ b/docs/opnfvsecguide/network/neutron.rst @@ -1,2 +1,2 @@ Neutron Security -----------------
\ No newline at end of file +---------------- diff --git a/docs/platformoverview/index.rst b/docs/platformoverview/index.rst index 3a62c69f3..44a48e573 100644 --- a/docs/platformoverview/index.rst +++ b/docs/platformoverview/index.rst @@ -3,18 +3,17 @@ You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. -Welcome to OPNFV Platform Overview document -================================================ +OPNFV Platform Overview document +================================ -This document seeks to inform operators how to configure the OPNFV Platform and its components to enable platform features provided in the Brahmaputra release. Contents: .. toctree:: - :maxdepth: 2 + :maxdepth: 4 + + platformoverview.rst - configguide.rst - ../../sdnvpn/docs/platformoverview/platformoverview.rst Indices and tables diff --git a/docs/platformoverview/platformoverview.rst b/docs/platformoverview/platformoverview.rst index 260658050..b590f06f7 100644 --- a/docs/platformoverview/platformoverview.rst +++ b/docs/platformoverview/platformoverview.rst @@ -1,4 +1,174 @@ +------------------------ Introduction +------------------------ + +The OPNFV project provides different kinds of output to its users: + +1. **Target Software Platform** + + This provides the software which will run as NFVI and VIM in an actual NFV deployment + It is an integrated solution of several other open source projects, e.g. OpenStack, + Linux, ODL. + +2. **Deployment Tools** + + So called installers help the user deploy target software on his hardware. + OPNFV provides multiple options to do this. + +3. **Test Cases and Framework** + + The target software platform can be verified and evaluated using these testcases. + Their goal is to show that the deployed platform is usable to run VNFs. + +4. **Documentation** + + OPNFV provides the necessary documents describing target software platform, deployment + tools, tests, etc. in their architecture and usage. + +5. **Requirements** + + OPNFV community works on requirements of open source projects used in OPNFV to + make these projects better suitable for NFV telco carrier use cases. + These requirements are described in requirement documents and also forwarded + to the "upstream" projects in the format required by these projects. + +6. **Community Labs** + + OPNFV creates lab environments not only for development of OPNFV, but also to help + build the NFV ecosystem. OPNFV labs follow a defined structure and configuration. + Some of the labs have their dedicated tasks in the development environment, some of + the labs will be provided for open use. + +**OPNFV Releases** + +OPNFV bundles the target software, installers, documentation, test cases and lab +description to releases and provides documentation describing the scope and features +provided. + +This overview document introduces these components on a high level and points you to more +detailed documentation. +It describes the OPNFV Brahmaputra release. + +OPNFV Requirement documents typically describe requirements that will be implemented in +later releases of OPNFV. Thus they are not part of a release package. + +Also community labs are independent of releases. Only the lab description is included in +the release and describes the requirements of a lab to successfully run Brahmaputra +deployments. + + +------------------------ +Target software platform +------------------------ + +Software architecture +===================== + +This section will provide information which upstream projects, versions and components are +integrated in the Brahmaputra release + +OpenStack +--------- + +OPNFV uses OpenStack as cloud management system. +Brahmaputra is based on OpenStack Liberty Release. It comprises the following sub-projects +and modules: + +* Nova +* Neutron +* Cinder +* Ceilometer +* etc. + +Operating System +---------------- + +OPNFV uses Linux on all target machines. Depending on the installers, different +distributions are supported. + +Editors note: +Add a table showing which installer supports which operating system for controller nodes and for compute nodes. + + +SDN Controllers --------------- -The OPNFV Platform Overview needs work... +OPNFV Brahmaputra release supports three different SDN controllers: + +* OpenDaylight +* ONOS +* OpenContrail + +Depending on the SDN controller you are using, the featureset will vary. + +OpenDaylight +++++++++++++ + +Editor's note: +We need a high level paragraph here and a description of how we use ODL. + +ONOS +++++ + +Editors note: +We need a high level paragraph here and a description of how we use ONOS, especially the +relation of ONOS and ONOSFW project's integration and features. + +OpenContrail +++++++++++++ + +Editors note: +We need a high level paragraph here and a description of how we use OpenContrail, including +its vRouter capabilities. + +Data Plane +---------- + +Other Components +---------------- + +Deployment Architecture +======================= + +Editors note: +Short description that we use a typical configuration with 3 controller nodes running +OpenStack, SDN, etc. and a minimum of 2 compute nodes for deployment of the VNFs. +Also mention that we use a "jumphost" for the initial bring-up, and the deployment of the +test framework. + +In a second level of detail, describe how software is distributed over the 3 controller +nodes, compute nodes and other hardware. + +Dynamic View +============ + +Editors note: we might skip this section completely for Brahmaputra. + +Or we provide rather short statements. In later versions, we have to describe which +software is involved in which way during: + +* VNF Life Cycle (onboarding, instantiate, scaling): we can reference to other documents +* Hardware Life Cycle (mainly how to add compute nodes, but also other cases) +* ... + +---------------- +Deployment Tools +---------------- + +Brahmaputra provides 4 different installers + +Editors note: +A table to summarize main characteristics would be nice + +We also need to list restrictions or dependencies like which installer can install which SDN...... + +----------------------- +Testcases and Framework +----------------------- + +Editors note: +Just a high level description about the different types of tests and the role of yardstick as central framework. + + + + diff --git a/docs/templates/build-instructions.rst b/docs/templates/build-instructions.rst index 029eddead..3c7a9b8f1 100644 --- a/docs/templates/build-instructions.rst +++ b/docs/templates/build-instructions.rst @@ -14,7 +14,9 @@ License ======= <WORK'S NAME> (c) by <AUTHOR'S NAME> -<WORK'S NAME> is licensed under a Creative Commons Attribution 4.0 International License. You should have received a copy of the license along with this. If not, see <http://creativecommons.org/licenses/by/4.0/>. +<WORK'S NAME> is licensed under a Creative Commons Attribution 4.0 International License. +You should have received a copy of the license along with this. +If not, see <http://creativecommons.org/licenses/by/4.0/>. **Contents** @@ -54,9 +56,12 @@ License <EXAMPLE>: -This document describes build system used to build Fuel@OPNFV, required dependencies and minimum requirements on the host to be used for the buildsystem. +This document describes build system used to build Fuel@OPNFV, +required dependencies and minimum requirements on the host to be used for the buildsystem. -The Fuel build system is desigened around Docker containers such that dependencies outside of the build system can be kept to a minimum. It also shields the host from any potential dangerous operations performed by the build system. +The Fuel build system is desigened around Docker containers such that dependencies +outside of the build system can be kept to a minimum. +It also shields the host from any potential dangerous operations performed by the build system. The audience of this document is assumed to have good knowledge in network and Unix/Linux administration. @@ -81,7 +86,8 @@ The build host should run Ubuntu 14.04 operating system. On the host, the following packages must be installed: -- docker - see https://docs.docker.com/installation/ubuntulinux/ for installation notes for Ubuntu 14.04. Note: only use the Ubuntu stock distro of Docker (docker.io) +- docker - see https://docs.docker.com/installation/ubuntulinux/ for installation notes for Ubuntu 14.04. + Note: only use the Ubuntu stock distro of Docker (docker.io) - git (simply available through sudo apt-get install git) @@ -110,7 +116,9 @@ Then restart docker: 3.3.2 Setting up OPNFV Gerrit in order to being able to clone the code ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Start setting up OPNFV gerrit by creating a SSH key (unless you don't already have one), create one with ssh-keygen + +- Start setting up OPNFV gerrit by creating a SSH key (unless you don't already have one), + create one with ssh-keygen - Add your generated public key in OPNFV Gerrit <https://gerrit.opnfv.org/> (this requires a linuxfoundation account, create one if you do not already have one) @@ -189,7 +197,8 @@ For more info type <fuel/ci/build.sh -h>. The artifacts produced are: -- <OPNFV_XXXX.iso> - Which represents the bootable Fuel@OPNFV image, XXXX is replaced with the build identity provided to the build system +- <OPNFV_XXXX.iso> - Which represents the bootable Fuel@OPNFV image, + XXXX is replaced with the build identity provided to the build system - <OPNFV_XXXX.iso.txt> - Which holds version metadata. diff --git a/docs/templates/index.rst b/docs/templates/index.rst index 603615ccb..5fde4e39e 100644 --- a/docs/templates/index.rst +++ b/docs/templates/index.rst @@ -3,7 +3,7 @@ You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. -.. image:: ../etc/opnfv-logo.png +.. image:: opnfv-logo.png :height: 40 :width: 200 :alt: OPNFV diff --git a/docs/templates/installation-instructions.rst b/docs/templates/installation-instructions.rst index 58972c1f1..8c46fe9ba 100644 --- a/docs/templates/installation-instructions.rst +++ b/docs/templates/installation-instructions.rst @@ -19,7 +19,9 @@ License ======= <WORK'S NAME> (c) by <AUTHOR'S NAME> -<WORK'S NAME> is licensed under a Creative Commons Attribution 4.0 International License. You should have received a copy of the license along with this. If not, see <http://creativecommons.org/licenses/by/4.0/>. +<WORK'S NAME> is licensed under a Creative Commons Attribution 4.0 International License. +You should have received a copy of the license along with this. +If not, see <http://creativecommons.org/licenses/by/4.0/>. **Contents** @@ -66,10 +68,13 @@ License <EXAMPLE>: -This document describes the supported software and hardware configurations for the Fuel OPNFV reference platform as well as providing guidelines on how to install and +This document describes the supported software and hardware configurations for the +Fuel OPNFV reference platform as well as providing guidelines on how to install and configure such reference system. -Although the available installation options gives a high degree of freedom in how the system is set-up, with what architecture, services and features, etc., not nearly all of those permutations provides a OPNFV compliant reference architecture. Following the guidelines in this document ensures +Although the available installation options gives a high degree of freedom in how the system is set-up, +with what architecture, services and features, etc., not nearly all of those permutations provides +a OPNFV compliant reference architecture. Following the guidelines in this document ensures a result that is OPNFV compliant. The audience of this document is assumed to have good knowledge in network and Unix/Linux administration. @@ -82,7 +87,8 @@ The audience of this document is assumed to have good knowledge in network and U Before starting the installation of Fuel@OPNFV, some planning must preceed. -First of all, the Fuel@OPNFV .iso image needs to be retrieved, the Latest stable Arno release of Fuel@OPNFV can be found here: <www.opnfv.org/abc/def> +First of all, the Fuel@OPNFV .iso image needs to be retrieved, +the Latest stable Arno release of Fuel@OPNFV can be found here: <www.opnfv.org/abc/def> Alternatively, you may build the .iso from source by cloning the opnfv/genesis git repository: <git clone https://<linux foundation uid>@gerrit.opnf.org/gerrit/genesis> @@ -148,9 +154,15 @@ Following minimum hardware requirements must be met for installation of Fuel@OPN <EXAMPLE>: -The switching infrastructure provides connectivity for the OPNFV infra-structure operations as well as for the tenant networks (East/West) and provider connectivity (North/South bound connectivity). The switching connectivity can (but does not need to) be fully redundant, in case it and comprises a redundant 10GE switch pair for “Traffic/Payload/SAN” purposes as well as a 1GE switch pair for “infrastructure control-, management and administration” +The switching infrastructure provides connectivity for the OPNFV infra-structure operations as well as +for the tenant networks (East/West) and provider connectivity (North/South bound connectivity). +The switching connectivity can (but does not need to) be fully redundant, +in case it and comprises a redundant 10GE switch pair for "Traffic/Payload/SAN" purposes as well as +a 1GE switch pair for "infrastructure control-, management and administration" -The switches are **not** automatically configured from the OPNFV reference platform. All the networks involved in the OPNFV infra-structure as well as the provider networks and the private tenant VLANs needs to be manually configured. +The switches are **not** automatically configured from the OPNFV reference platform. +All the networks involved in the OPNFV infra-structure as well as the provider networks +and the private tenant VLANs needs to be manually configured. This following sections guides through required black-box switch configurations. @@ -166,7 +178,8 @@ This following sections guides through required black-box switch configurations. <EXAMPLE>: -This section describes the installation of the Fuel@OPNFV installation server (Fuel master) as well as the deployment of the full OPNFV reference platform stack across a server cluster. +This section describes the installation of the Fuel@OPNFV installation server (Fuel master) +as well as the deployment of the full OPNFV reference platform stack across a server cluster. Etc. 6.1 Install Fuel master @@ -187,11 +200,12 @@ Etc. <EXAMPLE>: -Now that the OPNFV environment has been created, and before the post installation configurations is started, perform a system health check from the Fuel GUI: +Now that the OPNFV environment has been created, and before the post installation configurations is started, +perform a system health check from the Fuel GUI: -- Select the “Health check” TAB. +- Select the "Health check" TAB. - Select all test-cases -- And click “Run tests” +- And click "Run tests" All test cases except the following should pass: @@ -200,7 +214,8 @@ All test cases except the following should pass: <DESCRIBE ANY POST INSTALLATION ACTIONS/CONFIGURATIONS NEEDED> <EXAMPLE>: -After the OPNFV deployment is completed, the following manual changes needs to be performed in order for the system to work according OPNFV standards. +After the OPNFV deployment is completed, the following manual changes needs to be performed in order +for the system to work according OPNFV standards. **Change host OS password:** Change the Host OS password by...... diff --git a/docs/templates/release-notes.rst b/docs/templates/release-notes.rst index 1c08d092f..6941f181f 100644 --- a/docs/templates/release-notes.rst +++ b/docs/templates/release-notes.rst @@ -19,7 +19,9 @@ License ======= <WORK'S NAME> (c) by <AUTHOR'S NAME> -<WORK'S NAME> is licensed under a Creative Commons Attribution 4.0 International License. You should have received a copy of the license along with this. If not, see <http://creativecommons.org/licenses/by/4.0/>. +<WORK'S NAME> is licensed under a Creative Commons Attribution 4.0 International License. +You should have received a copy of the license along with this. If not, +see <http://creativecommons.org/licenses/by/4.0/>. **Contents** @@ -62,7 +64,8 @@ License <EXAMPLE>: -**Attention:** Please be aware that since LSV3 a pre-deploy script must be ran on the Fuel master – see the OPNFV@Fuel SW installation instructions +**Attention:** Please be aware that since LSV3 a pre-deploy script must be ran on the Fuel master - +see the OPNFV@Fuel SW installation instructions 3 Summary =========== @@ -71,7 +74,8 @@ License <EXAMPLE>: -Arno Fuel@OPNFV is based the OpenStack Fuel upstream project version 6.0.1, but adds OPNFV unique components such as OpenDaylight version: Helium as well as other OPNFV unique configurations...... +Arno Fuel@OPNFV is based the OpenStack Fuel upstream project version 6.0.1, +but adds OPNFV unique components such as OpenDaylight version: Helium as well as other OPNFV unique configurations...... 4 Release Data ================ diff --git a/docs/userguide/index.rst b/docs/userguide/index.rst index 581a74b33..eb3512075 100644 --- a/docs/userguide/index.rst +++ b/docs/userguide/index.rst @@ -6,7 +6,8 @@ Welcome to OPNFV User Guide ================================================ -This guide seeks to inform operators how to use the OPNFV Platform and its components to enable platform features provided in the Brahmaputra release. +This guide seeks to inform operators how to use the OPNFV Platform and its components to enable platform +features provided in the Brahmaputra release. Contents: |