[tacker][ptg] Yoga PTG summary

yasufum yasufum.o at gmail.com
Mon Nov 1 16:50:05 UTC 2021


Hi everyone,

Thank you for participating in the Yoga PTG sessions. We discussed 17 
items totally, including 13 specs, and agreed all to implement the 
proposed features. We also decided to set the spec freeze on 31th Dec. 
The etherpad of our PTG is at
https://etherpad.opendev.org/p/tacker-yoga-ptg

Here is a summary of the PTG sessions.

*Day 1
   1. Introduce for Tacker installer
     * To reduce uinteresting steps of setting up tacker, we introduce a 
dedicated installer for developers.
     * For beginners, we should minimize difficulties of deploying and 
make them focusing on their usecases.

   2. Prometheus monitoring and AutoHeal support for Kubernetes Cluster 
VNF via FM Interface
     * Add fault management interface support applied with ETSI SOL003 
standards including polling mode and notify mode.
     * Polling mode responds to resources that is named "Alarms" and 
"Individual alarm". On the other hand, notify mode responds to resources 
that is named "Subscriptions" and "Notification endpoint"

   3. Support VNF update operations reflecting changes to VNF instances 
using MgmtDriver
     * Add update APIs for container VNF instances by using ConfigMap 
and Secret of k8s.

   4. Support CentOS stream
     * Revise our current incomplete CentOS support for the latest 'stream'.
     * We will provide some functional tests for the update, but 
non-voting for a while.

   5. Add VNF Package sample for practical use cases
     * Provide more practical examples of usecase of tacker for users 
because current usecases in documentation are simple and not enough so 
much for
       actual cases.
     * There are three examples supposed in the proposal, "use multiple 
deployment flavours", "deploy VNF connected to external network" and 
"deploy VNF as HA cluster".

*Day 2
   6. Support handling large query results by ETSI NFV
     * Introduce an extended feature for reducing a large amount of 
result for some queries defined in ETSI standards.
     * The idea is simply dividing the results in several pieces with 
paging.

   7. Support FT of Multi tenant
     * There are two problems in multi-tenancy case, (1) No restriction 
in assigning a tenant,(2) Notifying events on different tenants.
     * The policy of assigning a tenant should be clarified and also 
Notification process under multi-tenancy should be changed.
     * We need to clear the policy of RBAC (Is it allowed to make admin 
user can access all resources?)

   8. Sample Ansible Driver
     * There are no management drivers enable VNF Configuration using 
Ansible. So, add the scripts as samples and docs.
     * Revise the name of directories for considering conventioins in 
takcer repo is necessary.
     * This can be used for 'Add VNF Package sample for practical use 
cases' proposal. We wii support the sample development.

   9. Support Robot Framework API
     * Currently Tacker functional tests mainly focus on checking 
various VNF patterns such as a simple VNF, multi VDU, volume attach and 
affinity set. Tacker community is advancing ETSI NFV standard 
compliance, and coverage of compliant API testing becomes important.
     * The proposal is to use Robot Framework to achieve automated API 
testing and in the first step, we adopt API test code released by ETSI 
NFV-TST010.
   10. Add Tacker-horizon Unit Test Cases
     * `tacker-horizon` which provides very limited features, such as 
showing a list of registered VIMs, VNFDs or so. We don't use this 
feature so much without checking instances of Tacker quickly via 
intuitive Web GUI way. So, we have not maintained tacker-horizon so actively
     * One of the reasons why bugs in tacker-horizon have not fixed is 
that we have no unittests in. Although we can find a bug coincidentally 
while using the features, but should implement unittests because bugs in 
horizon are some contextual and not so easy to find by hand.

*Day 3
   11.  Report for ETSI  NFV API Conformance Test Results
     * Share the result of Remote NFV&MEC API Plugtest 2021, Totally 136 
API Conformance test sessions were executed for [NFV-SOL003] were 
executed as well as for NFV-SOL005.
     * https://hackmd.io/q4DzQ6_2Q0e-TdmtBikVlQ?view

   12. Reduce code clone from sol-kubernetes job of FT
     * There are much similar files can be reduced for functional tests. 
It makes maintenance more complicated and difficult. The goal is to 
reduce it to less than 20%.
     * In particular, since sol_kubernetes's code clone rate is up to 
40% , we think it will be better to refactor to make future maintenance 
easier.
       * other details: https://hackmd.io/Wo8cBIH_RPe6ll1hNwmx1w?view

   13. Reduce unnecessary test codes
     * It's similar as above item. We have very similar YAML files for 
definitions and useless template files for tests can be reduced.

   14. Enhance NFV SOL_v3 LCM operation
     * Introduce the latest V2 APIs for LCM operation as below.
       * Scale VNF (POST /vnf_instances/{vnfInstanceId}/scale)
       * Heal VNF (POST /vnf_instances/{vnfInstanceId}/heal)
       * Modify VNF Information (PATCH /vnf_instances/{vnfInstanceId})
       * Change External VNF Connectivity (POST 
/vnf_instances/{vnfInstanceId}/change_ext_conn)

   15. Support ETSI NFV-SOL_v3 based error-handling operation
     * Introduce the latest V2 APIs for error handling operation as below.
       * Retry operation (POST /vnf_lcm_op_occs/{vnfLcmOpOccId}/retry)
       * Fail operation (POST /vnf_lcm_op_occs/{vnfLcmOpOccId}/fail)
       * Rollback operation (POST /vnf_lcm_op_occs/{vnfLcmOpOccId}/rollback)
     * Test scenario needs to include raising an error, becoming 
FAILD_TEMP, and executing the ErrorHandling API.
     * Timer adjusting and using inapporpriate vnf package can cause error.

   16. Support ChangeCurrentVNFPackage
     * Add API for ChangeCurrentVNFPackage by which blue-green 
deployment and rolling update are supported.
     * Both of VIMs, OpenStack and Kubernetes, are covered.

   17. Support heal and scale method in lcm_user_data
     * Enable to customize stack parameters for heal and scale 
operations in user script, `user_lcm_data.py` more specifically.
     * Call the proposed methods if it's existing in the script for the 
operations.

Thanks,
Yasufumi



More information about the openstack-discuss mailing list