Merge "Add LCM op figures to User Guide"
BIN
doc/source/_images/etsi_cnf_healing.png
Normal file
After Width: | Height: | Size: 34 KiB |
35
doc/source/_images/etsi_cnf_healing.pu
Normal file
@ -0,0 +1,35 @@
|
||||
@startuml
|
||||
|
||||
frame "python-tackerclient" {
|
||||
component "tacker-client" as client
|
||||
}
|
||||
|
||||
frame "tacker" {
|
||||
component "tacker-server" {
|
||||
component "server" as serv
|
||||
}
|
||||
component "tacker-conductor" {
|
||||
component "conductor" as cond
|
||||
component "Kubernetes\ninfra-driver" as infra
|
||||
}
|
||||
}
|
||||
|
||||
node "Kubernetes\nCluster\n(Master)" as k8s_m
|
||||
cloud "Hardware Resources" as hw {
|
||||
node "Kubernetes\nCluster\n(Worker)" as k8s_w {
|
||||
node "Pod" as ins1
|
||||
node "Pod" as ins2
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
'# Relationships
|
||||
client --> serv: 1. Request\n heal VNF
|
||||
serv --> cond
|
||||
cond --> infra
|
||||
infra -right-> k8s_m: 2. Call Kubernetes\n API
|
||||
k8s_m --> ins1: 3. Re-create Pods
|
||||
k8s_m --> ins2
|
||||
ins1 -[hidden]right-> ins2
|
||||
|
||||
@enduml
|
BIN
doc/source/_images/etsi_cnf_scaling.png
Normal file
After Width: | Height: | Size: 32 KiB |
34
doc/source/_images/etsi_cnf_scaling.pu
Normal file
@ -0,0 +1,34 @@
|
||||
@startuml
|
||||
|
||||
frame "python-tackerclient" {
|
||||
component "tacker-client" as client
|
||||
}
|
||||
|
||||
frame "tacker" {
|
||||
component "tacker-server" {
|
||||
component "server" as serv
|
||||
}
|
||||
component "tacker-conductor" {
|
||||
component "conductor" as cond
|
||||
component "Kubernetes\ninfra-driver" as infra
|
||||
}
|
||||
}
|
||||
|
||||
node "Kubernetes\nCluster\n(Master)" as k8s_m
|
||||
cloud "Hardware Resources" as hw {
|
||||
node "Kubernetes\nCluster\n(Worker)" as k8s_w {
|
||||
node "Pod" as ins1
|
||||
node "Pod" as ins2
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
'# Relationships
|
||||
client --> serv: 1. Request\n scale VNF
|
||||
serv --> cond
|
||||
cond --> infra
|
||||
infra -right-> k8s_m: 2. Call Kubernetes\n API
|
||||
k8s_m --> ins1: 3. Change the\n number of\n Pods
|
||||
ins1 -[hidden]right-> ins2
|
||||
|
||||
@enduml
|
BIN
doc/source/_images/etsi_containerized_vnf_usage_guide.png
Normal file
After Width: | Height: | Size: 43 KiB |
38
doc/source/_images/etsi_containerized_vnf_usage_guide.pu
Normal file
@ -0,0 +1,38 @@
|
||||
@startuml
|
||||
|
||||
frame "python-tackerclient" {
|
||||
component "tacker-client" as client {
|
||||
package "VNF Package" as vnfpkg {
|
||||
file "VNFD" as vnfd
|
||||
file "CNF\nDefinition" as cnfd
|
||||
}
|
||||
file "Instantiate\nparameters" as inst_param
|
||||
}
|
||||
}
|
||||
|
||||
frame "tacker" {
|
||||
component "tacker-server" {
|
||||
component "server" as serv
|
||||
}
|
||||
component "tacker-conductor" {
|
||||
component "conductor" as cond
|
||||
component "Kubernetes\ninfra-driver" as infra
|
||||
}
|
||||
}
|
||||
|
||||
node "Kubernetes\nCluster\n(Master)" as k8s_m
|
||||
cloud "Hardware Resources" as hw {
|
||||
node "Kubernetes\nCluster\n(Worker)" as k8s_w {
|
||||
node "Pod" as ins1
|
||||
}
|
||||
}
|
||||
|
||||
'# Relationships
|
||||
vnfpkg --> serv: 1. Request\n create VNF
|
||||
inst_param --> serv: 2. Request\n instantiate VNF
|
||||
serv --> cond
|
||||
cond --> infra
|
||||
infra -right-> k8s_m: 3. Call Kubernetes\n API
|
||||
k8s_m --> ins1: 4. Create a Pod
|
||||
|
||||
@enduml
|
BIN
doc/source/_images/etsi_vnf_deployment_as_vm_with_tosca.png
Normal file
After Width: | Height: | Size: 36 KiB |
35
doc/source/_images/etsi_vnf_deployment_as_vm_with_tosca.pu
Normal file
@ -0,0 +1,35 @@
|
||||
@startuml
|
||||
|
||||
frame "python-tackerclient" {
|
||||
component "tacker-client" as client {
|
||||
package "VNF Package" as vnfpkg {
|
||||
file "VNFD" as vnfd
|
||||
}
|
||||
file "Instantiate\nparameters" as inst_param
|
||||
}
|
||||
}
|
||||
|
||||
frame "tacker" {
|
||||
component "tacker-server" {
|
||||
component "server" as serv
|
||||
}
|
||||
component "tacker-conductor" {
|
||||
component "conductor" as cond
|
||||
component "OpenStack\ninfra-driver" as infra
|
||||
}
|
||||
}
|
||||
|
||||
node "OpenStack\nHeat" as heat
|
||||
cloud "Hardware Resources" as hw {
|
||||
node "VM" as ins1
|
||||
}
|
||||
|
||||
'# Relationships
|
||||
vnfpkg --> serv: 1. Request\n create VNF
|
||||
inst_param --> serv: 2. Request\n instantiate VNF
|
||||
serv --> cond
|
||||
cond --> infra
|
||||
infra -right-> heat: 3. Call OpenStack\n Heat API
|
||||
heat --> ins1: 4. Create a VM
|
||||
|
||||
@enduml
|
BIN
doc/source/_images/etsi_vnf_deployment_as_vm_with_user_data.png
Normal file
After Width: | Height: | Size: 40 KiB |
@ -0,0 +1,38 @@
|
||||
@startuml
|
||||
|
||||
frame "python-tackerclient" {
|
||||
component "tacker-client" as client {
|
||||
package "VNF Package" as vnfpkg {
|
||||
file "VNFD" as vnfd
|
||||
file "UserData" as userdata
|
||||
file "BaseHOT" as hot
|
||||
}
|
||||
file "Instantiate\nparameters" as inst_param
|
||||
}
|
||||
}
|
||||
|
||||
frame "tacker" {
|
||||
component "tacker-server" {
|
||||
component "server" as serv
|
||||
}
|
||||
component "tacker-conductor" {
|
||||
component "conductor" as cond
|
||||
component "OpenStack\ninfra-driver" as infra
|
||||
}
|
||||
}
|
||||
|
||||
node "OpenStack\nHeat" as heat
|
||||
cloud "Hardware Resources" as hw {
|
||||
node "VM" as ins1
|
||||
}
|
||||
|
||||
'# Relationships
|
||||
hot -[hidden]down-> serv
|
||||
vnfpkg --> serv: 1. Request\n create VNF
|
||||
inst_param --> serv: 2. Request\n instantiate VNF
|
||||
serv --> cond
|
||||
cond --> infra
|
||||
infra -right-> heat: 3. Call OpenStack\n Heat API
|
||||
heat --> ins1: 4. Create a VM
|
||||
|
||||
@enduml
|
BIN
doc/source/_images/etsi_vnf_healing.png
Normal file
After Width: | Height: | Size: 28 KiB |
33
doc/source/_images/etsi_vnf_healing.pu
Normal file
@ -0,0 +1,33 @@
|
||||
@startuml
|
||||
|
||||
frame "python-tackerclient" {
|
||||
component "tacker-client" as client
|
||||
}
|
||||
|
||||
frame "tacker" {
|
||||
component "tacker-server" {
|
||||
component "server" as serv
|
||||
}
|
||||
component "tacker-conductor" {
|
||||
component "conductor" as cond
|
||||
component "OpenStack\ninfra-driver" as infra
|
||||
}
|
||||
}
|
||||
|
||||
node "OpenStack\nHeat" as heat
|
||||
cloud "Hardware Resources" as hw {
|
||||
node "VM" as ins1
|
||||
node "VM" as ins2
|
||||
}
|
||||
|
||||
|
||||
'# Relationships
|
||||
client --> serv: 1. Request\n heal VNF
|
||||
serv --> cond
|
||||
cond --> infra
|
||||
infra -right-> heat: 2. Call OpenStack\n Heat API
|
||||
heat --> ins1: 3. Re-create VMs
|
||||
heat --> ins2
|
||||
ins1 -[hidden]right-> ins2
|
||||
|
||||
@enduml
|
BIN
doc/source/_images/etsi_vnf_scaling.png
Normal file
After Width: | Height: | Size: 28 KiB |
32
doc/source/_images/etsi_vnf_scaling.pu
Normal file
@ -0,0 +1,32 @@
|
||||
@startuml
|
||||
|
||||
frame "python-tackerclient" {
|
||||
component "tacker-client" as client
|
||||
}
|
||||
|
||||
frame "tacker" {
|
||||
component "tacker-server" {
|
||||
component "server" as serv
|
||||
}
|
||||
component "tacker-conductor" {
|
||||
component "conductor" as cond
|
||||
component "OpenStack\ninfra-driver" as infra
|
||||
}
|
||||
}
|
||||
|
||||
node "OpenStack\nHeat" as heat
|
||||
cloud "Hardware Resources" as hw {
|
||||
node "VM" as ins1
|
||||
node "VM" as ins2
|
||||
}
|
||||
|
||||
|
||||
'# Relationships
|
||||
client --> serv: 1. Request\n scale VNF
|
||||
serv --> cond
|
||||
cond --> infra
|
||||
infra -right-> heat: 2. Call OpenStack\n Heat API
|
||||
heat --> ins1: 3. Change the\n number of\n VMs
|
||||
ins1 -[hidden]right-> ins2
|
||||
|
||||
@enduml
|
@ -4,6 +4,32 @@ ETSI NFV-SOL CNF Healing
|
||||
|
||||
This document describes how to heal CNF in Tacker.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The diagram below shows an overview of the CNF healing.
|
||||
|
||||
1. Request heal VNF
|
||||
|
||||
A user requests tacker-server to heal a VNF or all VNFs with tacker-client
|
||||
by requesting ``heal VNF``.
|
||||
|
||||
2. Call Kubernetes API
|
||||
|
||||
Upon receiving a request from tacker-client, tacker-server redirects it to
|
||||
tacker-conductor. In tacker-conductor, the request is redirected again to
|
||||
an appropriate infra-driver (in this case Kubernetes infra-driver) according
|
||||
to the contents of the instantiate parameters. Then, Kubernetes
|
||||
infra-driver calls Kubernetes APIs.
|
||||
|
||||
3. Re-create Pods
|
||||
|
||||
Kubernetes Master re-creates Pods according to the API calls.
|
||||
|
||||
.. figure:: ../_images/etsi_cnf_healing.png
|
||||
:align: left
|
||||
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
|
@ -4,6 +4,31 @@ ETSI NFV-SOL CNF Scaling
|
||||
|
||||
This document describes how to scale CNF in Tacker.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The diagram below shows an overview of the CNF scaling.
|
||||
|
||||
1. Request scale VNF
|
||||
|
||||
A user requests tacker-server to scale a VNF or all VNFs with tacker-client
|
||||
by requesting ``scale VNF``.
|
||||
|
||||
2. Call Kubernetes API
|
||||
|
||||
Upon receiving a request from tacker-client, tacker-server redirects it to
|
||||
tacker-conductor. In tacker-conductor, the request is redirected again to
|
||||
an appropriate infra-driver (in this case Kubernetes infra-driver) according
|
||||
to the contents of the instantiate parameters. Then, Kubernetes
|
||||
infra-driver calls Kubernetes APIs.
|
||||
|
||||
3. Change the number of Pods
|
||||
|
||||
Kubernetes Master change the number of Pods according to the API calls.
|
||||
|
||||
.. figure:: ../_images/etsi_cnf_scaling.png
|
||||
:align: left
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
|
@ -5,6 +5,39 @@ ETSI NFV-SOL CNF (Containerized VNF) Deployment
|
||||
This section covers how to deploy ETSI NFV-SOL containerized VNF
|
||||
in Tacker using Kubernetes VIM.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The following figure shows an overview of the CNF deployment.
|
||||
|
||||
1. Request create VNF
|
||||
|
||||
A user requests tacker-server to create a VNF with tacker-client by
|
||||
uploading a VNF Package and requesting ``create VNF``. The VNF Package
|
||||
should contain ``CNF Definition`` in addition to ``VNFD``. The detailed
|
||||
explanation of ``CNF Definition`` and ``VNFD`` can be found in :ref:`Create
|
||||
a Kubernetes Object File` and :ref:`Create VNFD`, respectively.
|
||||
|
||||
2. Request instantiate VNF
|
||||
|
||||
A user requests tacker-server to instantiate the created VNF by requesting
|
||||
``instantiate VNF`` with instantiate parameters.
|
||||
|
||||
3. Call Kubernetes API
|
||||
|
||||
Upon receiving a request from tacker-client, tacker-server redirects it to
|
||||
tacker-conductor. In tacker-conductor, the request is redirected again to
|
||||
an appropriate infra-driver (in this case Kubernetes infra-driver) according
|
||||
to the contents of the instantiate parameters. Then, Kubernetes
|
||||
infra-driver calls Kubernetes APIs to create a Pod as a VNF.
|
||||
|
||||
4. Create a Pod
|
||||
|
||||
Kubernetes Master creates a Pod according to the API calls.
|
||||
|
||||
.. figure:: ../_images/etsi_containerized_vnf_usage_guide.png
|
||||
:align: left
|
||||
|
||||
Prepare Kubernetes VIM
|
||||
=======================
|
||||
1. Create a Config File
|
||||
@ -135,6 +168,8 @@ Here is a sample of building a VNF Package CSAR directory:
|
||||
|
||||
$ mkdir -p deployment/{TOSCA-Metadata,Definitions,Files/kubernetes}
|
||||
|
||||
.. _Create a Kubernetes Object File:
|
||||
|
||||
2. Create a Kubernetes Object File
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A CSAR VNF package shall have a object file that defines Kubernetes resources
|
||||
@ -224,6 +259,8 @@ on TOSCA specifications.
|
||||
$ wget https://forge.etsi.org/rep/nfv/SOL001/raw/v2.6.1/etsi_nfv_sol001_common_types.yaml
|
||||
$ wget https://forge.etsi.org/rep/nfv/SOL001/raw/v2.6.1/etsi_nfv_sol001_vnfd_types.yaml
|
||||
|
||||
.. _Create VNFD:
|
||||
|
||||
5. Create VNFD
|
||||
~~~~~~~~~~~~~~
|
||||
How to create VNFD composed of plural deployment flavours is described in
|
||||
|
@ -5,6 +5,38 @@ ETSI NFV-SOL VNF Deployment as VM with TOSCA
|
||||
This document describes how to deploy VNF as VM with TOSCA
|
||||
in Tacker using CLI commands.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The diagram below shows an overview of the VNF deployment.
|
||||
|
||||
1. Request create VNF
|
||||
|
||||
A user requests tacker-server to create a VNF with tacker-client by
|
||||
uploading a VNF Package and requesting ``create VNF``. The VNF Package
|
||||
should contain ``VNFD``. The detailed explanation of ``VNFD`` can be found
|
||||
in :doc:`./vnf-package`.
|
||||
|
||||
2. Request instantiate VNF
|
||||
|
||||
A user requests tacker-server to instantiate the created VNF by requesting
|
||||
``instantiate VNF`` with instantiate parameters.
|
||||
|
||||
3. Call OpenStack Heat API
|
||||
|
||||
Upon receiving a request from tacker-client, tacker-server redirects it to
|
||||
tacker-conductor. In tacker-conductor, the request is redirected again to
|
||||
an appropriate infra-driver (in this case OpenStack infra-driver) according
|
||||
to the contents of the instantiate parameters. Then, OpenStack infra-driver
|
||||
calls OpenStack Heat APIs to create a VM as a VNF.
|
||||
|
||||
4. Create a VM
|
||||
|
||||
OpenStack Heat creates a VM according to the API calls.
|
||||
|
||||
.. figure:: ../_images/etsi_vnf_deployment_as_vm_with_tosca.png
|
||||
:align: left
|
||||
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
@ -12,6 +12,38 @@ for more information on LCM operation user data.
|
||||
but some have 'LCM operation user data' specific descriptions.
|
||||
The part will be clarified with the notation [This is UserData specific part].
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The diagram below shows an overview of the VNF deployment.
|
||||
|
||||
1. Request create VNF
|
||||
|
||||
A user requests tacker-server to create a VNF with tacker-client by
|
||||
uploading a VNF Package and requesting ``create VNF``. The VNF Package
|
||||
should contain ``BaseHOT`` and ``UserData`` in addition to ``VNFD``. The
|
||||
detailed explanation of these contents can be found in :doc:`./vnf-package`.
|
||||
|
||||
2. Request instantiate VNF
|
||||
|
||||
A user requests tacker-server to instantiate the created VNF by requesting
|
||||
``instantiate VNF`` with instantiate parameters.
|
||||
|
||||
3. Call OpenStack Heat API
|
||||
|
||||
Upon receiving a request, tacker-server redirects it to tacker-conductor.
|
||||
In tacker-conductor, the request is redirected again to an appropriate
|
||||
infra-driver (in this case OpenStack infra-driver) according to the contents
|
||||
of the instantiate parameters. Then, OpenStack infra-driver calls OpenStack
|
||||
Heat APIs to create a VM as a VNF.
|
||||
|
||||
4. Create a VM
|
||||
|
||||
OpenStack Heat creates a VM according to the API calls.
|
||||
|
||||
.. figure:: ../_images/etsi_vnf_deployment_as_vm_with_user_data.png
|
||||
:align: left
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
|
@ -4,6 +4,32 @@ ETSI NFV-SOL VNF Healing
|
||||
|
||||
This document describes how to heal VNF in Tacker.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The diagram below shows an overview of the VNF healing.
|
||||
|
||||
1. Request heal VNF
|
||||
|
||||
A user requests tacker-server to heal a VNF or all VNFs with tacker-client
|
||||
by requesting ``heal VNF``.
|
||||
|
||||
2. Call OpenStack Heat API
|
||||
|
||||
Upon receiving a request from tacker-client, tacker-server redirects it to
|
||||
tacker-conductor. In tacker-conductor, the request is redirected again to
|
||||
an appropriate infra-driver (in this case OpenStack infra-driver) according
|
||||
to the contents of the instantiate parameters. Then, OpenStack infra-driver
|
||||
calls OpenStack Heat APIs.
|
||||
|
||||
3. Re-create VMs
|
||||
|
||||
OpenStack Heat re-creates VMs according to the API calls.
|
||||
|
||||
.. figure:: ../_images/etsi_vnf_healing.png
|
||||
:align: left
|
||||
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
|
@ -4,6 +4,32 @@ ETSI NFV-SOL VNF Scaling
|
||||
|
||||
This document describes how to scale VNF in Tacker.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The diagram below shows an overview of the VNF scaling.
|
||||
|
||||
1. Request scale VNF
|
||||
|
||||
A user requests tacker-server to scale a VNF or all VNFs with tacker-client
|
||||
by requesting ``scale VNF``.
|
||||
|
||||
2. Call OpenStack Heat API
|
||||
|
||||
Upon receiving a request from tacker-client, tacker-server redirects it to
|
||||
tacker-conductor. In tacker-conductor, the request is redirected again to
|
||||
an appropriate infra-driver (in this case OpenStack infra-driver) according
|
||||
to the contents of the instantiate parameters. Then, OpenStack infra-driver
|
||||
calls OpenStack Heat APIs.
|
||||
|
||||
3. Change the number of VMs
|
||||
|
||||
OpenStack Heat change the number of VMs according to the API calls.
|
||||
|
||||
.. figure:: ../_images/etsi_vnf_scaling.png
|
||||
:align: left
|
||||
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
|