According to SFC RFC standard, the chains should be decoupled
from classifiers.
In Networking-sfc the chains and classifiers are completely
decoupled. This patch lets user can do it by allow creating
VNFFG with no flow-classifier.
User can use "tosca-vnffgd-no-classifier-sample.yaml" to create
VNFFG with no flow-classifier. User also have the ability to
add flow-classifiers through updating VNFFG with
"tosca-vnffgd-sample.yaml" in vnffgd tosca templates folder.
This patch only support Forwarding path with type
"tosca.nodes.nfv.FP.TackerV2". Tacker also support altering the
direction of the traffic in forwarding path, update new
forwarding path, add, remove and update flow-classifers though
updating VNFFG.
For more information: https://review.openstack.org/#/c/531817
Change-Id: Ice2f0f03f7a90f4fefdee751283ff26b9c037d87
Closes-Bug: #1745818
While deploying a vnf with autoscaling, heat translator failed with
premission denied error. This issue occured because [1] opening file
in root dir (i.e. '/'), due to which it giving permission denied.
Fixing it by setting current working dir as '/temp'
[1]: https://github.com/openstack/heat-translator/blob/master/translator/hot/tosca_translator.py#L69
Change-Id: Ib2b0fd6c4c32a523b9fb25f47eae19225b84439f
Closes-bug: #1749394
This patch along with another patch on the tacker client
will remove the need to mention ssl_ca_cert in the vim
configuration file.
Tacker client patch: https://review.openstack.org/546578
Change-Id: I362c40e8b2a606e3b28d368a95e74ee5ea306241
This patch adds the customized OpenWRT image that enables DHCP making
the VNF can be ping. Therefore, the continuously respawning of VNF
can be fixed.
This patch also rewrites the instruction of deploying VNF
based on OpenWRT.
Change-Id: Ieb4d98fe374676bad101a6c2965354a9b19ea0a2
Closes-Bug: #1557008
Closes-Bug: #1749243
Closes-Bug: #1709557
Until now there was no implementation of updating an existing
VNFFG with the use of the 'vnffgd-template' parameter which is
introduced in the Tacker client side. This patch addresses exactly
that.
Implements: blueprint update-vnffg
Change-Id: I8fa748a76fd479649be5dd7a19244f7143849687
Signed-off-by: Dimitrios Markou <mardim@intracom-telecom.com>
The reason is wrong in manual_installation.rst.
Written in manual_installation.rst is [nfvo], but wrote in the code is
[nfvo_vim].
The source code as follows:
tacker/nfvo/nfvo_plugin.py:79: cfg.CONF.register_opts(OPTS,
'nfvo_vim')
Change-Id: I6d130e646ca82697f6a2bcc0ef886a16f16912a3
This spec proposes implementing containerized VNF. We choose
to use Kubernetes resources (ConfigMap, Deployment, Horizontal
Pod Autoscaler, Service, etc) to define a containerized VNF.
1. Add "configurable_properties" type in VDU node.
2. Support translate TOSCA to Kubernetes templates.
3. Add kubernetes infra driver to support CRUD containerized
VNF.
Implements: blueprint containerised-vnfs
Change-Id: I706f1f325ca8c2b33debd7e6a13e81535245a5ad
Zuul no longer requires the project-name for in-repo configuration.
Omitting it makes forking or renaming projects easier.
Change-Id: I9ea26512320eab0a154880b991910656a8651e87
Because of null tenant_id, vnffg delete operation fails to delete
entry from ACLMatchCriteria.Hence delete attemp on parent table fails
with DBReferenceError.
Co-Authored-By: Dharmendra Kushwaha<dharmendra.kushwaha@nectechnologies.in>
Closes-Bug: 1658364
Change-Id: I699f66dfa2eab49dc5239e70973b68967f4d0142
The functinality of naming the classifiers which are
created through a vnffgd template is essential so the user
can identify somehow the classifiers that he created for a chain.
In addition to that the classifiers' names would be an important
tool in subsequent patches where we will use them to update the ACL
of an existing classifier though the vnffgd template. We are going to
use the name to identify which classifier's ACL the user wants to
update.
Change-Id: Ia586061c578a99662d49ad284d1ff313c350e1f3
Signed-off-by: Dimitrios Markou <mardim@intracom-telecom.com>
Although tacker client side supports the update of the VNFs which
are currently used in an existing VNFFG this functionality is not
implemented at the Tacker server side.
Through this patch we are trying to address exactly that problem.
Also this patch is the first step for the implementation of this:
Implements: blueprint update-vnffg
Change-Id: I147e9f8a52f3e307767cd855492eb9bb5867cf29
Signed-off-by: Dimitrios Markou <mardim@intracom-telecom.com>
TEMPEST_SERVICES global variable is not supported
by devstack since long back.
- I380dd20e5ed716a0bdf92aa02c3730359b8136e4
- I9c24705e494689f09a885eb0a640efd50db33fcf
Service availability of tempest known services will be
set by devstack with local check.
- I02be777bf93143d946ccbb8e9eff637bfd1928d4
Tacker does not have tempest plugin so it does
not need to have service register in tempest.
This commit removes the commented TEMPEST_SERVICES
setting to avoid any confusion.
Change-Id: I7ea859ce373e5118ebf38bc1adcb6b6fec97f785
Related-Bug: #1743688
Tacker uses the class path+file name+uuid as stack names to
uniquely identify the stacks for vnf create and vnf respawn workflow.
Tacker now mandates VNF names to be provided in API layer and will be
made unique. It is useful to base stack names based on vnf names for
debugging purposes. This affects the naming of nova instances as well.
Change-Id: If043ad8c6c356f3fa1d2f5648d3d861ff5006602
Closes-Bug: #1590215
