Hi everyone, Thank you for joining to the vPTG sessions last week. We had great discussion for several topics about Tacker's next development items. Here is a summary of the discussion. ## Revise FTs We've revised functional tests for the recent cycles since maintainance costs or running time are getting large. It's a recap of the previous vPTG discussion and we agree to focus on reducing the number of tests by dropping useless ones and setup configurations. ## Enhancing Tacker Testing Coverage in the OpenStack Helm Check Pipeline A proposal for enhancing Tacker testing within the OpenStack Helm (OSH) pipeline by adding more test cases. It will use the OpenStack CLI for Tacker testing, ensuring that no modifications to the OSH test code will be needed even if Tacker's functional tests change. It's also a recap from the previous cycle and we agreed to continue the development. ## Balancing Test Execution Efficiency and Resource Consumption in Tacker Testing It's a sub task of revising functional tests. Since some of usecases in tacker are little bit complicated and several nodes are used for test such a cases. As the result, the resource consumption is higher than we expected. This proposal aims to analyze this issue and propose possible optimizations to balance resource usage and test execution efficiency. ## Tacker Strategy and Guidelines to Support Newer TST Releases and V2 API We're planning to introduce ETSI NFV standard tests called as TST for ensuring Tacker's capabilities are exactly compliant with the standards, but there is a painpoint about supporting versions. The purpose of this proposal is to outline the strategy and guidelines for updating Tacker to support newer TST releases and its v2 API so that we can define how Tacker can collaborate with the TST team to implement support for newer releases. ## Potential new usecase from vRAN feedback Discussion for a new vRAN usecase other than basic ones already implemented in Tacker as a part of cross community collaboration items between O-RAN SC and OpenStack. Tacker is expected to be SMO which is a frontend of O-Cloud infrastructure defined in the O-RAN SC reference architecture model. In a highliy distributed deployment usecase called as D-RAN (Distributed RAN), there is a concern about resource consumption because of limited num of servers is available on each edge site. K8s may not support a case of far controll node on retional site and worker nodes on edge sites. We discussed two key points and will continue the discussion: (1) Tacker manages container via Docer directly by Infra-driver? and (2) How can Tacker ensure to manage container with delay? ## PaaS Manager It's a emerging requirement for Tacker. In ETSI NFV standards, PaaS and its manager are expected as key components for containers. ETSI NFV has specified PSM (PaaS Service Management) to manage LCM of PaaS in clause 10 of ETSI GS NFV-IFA 049. However, there might be several missing point in term of implementation, such as how manages dependency between VNF and PaaS, e.g. order of start/stop, capacity of PaaS, recovery when PaaS is failure. It's also required to provide a parser for PaaS Service Descriptor (PSD). In the vPTG discussion, we agree to continue the discussion to make it clear the actual requirements for managing PSM or describing PSD, and contribute ETSI NFV specifications. ## Add option to enable/disable Cinder volume recreation in v1 Heal request A proposal for enhancing Tacker v1 APIs by enabling to cancel cincer volume is recreated while heal operation. This feature was already implemented in v2, but it's also required to implement in v1 for keeping compatibility. ## Add default_secret_key Option to [vim_keys] for Multi-Master Tacker Deployment Currently, all Tacker nodes need to share or sync the VIM keys across all nodes. Since VIM keys are randomly generated and stored only on the conductor where the VIM registration process occurs, it doesn't work if instantiate or terminate requests are performed from a different conductor, the VIM key is also required on that host. This proposal is for allowing the Tacker administrator to use a pre-generated common key eliminates the need for key sharing or syncing, making the setup simpler. We agreed to the implementation strategy and expect to merge the feature in Flamimngo. Yasufumi