1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. SPDX-License-Identifier CC-BY-4.0
.. (c) Open Platform for NFV Project, Inc. and its contributors
Introduction
============
This document describes the software and hardware reference frameworks used by Auto,
and provides guidelines on how to perform configurations and additional installations.
Goal
====
The goal of `Auto <http://docs.opnfv.org/en/latest/release/release-notes.html>`_ installation and configuration is to prepare
an environment where the `Auto use cases <http://docs.opnfv.org/en/latest/submodules/auto/docs/release/userguide/index.html#auto-userguide>`_
can be assessed, i.e. where the corresponding test cases can be executed and their results can be collected.
An instance of ONAP needs to be present, as well as a number of deployed VNFs, in the scope of the use cases.
The initial Auto use cases cover:
* Edge Cloud (increased autonomy and automation for managing Edge VNFs)
* Resilience Improvements through ONAP (reduced recovery time for VNFs and end-to-end services in case of failure or suboptimal performance)
* Enterprise vCPE (automation, cost optimization, and performance assurance of enterprise connectivity to Data Centers and the Internet)
The general idea of Auto is to install an OPNFV environment (comprising at least one Cloud Manager),
an ONAP instance, ONAP-deployed VNFs as required by use cases, possibly additional cloud managers not
already installed during the OPNFV environment setup, traffic generators, and the Auto-specific software
for the use cases (which can include test frameworks such as `Robot <http://robotframework.org/>`_ or `Functest <http://docs.opnfv.org/en/latest/submodules/functest/docs/release/release-notes/index.html#functest-releasenotes>`_).
The ONAP instance needs to be configured with policies and closed-loop controls (also as required by use cases),
and the test framework controls the execution and result collection of all the test cases.
The following diagram illustrates two execution environments, for x86 architectures and for Arm architectures.
The installation process depends on the underlying architecture, since certain components may require a
specific binary-compatible version for a given x86 or Arm architecture. The preferred variant of ONAP is one
that runs on Kubernetes, while all VNF types are of interest to Auto: VM-based or containerized (on any cloud
manager), for x86 or for Arm. The initial VM-based VNFs will cover OpenStack, and in future versions,
additional cloud managers will be considered. The configuration of ONAP and of test cases should not depend
on the architecture.
.. image:: auto-installTarget-generic.jpg
For each component, various installer tools will be selected (based on simplicity and performance), and
may change from one Auto release to the next. For example, the most natural installer for ONAP should be
OOM (ONAP Operations Manager).
The initial version of Auto will focus on OpenStack VM-based VNFs, onboarded and deployed via ONAP API
(not by ONAP GUI, for the purpose of automation). ONAP is installed on Kubernetes. Two servers from LaaS
are used: one to support an OpenStack instance as provided by the OPNFV installation via Fuel/MCP, and
the other to support ONAP with Kubernetes and Docker. Therefore, the VNF execution environment is the
server with the OpenStack instance.
.. image:: auto-installTarget-initial.jpg
Jenkins will be used for Continuous Integration in OPNFV releases, to ensure that the latest master
branch of Auto is always working.
Moreover, Auto will offer an API, which can be imported as a module, and can be accessed for example
by a web application. The following diagram shows the planned structure for the Auto Git repository,
supporting this module, as well as the installation scripts, test case software, utilities, and documentation.
.. image:: auto-repo-folders.jpg
Pre-configuration activities
============================
The following resources will be required for the initial version of Auto:
* two LaaS (OPNFV Lab-as-a-Service) pods, with their associated network information. Later, other types of target pods will be supported.
* the `Auto Git repository <https://git.opnfv.org/auto/tree/>`_ (clone from `Gerrit Auto <https://gerrit.opnfv.org/gerrit/#/admin/projects/auto>`_)
Hardware configuration
======================
<TBC>
Feature configuration
=====================
Environment installation
^^^^^^^^^^^^^^^^^^^^^^^^
Current Auto work in progress is captured in the `Auto Lab Deployment wiki page <https://wiki.opnfv.org/display/AUTO/Auto+Lab+Deployment>`_.
OPNFV with OpenStack
~~~~~~~~~~~~~~~~~~~~
The Auto installation uses the Fuel/MCP installer for the OPNFV environment (see the
`OPNFV download page <https://www.opnfv.org/software/downloads>`_).
The following figure summarizes the two installation cases: virtual or baremetal.
This OPNFV installer starts with installing a Salt Master, which then configures
subnets and bridges, and install VMs (e.g., for controllers and compute nodes)
and an OpenStack instance with predefined credentials.
.. image:: auto-OPFNV-fuel.jpg
The Auto version of OPNFV installation configures additional resources for the OpenStack virtual pod,
as compared to the default installation. Examples of manual steps are as follows:
.. code-block:: console
1. mkdir /opt/fuel
2. cd /opt/fuel
3. git clone https://git.opnfv.org/fuel
4. cd fuel
5. vi /opt/fuel/fuel/mcp/config/scenario/os-nosdn-nofeature-noha.yaml
These lines can be added to configure more resources:
.. code-block:: yaml
gtw01:
ram: 2048
+ cmp01:
+ vcpus: 16
+ ram: 65536
+ disk: 40
+ cmp02:
+ vcpus: 16
+ ram: 65536
+ disk: 40
The final step deploys OpenStack (duration: approximately between 30 and 45 minutes).
.. code-block:: console
6. ci/deploy.sh -l UNH-LaaS -p virtual1 -s os-nosdn-nofeature-noha -D |& tee deploy.log
ONAP on Kubernetes
~~~~~~~~~~~~~~~~~~
An ONAP installation on OpenStack has also been investigated, but we focus here on
the ONAP on Kubernetes version.
The initial focus is on x86 architectures. The ONAP DCAE component for a while was not operational
on Kubernetes, and had to be installed separately on OpenStack. So the ONAP instance was a hybrid,
with all components except DCAE running on Kubernetes, and DCAE running separately on OpenStack.
For Arm architectures, specialized Docker images are being developed to provide Arm architecture
binary compatibility.
The goal for the first release of Auto is to use an ONAP instance where DCAE also runs on Kubernetes,
for both architectures.
The ONAP reference for this installation is detailed `here <https://wiki.onap.org/display/DW/ONAP+on+Kubernetes>`_.
Examples of manual steps for the deploy procedure are as follows:
.. code-block:: console
1 git clone https://gerrit.onap.org/r/oom
2 cd oom
3 git pull https://gerrit.onap.org/r/oom refs/changes/19/32019/6
4 cd install/rancher
5 ./oom_rancher_setup.sh -b master -s <your external ip> -e onap
6 cd oom/kubernetes/config
7 (modify onap-parameters.yaml for VIM connection (manual))
8 ./createConfig.sh -n onap
9 cd ../oneclick
10 ./createAll.bash -n onap
ONAP configuration
^^^^^^^^^^^^^^^^^^
This section describes the logical steps performed by the Auto scripts to prepare ONAP and VNFs.
VNF deployment
~~~~~~~~~~~~~~
<TBC; pre-onboarding, onboarding, deployment>
Policy and closed-loop control configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<TBC>
Traffic Generator configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<TBC>
Test Case software installation and execution control
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<TBC>
Installation health-check
=========================
<TBC; the Auto installation will self-check, but indicate here manual steps to double-check that the installation was successful>
References
==========
Auto Wiki pages:
* `Auto wiki main page <https://wiki.opnfv.org/pages/viewpage.action?pageId=12389095>`_
* `Auto Lab Deployment wiki page <https://wiki.opnfv.org/display/AUTO/Auto+Lab+Deployment>`_
OPNFV documentation on Auto:
* `Auto release notes <http://docs.opnfv.org/en/latest/release/release-notes.html>`_
* `Auto use case user guides <http://docs.opnfv.org/en/latest/submodules/auto/docs/release/userguide/index.html#auto-userguide>`_
Git&Gerrit Auto repositories:
* `Auto Git repository <https://git.opnfv.org/auto/tree/>`_
* `Gerrit for Auto project <https://gerrit.opnfv.org/gerrit/#/admin/projects/auto>`_
|
