Example Documentation table of contents¶

Contents:

1. OPNFV Build instructions for - < Component denomination >¶

1.1. Abstract¶

This document describes how to build <Component>, build system dependencies and required system resources.

1.2. 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/>.

Contents

1 Version history

2 Introduction

3 Requirements

4 Building

5 Artifacts

1.3. 1 Version history¶

Date	Ver.	Author	Comment
2015-04-14	0.1.0	Jonas Bjurel	First draft
	0.1.1
	1.0

1.4. 2 Introduction¶

<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.

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.

1.5. 3 Requirements¶

1.5.1. 3.1 Minimum Hardware Requirements¶

<EXAMPLE>:

An x86_64 host (Bare-metal or VM) with Ubuntu 14.04 LTS installed
~30 GB available disc
4 GB RAM

1.5.2. 3.2 Minimum Software Requirements¶

<EXAMPLE>: 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)
git (simply available through sudo apt-get install git)
make (simply available through sudo apt-get install make)
curl (simply available through sudo apt-get install curl)

1.5.3. 3.3 Preparations¶

<EXAMPLE>:

1.5.3.1. 3.3.1 Setting up the Docker build container¶

After having installed Docker, add yourself to the docker group:

Also make sure to define relevant DNS servers part of the global dns chain in in your </etc/default/docker> configuration file, eg.

<DOCKER_OPTS=” –dns=8.8.8.8 –dns=8.8.8.4”>

Then restart docker:

1.5.3.2. 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
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)
Select “SSH Public Keys” to the left and then “Add Key” and paste your public key in.

1.5.3.3. 3.3.3 Clone the OPNFV code git repository¶

Now it is time to clone the code repository:

Now you should have the OPNFV genesis repository with Fuel@OPNFV stored locally on your build host.

1.6. 4 Building¶

<EXAMPLE>:

There are two methods available for building Fuel@OPNFV:

A low level method using Make
An abstracted method using build.sh

1.6.1. 4.1 Configure your build environment¶

Select the versions of the components you want to build by editing the fuel/build/config.mk file. Note if you want to build with OpenDaylight SDN controller you need to uncomment the lines starting with odl-main and java-main

1.6.2. 4.2 Low level build method using make¶

The low level method is based on Make:

From the <fuel/build directory> invoke <make [target]>

Following targets exist:

none/all - this will:
- If not allready existing, initialize the docker build environment
- If not already done, build OpenDaylight from upstream (as defined by fuel-build config-spec)
- If not already done, build fuel from upstream (as defined by fuel-build/config-spec)
- Build the defined additions to fuel (as defined by the structure of this framework)
- Apply changes and patches to fuel (as defined by the structure of this framework)
- Reconstruct a fuel .iso image
clean - this will remove all artifacts from earlier builds.

If the build is successful, you will find the generated ISO file in the <fuel/build/release> subdirectory!

1.7. 4.3 Abstracted build method using build.sh¶

The abstracted build method useses the <fuel/ci/build.sh> script which allows you to:

Create and use a build cache - significantly speeding up the buildtime if upstream repositories have not changed.
push/pull cache and artifacts to an arbitrary URI (http(s):, file:, ftp:)

For more info type <fuel/ci/build.sh -h>.

1.8. 5 Artifacts¶

<EXAMPLES>:

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.txt> - Which holds version metadata.

1.9. 6 References¶

Revision:

Build date: _date_

2. OPNFV Installation instructions for - < Component denomination >¶

2.1. Abstract¶

This document describes how to install <Component>, it’s dependencies and required system resources.

2.2. 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/>.

Contents

1 Version history

2 Introduction

3 Preface

4 Hardware requirements

5 Top of the rack (TOR) Configuration requirements

6 OPNFV Software installation and deployment

7 Installation health-check

8 Post installation and deployment actions

9 References

2.3. 1 Version history¶

Date	Ver.	Author	Comment
2015-04-14	0.1.0	Jonas Bjurel	First draft
	0.1.1
	1.0

2.4. 2 Introduction¶

<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 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 a result that is OPNFV compliant.

The audience of this document is assumed to have good knowledge in network and Unix/Linux administration.

2.5. 3 Preface¶

<EXAMPLE>:

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>

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> Check-out the Arno release: <cd genesis; git checkout arno> Goto the fuel directory and build the .iso <cd fuel/build; make all>

Familiarize yourself with the Fuel 6.0.1 version by reading the following documents: - abc <http://wiki.openstack.org/abc> - def <http://wiki.openstack.org/def> - ghi <http://wiki.openstack.org/ghi>

Secondly, a number of deployment specific parameters must be collected, those are:

Provider sub-net and gateway information
Provider VLAN information
Provider DNS addresses
Provider NTP addresses

This information will be needed for the configuration procedures provided in this document.

2.6. 4 Hardware requirements¶

<EXAMPLE>:

Following minimum hardware requirements must be met for installation of Fuel@OPNFV:

HW Aspect	Requirement
# of servers	Minimum 5 (3 for non redundant deployment) 1 Fuel deployment master (may be virtualized) 3(1) Controllers 1 Compute
CPU	Minimum 1 socket x86_AMD64 Ivy bridge 1.6 GHz
RAM	Minimum 16GB/server (Depending on VNF work load)
Disk	Minimum 256GB 10kRPM spinning disks
NICs	2(1)x10GE Niantec for Private/Public (Redundant) 2(1)x10GE Niantec for SAN (Redundant) 2(1)x1GE for admin (PXE) and control (RabitMQ,etc)

2.7. 5 Top of the rack (TOR) Configuration requirements¶

<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 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.

2.7.1. 5.1 VLAN considerations and blue-print¶

2.7.2. 5.2 IP Address plan considerations and blue-print¶

2.8. 6 OPNFV Software installation and deployment¶

<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. Etc.

2.8.1. 6.1 Install Fuel master¶

2.8.2. 6.2 Create an OPNV (Fuel Environment)¶

2.8.3. 6.3 Configure the OPNFV environment¶

2.8.4. 6.4 Deploy the OPNFV environment¶

2.9. 7 Installation health-check¶

<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:

Select the “Health check” TAB.
Select all test-cases
And click “Run tests”

All test cases except the following should pass:

2.10. 8 Post installation and deployment actions¶

<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.

Change host OS password: Change the Host OS password by......

2.11. 9 References¶

<EXAMPLES>:

2.11.1. 9.1 OPNFV¶

2.11.2. 9.2 OpenStack¶

2.11.3. 9.3 OpenDaylight¶

2.11.4. 9.4 Fuel¶

3. Open Platform for NFV Project Software Licence¶

Any software developed by the “Open Platform for NFV” Project is licenced under the Apache License, Version 2.0 (the “License”); you may not use the content of this software bundle 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.

4. Open Platform for NFV Project Documentation Licence¶

Any documentation developed by the “Open Platform for NFV Project” 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/>.

Unless required by applicable law or agreed to in writing, documentation 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.

5. Other applicable upstream project Licenses relevant for <Component>¶

You may not use the content of this software bundle except in compliance with the Licenses as listed below: +—————-+—————————-+ | Component | Licence | +—————-+—————————-+ | OpenStack | Apache License 2.0 | +—————-+—————————-+ | OpenDaylight | Eclipse Public License 1.0 | +—————-+—————————-+ | ++ | | +—————-+—————————-+

Revision:

Build date: _date_

6. OPNFV Release Note for “Arno-SRx release” - < Component denomination >¶

6.1. Abstract¶

This document provides the release notes for <RELEASE> of <COMPONENT>.

6.2. 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/>.

Contents

1 Version History

2 Important notes

3 Summary

4 Delivery Data

5 Known Limitations, Issues and Workarounds

6 Test Result

7 References

6.3. 1 Version history¶

Date	Ver.	Author	Comment
2015-04-14	0.1.0	Jonas Bjurel	First draft
	0.1.1
	1.0

6.4. 2 Important notes¶

<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

6.5. 3 Summary¶

<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......

6.6. 4 Release Data¶

<EXAMPLE>:

Project	E.g. Arno/genesis/fuel@opnfv
Repo/commit-ID	E.g. genesis/adf634a0d4.....
Release designation	E.g. Arno RC2
Release date	E.g. 2015-04-16
Purpose of the delivery	E.g. OPNFV Internal quality assurance

6.6.1. 4.1 Version change¶

6.6.1.1. 4.1.1 Module version changes¶

<EXAMPLE>:

Fuel have changed from 5.1 to 6.0.1
OpenDaylight has changed from Helium-SR1 to Helium-SR2

6.6.1.2. 4.1.2 Document version changes¶

<EXAMPLE>:

The Fuel@OPNFV installation guide version has changed from version 0.1 to to 0.2

6.6.2. 4.2 Reason for version¶

6.6.2.1. 4.2.1 Feature additions¶

<EXAMPLE>:

JIRA BACK-LOG:

JIRA REFERENCE	SLOGAN
BGS-123	ADD OpenDaylight ml2 integration
BGS-456	Add auto-deployment of Fuel@OPNFV

6.6.2.2. 4.2.2 Bug corrections¶

JIRA TICKETS:

JIRA REFERENCE	SLOGAN
BGS-888	Fuel doesn’t deploy
BGS-999	Floating IP doesn’t work

6.6.3. 4.3 Deliverables¶

6.6.3.1. 4.3.1 Software deliverables¶

<EXAMPLE>:

6.6.3.2. 4.3.2 Documentation deliverables¶

<EXAMPLE>:

6.7. 5 Known Limitations, Issues and Workarounds¶

6.7.1. 5.1 System Limitations¶

<EXAMPLE>:

Max number of blades: 1 Fuel master, 3 Controllers, 20 Compute blades

Min number of blades: 1 Fuel master, 1 Controller, 1 Compute blade

Storage: Ceph is the only supported storage configuration.

Max number of networks: 3800 (Needs special switch config.)

L3Agent: L3 agent and floating IPs is not supported.

6.7.2. 5.2 Known issues¶

<EXAMPLE>:

JIRA TICKETS:

JIRA REFERENCE	SLOGAN
BGS-987	Nova-compute process does not re-spawn when killed
BGS-654	MOS 5.1 : neutron net-list returns “400 Bad request”

6.7.3. 5.3 Workarounds¶

<EXAMPLE>:

In case the contact with a compute is lost - restart the compute host
In case the disk is full on a controller - delete all files in /tmp

6.8. 6 Test Result¶

<EXAMPLE>:

Fuel@OPNFV Arno RC2 has undergone QA test runs with the following results:

TEST-SUITE

Results:

Tempest test suite 123

Following tests failed:

Image resizing....
Heat deploy....

Robot test suite 456

Following tests failed:

1.......

2.......

6.9. 7 References¶

<EXAMPLE>:

For more information on the OPNFV Arno release, please see:

http://wiki.opnfv.org/release/arno

Indices and tables¶

Search Page

Revision:

Build date: December 06, 2016