.. ============LICENSE_START========================================== .. =================================================================== .. Copyright © 2018 AT&T Intellectual Property. All rights reserved. .. =================================================================== .. Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License"); .. you may not use this documentation except in compliance with the License. .. You may obtain a copy of the License at .. .. https://creativecommons.org/licenses/by/4.0/ .. .. Unless required by applicable law or agreed to in writing, software .. distributed under the License is distributed on an "AS IS" BASIS, .. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. .. See the License for the specific language governing permissions and .. limitations under the License. .. ============LICENSE_END============================================ .. _appc_cdt_guide: =================== APPC CDT User Guide =================== Introduction ============ This document is the APPC Controller Design Tool (CDT) User Guide for self-service onboarding of VNF’s. VNF owners can create templates and other artifacts for APPC Configure command (used to apply a post-instantiation configuration) as well as other life cycle commands. A complete list of all APPC supported commands is contained in the APPC LCM API Guide available on onap.readthedocs.io. Overview of APPC Support for VNF Configuration and Lifecycle Commands ====================================================================== APPC is an ONAP component that performs functions to manage the lifecycle of VNF’s and their component. The picture below summarizes the APP-C design intent. |image0| Some lifecycle commands are supported on any VNF type, such as commands executed using OpenStack or for generic REST calls such as for HealthCheck. Other commands require models called templates to be created in the APPC Controller Design Tool(CDT) by the VNF owner. Templates are needed for lifecycle commands such as for post-instantiation configuration and for passing payloads to a Chef or Ansible server. Templates contain static and instance-specific parameters in a structured language (currently limited to xml and JSON). The APPC CDT allows a VNF technology owner to identify the instance specific parameters with a unique name. At run time, the instance specific parameter values are populated in the template to replace the parameter name. |image1| |image2| |image3| Overview of the Onboarding Process ================================== Pre-Requisites for Onboarding: ------------------------------ - The VNF must support the below listed device protocols along with OpenStack for VM-level commands: - Netconf, - Chef, - Ansible, - REST - The REST protocol is used for REST interfaces to a VNF. Currently, the only action that can use REST is HealthCheck. - RESTCONF - The RESTCONF protocal is used only for VNFs that support Netconf and are able to be mounted in OpenDayLight (ODL). Use the protocal NETCONF-XML if the VNF is not ODL mountable. - In order to build the templates needed for lifecycle commands, the VNF owner will be asked to upload either an xml file (for Netconf) or a JSON file (for Chef or Ansible). This file contains the parameter values in a valid schema that would be sent to either the VNF or the Chef/Ansible server to execute the action. For more detail on Netconf, Chef, or Ansible, see the ONAP vendor guidelines at: https://wiki.onap.org/pages/viewpage.action?pageId=1015852&preview=/1015849/1017888/VNF%20Management%20Requirements%20for%20OpenECOMP.pdf - The VNF related key identifiers (vnf-type, vnfc-type, vnfc-function-code) that will be stored in A&AI have been defined. Onboarding Process Steps: ------------------------- 1. Use the APPC CDT GUI to populate **reference data** describing the VNF and action to be onboarded. - Select the VNF, action, and protocol to be on-boarded. - Describe the VM/VNFC components that comprise the VNF’s. APPC will use this VM/VNFC data to update A&AI when configuring the VNF at run time. 2. Create a **template** from a “golden” configuration file. - Upload a “golden configuration” file (described later) into the APPC CDT GUI. - Manually edit the configuration file to associate parameter names with instance-specific values you wish to parameterize (e.g., IP addresses). - This creates a template file, which will be used at run-time to create the payload that APPC sends to the VNF or to Ansible/Chef. - Alternative: If the golden configuration changes, rather than manually re-creating an updated template, you can *automatically* create an updated template by **Merging** a current parameter name-value pairs file with the new configuration file. APPC will scan the new configuration file, and automatically replace values with parameter names. 3. Create a **parameter definition** file describing instance-specific parameters in the template. - Once you have a template, use the **Synchronize Template Parameters** button to automatically create/update a parameter definition file (and a parameter name-value pair file) based on the template. - You can then populate/update the fields describing each parameter. - If the parameters will be populated from external systems (such as INSTAR), you can upload a “key file” that automatically populates key fields used to retrieve data from the external system. - If the parameters will be populated from A&AI, you can select the rules and key fields used to retrieve data from A&AI. - The parameter definition file will be used at run time to automatically obtain parameter values from external system, A&AI, or a user input spreadsheet for insertion into the template. 4. Create a **parameter name-value pair file** for those parameters. - Once you have a template, use the **Synchronize Template Parameters** button to automatically create a parameter name-value pair file (and a parameter definition file) based on the template. - The parameter name-value file serves as a guide for populating instance-specific data into the user input spreadsheet used at run time. The parameter name-value file can also be used to automatically create a template via the **Merge** function as described in step 2. - You can also use the **Synchronize With Name Values** button to update the parameter definitions to match an existing parameter name-values pair file. 5. **Test** the template in your test environment using the **TEST** function of APPC CDT - Use the **Save All to APP-C** button in the CDT GUI to save the artifacts for your VNF to APPC. This makes the current version of artifacts available to both the APPC CDT and APPC Run Time. - Prepare a “user input” excel file on your PC and upload it to the APPC CDT. - **Execute** the onboa
# ============LICENSE_START=======================================================
# Copyright (C) 2018 Ericsson. All rights reserved.
# Modifications Copyright (C) 2019-2020 AT&T Intellectual Property.
# ================================================================================
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
# SPDX-License-Identifier: Apache-2.0
# ============LICENSE_END=========================================================
#################################################################
# Global configuration defaults.
#################################################################
global:
persistence: {}
#################################################################
# Application configuration defaults.
#################################################################
# application image
repository: nexus3.onap.org:10001
image: onap/policy-distribution:2.3.1
pullPolicy: Always
# flag to enable debugging - application support required
debugEnabled: false
# application configuration
# default number of instances
replicaCount: 1
nodeSelector: {}
affinity: {}
# probe configuration parameters
liveness:
initialDelaySeconds: 20
periodSeconds: 10
# necessary to disable liveness probe when setting breakpoints
# in debugger so K8s doesn't restart unresponsive container
enabled: true
readiness:
initialDelaySeconds: 20
periodSeconds: 10
service:
type: ClusterIP
name: policy-distribution
portName: policy-distribution
externalPort: 6969
internalPort: 6969
ingress:
enabled: false
resources: {}