--- /dev/null
+{
+ "restructuredtext.confPath": "${workspaceFolder}/docs"
+}
\ No newline at end of file
intersphinx_mapping['onap-holmes-rule-management'] = ('{}/onap-holmes-rule-management/en/%s'.format(doc_url) % branch, None)
intersphinx_mapping['onap-portal'] = ('{}/onap-portal/en/%s'.format(doc_url) % branch, None)
intersphinx_mapping['onap-cli'] = ('{}/onap-cli/en/%s'.format(doc_url) % branch, None)
-intersphinx_mapping['onap-oom-certservice'] = ('{}/onap-oom-platform-cert-service/en/%s'.format(doc_url) % branch, None)
+intersphinx_mapping['onap-oom-platform-cert-service'] = ('{}/onap-oom-platform-cert-service/en/%s'.format(doc_url) % branch, None)
intersphinx_mapping['onap-ccsdk-cds'] = ('{}/onap-ccsdk-cds/en/%s'.format(doc_url) % branch, None)
intersphinx_mapping['onap-ccsdk-apps'] = ('{}/onap-ccsdk-apps/en/%s'.format(doc_url) % branch, None)
intersphinx_mapping['onap-ccsdk-oran'] = ('{}/onap-ccsdk-oran/en/%s'.format(doc_url) % branch, None)
* :ref:`SDNC - SDN Controller<onap-sdnc-oam:offeredapis>`
* :ref:`SO - Service Orchestration<onap-so:offeredapis>`
* :ref:`VFC - Virtual Function Controller<onap-vfc-nfvo-lcm:master_index>`
+* :ref:`CDS - Controller Design Studio<onap-ccsdk-cds:offeredapis>`
Common Services
---------------
+++ /dev/null
-ONAP Blueprint Enrichment
--------------------------
-
-The ONAP Beijing release includes four functional enhancements in the
-areas of manually triggered scaling, change management, and hardware
-platform awareness (HPA). These features required significant community
-collaboration as they impact multiple ONAP projects. These features are
-applicable to any use case; however, to showcase them in a concrete
-manner, they have been incorporated into VoLTE and vCPE blueprints.
-
-Manually Triggered Scaling
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Scale-out and scale-in are two primary benefits of NFV. Scaling can be
-triggered manually (e.g., by a user or OSS/BSS) or automatically via a
-policy-driven closed loop. An automatic trigger allows real-time action
-without human intervention, reducing costs and improving customer
-experience. A manual trigger, on the other hand, is useful to schedule
-capacity in anticipation of events such as holiday shopping. An ideal
-scaling operation can scale granularly at a virtual function level (VF),
-automate VF configuration tasks and manage the load-balancer that may be
-in front of the VF instances. In addition to run-time, this capability
-also affects service design, as VNF descriptors need to be granular up
-to the VF level.
-
-The Beijing release provides the initial support for these capabilities.
-The community has implemented manually triggered scale-out and scale-in
-in combination with a specific VNF manager (sVNFM) and demonstrated this
-with the VoLTE blueprint. An operator uses the Usecase UI (UUI) project
-to trigger a scaleing operation. UUI communicates with the Service
-Orchestrator (SO). SO uses the VF-C controller, which in turn instructs
-a vendor-provided sVNFM to implement the scale-out action.
-
-We have also demonstrated a manual process to Scale Out VNFs that use
-the Virtual Infrastructure Deployment (VID), the Service Orchestrator
-(SO) and the Application Controller (APPC) as a generic VNF Manager.
-Currently, the process is for the operator to trigger the Scale Out
-action using VID, which will request SO to spin up a new component of
-the VNF. Then SO is building the ConfigScaleOut request and sending to
-APPC over DMaaP, where APPC picks it up and executes the configuration
-scale out action on the requested VNF.
-
-Change Management
-~~~~~~~~~~~~~~~~~
-
-NFV will bring with it an era of continuous, incremental changes instead
-of periodic step-function software upgrades, in addition to a constant
-stream of both PNF and VNF updates and configuration changes. To
-automatically deliver these to existing network services, the ONAP
-community is creating framework to implement change management
-functionality that is independent of any particular network service or
-use case. Ideally, change management provides a consistent interface and
-mechanisms to manage complex dependencies, different upgrade mechanisms
-(in-place vs. scale-out and replace), A/B testing, conflict checking,
-pre- and post-change testing, change scheduling, rollbacks, and traffic
-draining, redirection and load-balancing. These capabilities impact both
-design-time and run-time environments.
-
-Over the next several releases, the community will enhance change
-management capabilities in ONAP, culminating with a full CI/CD flow.
-These capabilities can be applied to any use case; however, specifically
-for the Beijing release, the vCPE blueprint has been enriched to execute
-a predefined workflow to upgrade the virtual gateway VNF by using
-Ansible. An operator invokes an upgrade operation through the VID
-interface. VID drives SO, which initiates a sequence of steps such as
-VNF lock, pre-check, software upgrade, post-check and unlock. Since
-virtual gateway is an L3 VNF, the specific operations are carried out by
-the SDN-C controller in terms of running the pre-check, post-check and
-upgrade through Ansible playbooks.
-
-Hardware Platform Awareness (HPA)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Many VNFs have specific hardware requirements to achieve their
-performance and security goals. These hardware requirements may range
-from basic requirements such as number of cores, memory size, and
-ephemeral disk size to advanced requirements such as CPU policy (e.g.
-dedicate, shared), NUMA, hugepages (size and number), accelerated
-vSwitch (e.g DPDK), crypto/compression acceleration, SRIOV-NIC, TPM, SGX
-and so on. The Beijing release provides three HPA-related capabilities:
-
-1. Specification of the VNF hardware platform requirements as a set of
- policies.
-
-2. Discovery of hardware and other platform features supported by cloud
- regions.
-
-3. Selection of the right cloud region and NFV infrastructure flavor by
- matching VNF HPA requirements with the discovered platform
- capabilities.
-
-While this functionality is independent of any particular use case, in
-the Beijing release, the vCPE use case has been enriched with HPA. An
-operator can specify engineering rules for performance sensitive VNFs
-through a set of policies. During run-time, SO relies on the ONAP
-Optimization Framework (OOF) to enforce these policies via a
-placement/scheduling decision. OOF determines the right compute node
-flavors for the VNF by querying the above-defined policies. Once a
-homing decision is conveyed to SO, SO executes the appropriate workflow
-via the appropriate controller.
Introduction
============
+ONAP is a comprehensive platform for orchestration, management, and automation
+of network and edge computing services for network operators, cloud providers,
+and enterprises. Real-time, policy-driven orchestration and automation of
+physical, virtual, and cloud native network functions enables rapid automation
+of new services and complete lifecycle management critical for 5G and
+next-generation networks.
The ONAP project addresses the rising need for a common automation platform for
telecommunication, cable, and cloud service providers—and their solution
exploit SDN and NFV to improve service velocity, simplify equipment
interoperability and integration, and to reduce overall CapEx and OpEx costs.
In addition, the current, highly fragmented management landscape makes it
-difficult to monitor and guarantee service-level agreements (SLAs). These
-challenges are still very real now as ONAP creates its fourth release.
+difficult to monitor and guarantee service-level agreements (SLAs).
ONAP is addressing these challenges by developing global and massive scale
-(multi-site and multi-VIM) automation capabilities for both physical and
-virtual network elements. It facilitates service agility by supporting data
-models for rapid service and resource deployment and providing a common set of
-northbound REST APIs that are open and interoperable, and by supporting
+(multi-site and multi-VIM) automation capabilities for physical, virtual, and
+cloud native network elements. It facilitates service agility by supporting
+data models for rapid service and resource deployment and providing a common
+set of northbound REST APIs that are open and interoperable, and by supporting
model-driven interfaces to the networks. ONAP’s modular and layered nature
improves interoperability and simplifies integration, allowing it to support
-multiple VNF environments by integrating with multiple VIMs, VNFMs,
-SDN Controllers, as well as legacy equipment (PNF). ONAP’s consolidated xNF
-requirements publication enables commercial development of ONAP-compliant xNFs.
-This approach allows network and cloud operators to optimize their physical
-and virtual infrastructure for cost and performance; at the same time, ONAP’s
-use of standard models reduces integration and deployment costs of
+multiple VNF environments by integrating with multiple VIMs, VNFMs, SDN
+Controllers, as well as legacy equipment (PNF). The Service Design & Creation
+(SDC) project also offers seamless orchestration of CNFs. ONAP’s consolidated
+xNF requirements publication enables commercial development of ONAP-compliant
+xNFs. This approach allows network and cloud operators to optimize their
+physical and virtual infrastructure for cost and performance; at the same time,
+ONAP’s use of standard models reduces integration and deployment costs of
heterogeneous equipment. All this is achieved while minimizing management
fragmentation.
engineer, plan, bill and assure these dynamic services, there are three major
requirements:
-- A robust design framework that allows the specification of the service in
- all aspects – modeling the resources and relationships that make up the
- service, specifying the policy rules that guide the service behavior,
- specifying the applications, analytics and closed control loop events needed
- for the elastic management of the service
-
-- An orchestration and control framework (Service Orchestrator and Controllers
- ) that is recipe/ policy-driven to provide an automated instantiation of the
+- A robust design framework that allows the specification of the service in all
+ aspects – modeling the resources and relationships that make up the service,
+ specifying the policy rules that guide the service behavior, specifying the
+ applications, analytics and closed control loop events needed for the elastic
+ management of the service
+- An orchestration and control framework (Service Orchestrator and Controllers)
+ that is recipe/ policy-driven to provide an automated instantiation of the
service when needed and managing service demands in an elastic manner
-
- An analytic framework that closely monitors the service behavior during the
service lifecycle based on the specified design, analytics and policies to
enable response as required from the control framework, to deal with
To achieve this, ONAP decouples the details of specific services and supporting
technologies from the common information models, core orchestration platform,
and generic management engines (for discovery, provisioning, assurance etc.).
+
Furthermore, it marries the speed and style of a DevOps/NetOps approach with
-the formal models and processes operators require to introduce new services
-and technologies. It leverages cloud-native technologies including Kubernetes
-to manage and rapidly deploy the ONAP platform and related components. This is
-in stark contrast to traditional OSS/Management software platform
-architectures, which hardcoded services and technologies, and required lengthy
-software development and integration cycles to incorporate changes.
+the formal models and processes operators require to introduce new services and
+technologies. It leverages cloud-native technologies including Kubernetes to
+manage and rapidly deploy the ONAP platform and related components. This is in
+stark contrast to traditional OSS/Management software platform architectures,
+which hardcoded services and technologies, and required lengthy software
+development and integration cycles to incorporate changes.
The ONAP Platform enables service/resource independent capabilities for design,
creation and lifecycle management, in accordance with the following
foundational principles:
- Ability to dynamically introduce full service lifecycle orchestration (design
- ,provisioning and operation) and service API for new services and
+ , provisioning and operation) and service API for new services and
technologies without the need for new platform software releases or without
affecting operations for the existing services
-- Carrier-grade scalability including horizontal scaling (linear scale-out) and
- distribution to support a large number of services and large networks
+- Scalability and distribution to support a large number of services and large
+ networks
- Metadata-driven and policy-driven architecture to ensure flexible and
automated ways in which capabilities are used and delivered
- The architecture shall enable sourcing best-in-class components
designing required services.
#. External API provides northbound interoperability for the ONAP Platform and
Multi-VIM/Cloud provides cloud interoperability for the ONAP workloads.
-#. OOM provides the ability to manage cloud-native installation and
- deployments to Kubernetes-managed cloud environments.
-#. ONAP Shared Services provides shared capabilities for ONAP modules. MUSIC
- allows ONAP to scale to multi-site environments to support global scale
- infrastructure requirements. The ONAP Optimization Framework (OOF) provides
- a declarative, policy-driven approach for creating and running optimization
- applications like Homing/Placement, and Change Management Scheduling
- Optimization. Logging provides centralized logging capabilities, Audit
- (POMBA) provides capabilities to understand orchestration actions.
+#. OOM provides the ability to manage cloud-native installation and deployments
+ to Kubernetes-managed cloud environments.
+#. ONAP Shared Services provides shared capabilities for ONAP modules. The ONAP
+ Optimization Framework (OOF) provides a declarative, policy-driven approach
+ for creating and running optimization applications like Homing/Placement,
+ and Change Management Scheduling Optimization.
#. ONAP shared utilities provide utilities for the support of the ONAP
components.
#. Information Model and framework utilities continue to evolve to harmonize
the topology, workflow, and policy models from a number of SDOs including
- ETSI NFV MANO, TM Forum SID, ONF Core, OASIS TOSCA, IETF, and MEF.
+ ETSI NFV MANO, ETSI/3GPP, O-RAN, TM Forum SID, ONF Core, OASIS TOSCA, IETF,
+ and MEF.
|image2|
The ONAP deployment methodology needs to be flexible enough to suit the
different scenarios and purposes for various operator environments. Users may
also want to select a portion of the ONAP components to integrate into their
-own systems. And the platform needs to be highly reliable, scalable, secure and
-easy to manage. To achieve all these goals, ONAP is designed as a
+own systems. And the platform needs to be highly reliable, scalable, secure
+and easy to manage. To achieve all these goals, ONAP is designed as a
microservices-based system, with all components released as Docker containers
following best practice building rules to optimize their image size. To reduce
-the ONAP footprint, a first effort to use shared data base have been initiated
+the ONAP footprint, a first effort to use a shared database has been initiated
with a Cassandra and mariadb-galera clusters.
The ONAP Operations Manager (OOM) is responsible for orchestrating the
OOM supports a wide variety of cloud infrastructures to suit your individual
requirements.
-Microservices Bus (MSB) provides fundamental microservices supports including
+Microservices Bus (MSB) provides fundamental microservices support including
service registration/ discovery, external API gateway, internal API gateway,
client software development kit (SDK), and Swagger SDK. When integrating with
OOM, MSB has a Kube2MSB registrar which can grasp services information from k8s
metafile and automatically register the services for ONAP components.
In the spirit of leveraging the microservice capabilities, further steps
-towards increased modularity have been taken. Service
-Orchestrator (SO) and the controllers have increased its level of modularity.
+towards increased modularity have been taken. Service Orchestrator (SO) and the
+controllers have increased its level of modularity.
Portal
======
runtime environments, based on the user’s role. Role changes are configured
within a single ONAP instance.
-This user experience is managed by the ONAP Portal, which provides access to
-design, analytics and operational control/administration functions via a
-shared, role-based menu or dashboard. The portal architecture provides
-web-based capabilities such as application onboarding and management,
-centralized access management through the Authentication and Authorization
-Framework (AAF), and dashboards, as well as hosted application widgets.
+This user experience is managed by the ONAP
+Portal, which provides access to design, analytics and operational control/
+administration functions via a shared, role-based menu or dashboard. The portal
+architecture provides web-based capabilities such as application onboarding and
+management, centralized access management through the Authentication and
+Authorization Framework (AAF), and dashboards, as well as hosted application
+widgets.
The portal provides an SDK to enable multiple development teams to adhere to
consistent UI development requirements by taking advantage of built-in
capabilities (Services/ API/ UI controls), tools and technologies. ONAP also
provides a Command Line Interface (CLI) for operators who require it (e.g., to
-integrate with their scripting environment). ONAP SDKs enable
-operations/security, third parties (e.g., vendors and consultants), and other
-experts to continually define/redefine new collection, analytics, and policies
-(including recipes for corrective/remedial action) using the ONAP Design
-Framework Portal.
+integrate with their scripting environment). ONAP SDKs enable operations/
+security, third parties (e.g., vendors and consultants), and other experts to
+continually define/redefine new collection, analytics, and policies (including
+recipes for corrective/remedial action) using the ONAP Design Framework Portal.
Design Time Framework
=====================
-The design time framework is a comprehensive development environment with
-tools, techniques, and repositories for defining/ describing resources,
-services, and products.
+The design time framework is a comprehensive development environment with tools
+, techniques, and repositories for defining/ describing resources, services,
+and products.
The design time framework facilitates reuse of models, further improving
efficiency as more and more models become available. Resources, services,
-products, and their management and control functions can all be modeled using
-a common set of specifications and policies (e.g., rule sets) for controlling
+products, and their management and control functions can all be modeled using a
+common set of specifications and policies (e.g., rule sets) for controlling
behavior and process execution. Process specifications automatically sequence
instantiation, delivery and lifecycle management for resources, services,
products and the ONAP platform components themselves. Certain process
-specifications (i.e., ‘recipes’) and policies are geographically distributed
-to optimize performance and maximize autonomous behavior in federated cloud
+specifications (i.e., ‘recipes’) and policies are geographically distributed to
+optimize performance and maximize autonomous behavior in federated cloud
environments.
Service Design and Creation (SDC) provides tools, techniques, and repositories
to define/simulate/certify system assets as well as their associated processes
-and policies. Each asset is categorized into one of four asset groups:
-Resource, Services, Products, or Offers. SDC also supports TOSCA1.3 List type
-definition which provides the ability to design complicated
-service descriptor.
+and policies. Each asset is categorized into one of four asset groups: Resource
+, Services, Products, or Offers. SDC supports the onboarding of Network
+Services packages (ETSI SOL 0007 ), CNF packages (Helm), VNF packages (Heat or
+ETSI SOL004) and PNF packages (ETSI SOL004). SDC also includes some
+capabilities to model 5G network slicing using the standard properties (Slice
+Profile, Service Template).
The SDC environment supports diverse users via common services and utilities.
Using the design studio, product and service designers onboard/extend/retire
Kit (VNF SDK) and VNF Validation Program (VVP) components. Vendors can
integrate these tools in their CI/CD environments to package VNFs and upload
them to the validation engine. Once tested, the VNFs can be onboarded through
-SDC. In addition, the testing capability of VNFSDK is being utilized at the
-LFN Compliance Verification Program to work towards ensuring a highly
-consistent approach to VNF verification.
+SDC. In addition, the testing capability of VNFSDK is being utilized at the LFN
+Compliance Verification Program to work towards ensuring a highly consistent
+approach to VNF verification.
The Policy Creation component deals with policies; these are rules, conditions,
requirements, constraints, attributes, or needs that must be provided,
Policy allows rapid modification through easily updating rules, thus updating
technical behaviors of components in which those policies are used, without
-requiring rewrites of their software code. Policy permits simpler management
-/ control of complex mechanisms via abstraction.
+requiring rewrites of their software code. Policy permits simpler
+management / control of complex mechanisms via abstraction.
Runtime Framework
=================
The runtime execution framework executes the rules and policies and other
models distributed by the design and creation environment.
-This allows for the distribution of models and policy among
-various ONAP modules such as the Service Orchestrator (SO), Controllers,
-Data Collection, Analytics and Events (DCAE), Active and Available Inventory
-(A&AI). These components use common services that
-support logging, access control, Multi-Site State Coordination (MUSIC), which
-allow the platform to register and manage state across multi-site deployments.
+This allows for the distribution of models and policy among various ONAP
+modules such as the Service Orchestrator (SO), Controllers, Data Collection,
+Analytics and Events (DCAE), Active and Available Inventory (A&AI). These
+components use common services that support access control.
Orchestration
-------------
automating sequences of activities, tasks, rules and policies needed for
on-demand creation, modification or removal of network, application or
infrastructure services and resources, this includes VNFs, CNFs and PNFs.
-The SO provides orchestration at a very high level, with an end-to-end view of
-the infrastructure, network, and applications.
-
-One is BroadBand Service (BBS), the second one is Cross Domain and Cross Layer
-VPN (CCVPN).
+The SO provides orchestration at a very high level, with an end-to-end view
+of the infrastructure, network, and applications. Examples of this include
+BroadBand Service (BBS) and Cross Domain and Cross Layer VPN (CCVPN).
Virtual Infrastructure Deployment (VID)
---------------------------------------
service specific constraints.
ONAP Multi-VIM/Cloud (MC) and several other ONAP components such as Policy, SO,
-A&AI etc. play an important role in enabling “Policy-driven
-Performance/Security-Aware Adaptive Workload Placement/ Scheduling” across
-cloud sites through OOF-HAS. OOF-HAS uses Hardware Platform Awareness (HPA),
-cloud agnostic Intent capabilities, and real-time capacity checks provided by
-ONAP MC to determine the optimal VIM/Cloud instances, which can deliver the
-required performance SLAs, for workload (VNF etc.) placement and scheduling
-(Homing). Operators now realize the true value of virtualization through fine
-grained optimization of cloud resources while delivering performance and
-security SLAs.
+A&AI etc. play an important role in enabling “Policy-driven Performance/
+Security-Aware Adaptive Workload Placement/ Scheduling” across cloud sites
+through OOF-HAS. OOF-HAS uses Hardware Platform Awareness (HPA), cloud agnostic
+Intent capabilities, and real-time capacity checks provided by ONAP MC to
+determine the optimal VIM/Cloud instances, which can deliver the required
+performance SLAs, for workload (VNF etc.) placement and scheduling (Homing).
+Operators now realize the true value of virtualization through fine grained
+optimization of cloud resources while delivering performance and security SLAs.
Controllers
-----------
VNFM capability but also integrates with external VNFMs and VIMs as part of an
NFV MANO stack.
+The Controller Design Studio (CDS) community in ONAP has contributed a
+framework to automate the resolution of resources for instantiation and any
+config provisioning operation, such as day0, day1 or day2 configuration. The
+essential function of CDS is to create and populate a controller blueprint,
+create a configuration file from this Controller blueprint, and associate at
+design time this configuration file (configlet) to a PNF/VNF/CNF during the
+design phase. CDS removes dependence on code releases and the delays they cause
+and puts the control of services into the hands of the service providers. Users
+can change a model and its parameters with great flexibility to fetch data from
+external systems (e.g. IPAM) that is required in real deployments. This makes
+service providers more responsive to their customers and able to deliver
+products that more closely match the needs of those customers.
+
Inventory
---------
Active and Available Inventory (A&AI) provides real-time views of a system’s
Multi Cloud Adaptation
----------------------
Multi-VIM/Cloud provides and infrastructure adaptation layer for VIMs/Clouds
-in exposing advanced hardware platform awareness and cloud agnostic intent
-capabilities, besides standard capabilities, which are used by OOF and other
-components for enhanced cloud selection and SO/VF-C for cloud agnostic workload
-deployment.
+and K8s clusters in exposing advanced hardware platform awareness and cloud
+agnostic intent capabilities, besides standard capabilities, which are used by
+OOF and other components for enhanced cloud selection and SO/VF-C for cloud
+agnostic workload deployment. The K8s plugin is in charge to deploy the CNF on
+the Kubernetes clusters using Kubernetes API.
Closed Control Loop Automation
==============================
Closed loop control is provided by cooperation among a number of design-time
and run-time elements. The Runtime loop starts with data collectors from Data
-Collection, Analytics and Events (DCAE). ONAP includes the following
-collectors: VES for events, HV-VES for high-volume events, SNMP for SNMP traps,
-File Collector to receive files, and Restconf Collector to collect the
-notifications. After data collection/verification phase, data are moved through
-the loop of micro-services like Homes for event detection, Policy for
-determining actions, and finally, controllers and orchestrators to implement
-actions CLAMP is used to monitor the loops themselves. DCAE also supports
-(Platform for Network Data Analytics) PNDA analytics capabilities. CLAMP,
-Policy and DCAE all have design time aspects to support the creation of the
-loops.
+Collection, Analytics and Events (DCAE). ONAP includes the following collectors
+: VES (VNF Event Streaming) for events, HV-VES for high-volume events, SNMP
+for SNMP traps, File Collector to receive files, and RESTCONF Collector to
+collect the notifications. After data collection/verification phase, data are
+moved through the loop of micro-services like Homes for event detection, Policy
+for determining actions, and finally, controllers and orchestrators to
+implement actions CLAMP is used to monitor the loops themselves. DCAE also
+includes a number of specialized micro-services to support some use-cases such
+as the Slice Analysis or SON-Handler. Some dedicated event processor modules
+transform collected data (SNMP, 3GPP XML, RESTCONF) to VES format and push the
+various data onto data lake. CLAMP, Policy and DCAE all have design time
+aspects to support the creation of the loops.
We refer to this automation pattern as “closed control loop automation” in that
it provides the necessary automation to proactively respond to network and
Security) functionality. DCAE collects performance, usage, and configuration
data; provides computation of analytics; aids in troubleshooting; and publishes
events, data and analytics (e.g., to policy, orchestration, and the data lake).
-Another component, “Holmes”, connects to DCAE and provides alarm correlation
-for ONAP, new data collection capabilities with High Volume VES, and bulk
-performance management support.
-
Working with the Policy Framework and CLAMP, these components detect problems
in the network and identify the appropriate remediation. In some cases, the
action will be automatic, and they will notify Service Orchestrator or one of
=============
ONAP provides models to assist with service design, the development of ONAP
service components, and with the improvement of standards interoperability.
-
Models are an essential part for the design time and runtime framework
development. The ONAP modeling project leverages the experience of member
companies, standard organizations and other open source projects to produce
parser functionalities, as well as additional package management
functionalities.
-
Industry Alignment
==================
ONAP support and collaboration with other standards and open source communities
- Further collaboration includes 5G/ORAN & 3GPP Harmonization, Acumos DCAE
Integration, and CNCF Telecom User Group (TUG).
-Read this whitepaper for more information: The Progress of ONAP: Harmonizing
-Open Source and Standards.
+Read this whitepaper for more information:
+`The Progress of ONAP: Harmonizing Open Source and Standards <https://www.onap.org/wp-content/uploads/sites/20/2019/04/ONAP_HarmonizingOpenSourceStandards_032719.pdf>`_
ONAP Blueprints
===============
ONAP can support an unlimited number of use cases, within reason. However, to
provide concrete examples of how to use ONAP to solve real-world problems, the
-community has created a set of blueprints. In addition to helping users
-rapidly adopt the ONAP platform through end-to-end solutions, these blueprints
-also help the community prioritize their work. With the ONAP Frankfurt release,
-we introduced a new blueprint in the area of optical transport networking
-called Multi-Domain Optical Network Service (MDONS). Prior blueprints were
-vCPE, VoLTE, vFW/vDNS, 5G, and CCVPN. 5G and CCVPN underwent feature
-enhancements during the Frankfurt release.
+community has created a set of blueprints. In addition to helping users rapidly
+adopt the ONAP platform through end-to-end solutions, these blueprints also
+help the community prioritize their work.
5G Blueprint
------------
Virtual CPE (vCPE)
..................
-Currently, services offered to a subscriber are restricted to what is
-designed into the broadband residential gateway. In the blueprint, the customer
-has a slimmed down physical CPE (pCPE) attached to a traditional broadband
-network such as DSL, DOCSIS, or PON (Figure 5). A tunnel is established to a
-data center hosting various VNFs providing a much larger set of services to the
+Currently, services offered to a subscriber are restricted to what is designed
+into the broadband residential gateway. In the blueprint, the customer has a
+slimmed down physical CPE (pCPE) attached to a traditional broadband network
+such as DSL, DOCSIS, or PON (Figure 5). A tunnel is established to a data
+center hosting various VNFs providing a much larger set of services to the
subscriber at a significantly lower cost to the operator. In this blueprint,
ONAP supports complex orchestration and management of open source VNFs and both
virtual and underlay connectivity.
Broadband Service (BBS)
.......................
-This blueprint provides multi-gigabit residential
-internet connectivity services based on PON (Passive Optical Network) access
-technology. A key element of this blueprint is to show automatic
-re-registration of an ONT (Optical Network Terminal) once the subscriber moves
-(nomadic ONT) as well as service subscription plan changes. This blueprint uses
-ONAP for the design, deployment, lifecycle management, and service assurance of
-broadband services. It further shows how ONAP can orchestrate services across
-different locations (e.g. Central Office, Core) and technology domains (e.g.
-Access, Edge).
+This blueprint provides multi-gigabit residential internet connectivity
+services based on PON (Passive Optical Network) access technology. A key
+element of this blueprint is to show automatic re-registration of an ONT
+(Optical Network Terminal) once the subscriber moves (nomadic ONT) as well as
+service subscription plan changes. This blueprint uses ONAP for the design,
+deployment, lifecycle management, and service assurance of broadband services.
+It further shows how ONAP can orchestrate services across different locations
+(e.g. Central Office, Core) and technology domains (e.g. Access, Edge).
|image6|
Voice over LTE (VoLTE) Blueprint
--------------------------------
This blueprint uses ONAP to orchestrate a Voice over LTE service. The VoLTE
-blueprint incorporates commercial VNFs to create and manage the underlying vEPC
-and vIMS services by interworking with vendor-specific components, including
-VNFMs, EMSs, VIMs and SDN controllers, across Edge Data Centers and a Core Data
-Center. ONAP supports the VoLTE use case with several key components: SO, VF-C,
-SDN-C, and Multi-VIM/ Cloud. In this blueprint, SO is responsible for VoLTE
-end-to-end service orchestration working in collaboration with VF-C and SDN-C.
-SDN-C establishes network connectivity, then the VF-C component completes the
-Network Services and VNF lifecycle management (including service initiation,
-termination and manual scaling) and FCAPS (fault, configuration, accounting,
-performance, security) management. This blueprint also shows advanced
-functionality such as scaling and change management.
+blueprint incorporates commercial VNFs to create and manage the underlying
+vEPC and vIMS services by interworking with vendor-specific components,
+including VNFMs, EMSs, VIMs and SDN controllers, across Edge Data Centers and
+a Core Data Center. ONAP supports the VoLTE use case with several key
+components: SO, VF-C, SDN-C, and Multi-VIM/ Cloud. In this blueprint, SO is
+responsible for VoLTE end-to-end service orchestration working in collaboration
+with VF-C and SDN-C. SDN-C establishes network connectivity, then the VF-C
+component completes the Network Services and VNF lifecycle management
+(including service initiation, termination and manual scaling) and FCAPS
+(fault, configuration, accounting, performance, security) management. This
+blueprint also shows advanced functionality such as scaling and change
+management.
|image7|
Read the `VoLTE Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_112918FNL.pdf>`_
to learn more.
-
Optical Transport Networking (OTN)
----------------------------------
Two ONAP blueprints (CCVPN and MDONS) address the OTN use case. CCVPN addresses
Layers 2 and 3, while MDONS addresses Layers 0 and 1.
CCVPN (Cross Domain and Cross Layer VPN) Blueprint
---------------------------------------------------
+..................................................
CSPs, such as CMCC and Vodafone, see a strong demand for high-bandwidth, flat,
high-speed OTN (Optical Transport Networks) across carrier networks. They also
want to provide a high-speed, flexible and intelligent service for high-value
across CSPs uses an east-west API which is being aligned with the MEF Interlude
API. The key innovations in this use case are physical network discovery and
modeling, cross-domain orchestration across multiple physical networks, cross
-operator end-to-end service provisioning, close-loop reroute for
-cross-domain service, dynamic changes (branch sites, VNFs) and intelligent
-service optimization (including AI/ML). The Frankfurt release adds support for
-end-to-end E-LINE services over optical transport network (OTN)
-network-to-network interface (NNI).
+operator end-to-end service provisioning, close-loop reroute for cross-domain
+service, dynamic changes (branch sites, VNFs) and intelligent service
+optimization (including AI/ML).
Read the `CCVPN Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_CCVPN_062519.pdf>`_
to learn more.
MDONS (Multi-Domain Optical Network Service) Blueprint
-------------------------------------------------------
+......................................................
While CCVPN addresses the automation of networking layers 2 and 3, it does not
address layers 0 and 1. Automating these layers is equally important because
providing an end-to-end service to their customers often requires a manual and
onboarding, network service creation, service deployment and closed-loop
automation. The key components involved are SDC, CLAMP, SO, APP-C, DCAE and
Policy. In the recent releases, the vFW blueprint has been demonstrated by
-using a mix of a CNF and VNF and entirely using CNFs.
+using a mix of a CNF and VNF and entirely using CNFs.
Verified end to end tests
=========================
Use cases
---------
-Various use cases have been tested for the Release. Detailed information can
-be found in :ref:`Verified Use Cases<onap-integration:docs_usecases>`.
-
-- vFirewall with closed loop
-- vFirewall/vDNS with HPA
-- vFirewall In-Place Software Upgrade with Traffic Distribution
-- vFirewall CNF With CDS
-- Scale Out
-- CCVPN-E LINE over OTN NNI
-- CCVPN - MDONS
-- BBS (Broadband Service)
-- vFirewall CNF with multicloud k8s plugin
-- EdgeXFoundry CNF with multicloud k8s plugin
-- vCPE with Tosca
-- E2E Automation vLB with CDS
+Various use cases have been tested for the Release. Use case examples are
+listed below. See detailed information on use cases, functional requirements,
+and automated use cases can be found here:
+:ref:`Verified Use Cases<onap-integration:docs_usecases_release>`.
+
+- E2E Network Slicing
+- 5G OOF (ONAP Optimization Framework) SON (Self-Organized Network)
+- CCVPN-Transport Slicing
+- MDONS (Multi-Domain Optical Network Service)
Functional requirements
-----------------------
-Various functional requirements have been tested for the Release. Detailed
-information can be found in
-:ref:`Verified Use Cases<onap-integration:docs_usecases>`.
-
-- PNF Software Upgrade using direct Netconf Yang interface with PNF
-- PNF Software Upgrade with EM with Ansible
-- PNF Software Upgrade with EM with Netconf
-- VSP Compliance and Validation Check within SDC
-- Enable PNF software version at onboarding
-- xNF communication security enhancements
-- ETSI Alignment SO plugin to support SOL003 to connect to an external VNFM
-- Integration of CDS as an Actor
-- 3rd Party Operational Domain Manager
-- Configuration & persistency
-- 5G functional requirements
-
- - 5G Realtime PM and High Volume Stream Data Collection
- - 5G PNF Plug and Play
- - 5G Bulk PM
- - 5G OOF and PCI
- - 5G NRM Network Resource Model (Configuration management)
- - 5G NETCONF configuration
- - 5G PNF Pre-Onboarding & Onboarding
- - 5G OOF SON
- - 5G E2E Network Slicing
- - 5G ORAN A1 Adapter (SDNR)
+Various functional requirements have been tested for the Release. Detailed
+information can be found in the
+:ref:`Verified Use Cases<onap-integration:docs_usecases_release>`.
+
+- xNF Integration
+
+ - ONAP CNF orchestration - Enhancements
+ - PNF PreOnboarding
+ - PNF Plug & Play
+
+- Lifecycle Management
+
+ - Policy Based Filtering
+ - Bulk PM / PM Data Control Extension
+ - Support xNF Software Upgrade in association to schema updates
+ - Configuration & Persistency Service
+
+- Security
+
+ - CMPv2 Enhancements
+
+- Standard alignment
+
+ - ETSI-Alignment for Guilin
+ - ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES
+ - Extend ORAN A1 Adapter and add A1 Policy Management
+
+- NFV testing Automatic Platform
+
+ - Support for Test Result Auto Analysis & Certification
+ - Support for Test Task Auto Execution
+ - Support for Test Environment Auto Deploy
+ - Support for Test Topology Auto Design
Conclusion
==========
-The ONAP platform provides a comprehensive platform for real-time,
-policy-driven orchestration and automation of physical and virtual network
-functions that will enable software, network, IT and cloud providers and
-developers to rapidly automate new services and support complete lifecycle
-management.
+The ONAP platform provides a comprehensive platform for real-time, policy-
+driven orchestration and automation of physical and virtual network functions
+that will enable software, network, IT and cloud providers and developers to
+rapidly automate new services and support complete lifecycle management.
By unifying member resources, ONAP will accelerate the development of a vibrant
ecosystem around a globally shared architecture and implementation for network
* - Document
- Description
- * - :ref:`AAF<onap-aaf-authz:master_index>`
+ * - (in Maintenance) `AAF (Frankfurt) <https://docs.onap.org/projects/onap-aaf-authz/en/frankfurt/>`_
- AAF Architecture, APIs and Guides
- * - :ref:`Secret Management Service<onap-aaf-sms:master_index>`
- - Secret Management Service Architecture and API
AAI - Active and Available Inventory
------------------------------------
- Description
* - :ref:`AAI<onap-aai-aai-common:master_index>`
- AAI Architecture, APIs and Guides
- * - :ref:`ESR<onap-aai-esr-gui:master_index>`
- - External System Registry GUI Documentation (to be removed ?)
- * - :ref:`ESR<onap-aai-esr-server:master_index>`
- - External System Registry Server Documentation (to be removed ?)
- * - :ref:`AAI Inventory UI<onap-aai-sparky-be:master_index>`
- - Sparky - AAI Inventory UI Documentation (to be removed ?)
- * - :ref:`AAI Event Client<onap-aai-event-client:master_index>`
- - AAI Event Client Documentation (to be removed ?)
+ * - (in Maintenance) `ESR GUI (Latest) <https://docs.onap.org/projects/onap-aai-esr-gui/en/latest/>`_
+ - External System Registry GUI Documentation
+ * - (in Maintenance) `ESR Server (Latest) <https://docs.onap.org/projects/onap-aai-esr-server/en/latest/>`_
+ - External System Registry Server Documentation
+ * - (in Maintenance) :ref:`AAI UI<onap-aai-sparky-be:master_index>`
+ - Sparky - AAI Inventory UI Documentation
APPC - Application Controller
-----------------------------
* - Document
- Description
- * - :ref:`APPC<onap-appc:master_index>`
+ * - (in Maintenance) `APPC (Frankfurt) <https://docs.onap.org/projects/onap-appc/en/frankfurt/>`_
- APPC Architecture, APIs and Guides
- * - :ref:`APPC Deployment<onap-appc-deployment:master_index>`
+ * - (in Maintenance) `APPC Deployment (Frankfurt) <https://docs.onap.org/projects/onap-appc-deployment/en/frankfurt/>`_
- APPC Deployment Documentation
CCSDK - Common Controller Software Development Kit
- Description
* - :ref:`Distribution<onap-ccsdk-distribution:master_index>`
- TOSCA Orchestration Plugin, Directed Graph Support
- * - :ref:`Dashboard<onap-ccsdk-dashboard:master_index>`
- - Common Controller Dashboard (To be removed ?)
- * - :ref:`Platform Plugins<onap-ccsdk-platform-plugins:master_index>`
- - Platform Plugins (To be removed ?)
- * - :ref:`APPS<onap-ccsdk-apps:master_index>`
- - Apps optside ODL (To be removed ?)
CDS - Controller Design Studio
------------------------------
- Description
* - :ref:`Bus Controller<onap-dmaap-buscontroller:master_index>`
- Bus Controller Documentation
- * - :ref:`Bus Controller API<onap-dmaap-dbcapi:master_index>`
- - Bus Controller API Documentation
* - :ref:`Data Router<onap-dmaap-datarouter:master_index>`
- Data Router Documentation
* - :ref:`Message Router<onap-dmaap-messagerouter-messageservice:master_index>`
* - Document
- Description
- * - :ref:`Logging<onap-logging-analytics:master_index>`
- - ONAP Centralized Logging Documentation (to be deleted ?)
+ * - (in Maintenance) `LOGGING (Latest) <https://docs.onap.org/projects/onap-logging-analytics/en/latest/>`_
+ - ONAP Centralized Logging Documentation
MSB - Microservices Bus
-----------------------
* - Document
- Description
- * - :ref:`MUSIC<onap-music:master_index>`
- - MUSIC Architecture and Guides (To be deleted ?)
- * - :ref:`Distributed KV Store<onap-music:master_index>`
- - MUSIC Distribute KV Store Documents (To be deleted ?)
+ * - (in Maintenance) `MUSIC (Frankfurt) <https://docs.onap.org/projects/onap-music/en/frankfurt/>`_
+ - MUSIC Architecture and Guides
+ * - (in Maintenance) `MUSIC KV (Latest) <https://docs.onap.org/projects/onap-music-distributed-kv-store/en/latest/>`_
+ - MUSIC Distribute KV Store Documents
OOF - Optimization Framework
----------------------------
- Description
* - :ref:`OOM<onap-oom:master_index>`
- ONAP Operations Manager Documentation
- * - :ref:`OOM Certification Service<onap-oom-certservice:master_index>`
+ * - :ref:`OOM Certification Service<onap-oom-platform-cert-service:master_index>`
- ONAP CMPv2 certification support
ORAN - Open-RAN Support in ONAP
* - Document
- Description
- * - :ref:`SDCN<onap-sdnc-oam:master_index>`
+ * - :ref:`SDNC<onap-sdnc-oam:master_index>`
- SDNC Architecture, APIs and Guides
SDNR - Software Defined Network Controller for Radio
* - Document
- Description
- * - :ref:`SDNR<onap-ccsdk-features:master_index>`
+ * - :ref:`SDN-R<onap-ccsdk-features:master_index>`
- SDN-R Documentation (part of CCSDK)
SO - Service Orchestration
- Description
* - :ref:`SO<onap-so:master_index>`
- Service Orchestration Architecture, APIs and Guides
- * - :ref:`SO Libraries<onap-so-libs:master_index>`
- - Service Orchestration Build (To be deleted ?)
UUI - Use Case User Interface
-----------------------------
Converting to RST
=================
-RST format is used for documentation. Other file formats can be converted to RST
-with pandoc.
+RST format is used for documentation. Other file formats can be converted to
+RST with pandoc.
.. caution::
:code:`-f` tells pandoc the input format. It should be one of the following:
-+--------------------+---------------------------------------------------------------+
-| Format | Description |
-+====================+===============================================================+
-|commonmark | Markdown variant |
-+--------------------+---------------------------------------------------------------+
-|docbook | XML-based markup |
-+--------------------+---------------------------------------------------------------+
-|docx | Microsoft Word |
-+--------------------+---------------------------------------------------------------+
-|epub | Ebook format |
-+--------------------+---------------------------------------------------------------+
-|haddock | Doc format produced by tool used on Haskell code |
-+--------------------+---------------------------------------------------------------+
-|html | HTML |
-+--------------------+---------------------------------------------------------------+
-|json | JSON pandoc AST |
-+--------------------+---------------------------------------------------------------+
-|latex | Older typesetting syntax |
-+--------------------+---------------------------------------------------------------+
-|markdown | Simple formatting syntax meant to produce HTML |
-+--------------------+---------------------------------------------------------------+
-|markdown_github | Github flavored markdown |
-+--------------------+---------------------------------------------------------------+
-|markdown_mmd | Multi-markdown flavored markdown |
-+--------------------+---------------------------------------------------------------+
-|markdown_phpextra | PHP flavored markdown |
-+--------------------+---------------------------------------------------------------+
-|markdown_strict | Markdown with no added pandoc features |
-+--------------------+---------------------------------------------------------------+
-|mediawiki | Popular wiki language |
-+--------------------+---------------------------------------------------------------+
-|native | Pandoc native Haskell |
-+--------------------+---------------------------------------------------------------+
-|odt | Open document text (used by LibreOffice) |
-+--------------------+---------------------------------------------------------------+
-|opml | Outline processor markup language |
-+--------------------+---------------------------------------------------------------+
-|org | Org mode for Emacs |
-+--------------------+---------------------------------------------------------------+
-|rst | reStructuredText |
-+--------------------+---------------------------------------------------------------+
-|t2t | Wiki-like formatting syntax |
-+--------------------+---------------------------------------------------------------+
-|textile | A formatting syntax similar to RST and markdown |
-+--------------------+---------------------------------------------------------------+
-|twiki | Popular wiki formatting syntax |
-+--------------------+---------------------------------------------------------------+
++--------------------+----------------------------------------------------+
+| Format | Description |
++====================+====================================================+
+|commonmark | Markdown variant |
++--------------------+----------------------------------------------------+
+|docbook | XML-based markup |
++--------------------+----------------------------------------------------+
+|docx | Microsoft Word |
++--------------------+----------------------------------------------------+
+|epub | Ebook format |
++--------------------+----------------------------------------------------+
+|haddock | Doc format produced by tool used on Haskell code |
++--------------------+----------------------------------------------------+
+|html | HTML |
++--------------------+----------------------------------------------------+
+|json | JSON pandoc AST |
++--------------------+----------------------------------------------------+
+|latex | Older typesetting syntax |
++--------------------+----------------------------------------------------+
+|markdown | Simple formatting syntax meant to produce HTML |
++--------------------+----------------------------------------------------+
+|markdown_github | Github flavored markdown |
++--------------------+----------------------------------------------------+
+|markdown_mmd | Multi-markdown flavored markdown |
++--------------------+----------------------------------------------------+
+|markdown_phpextra | PHP flavored markdown |
++--------------------+----------------------------------------------------+
+|markdown_strict | Markdown with no added pandoc features |
++--------------------+----------------------------------------------------+
+|mediawiki | Popular wiki language |
++--------------------+----------------------------------------------------+
+|native | Pandoc native Haskell |
++--------------------+----------------------------------------------------+
+|odt | Open document text (used by LibreOffice) |
++--------------------+----------------------------------------------------+
+|opml | Outline processor markup language |
++--------------------+----------------------------------------------------+
+|org | Org mode for Emacs |
++--------------------+----------------------------------------------------+
+|rst | reStructuredText |
++--------------------+----------------------------------------------------+
+|t2t | Wiki-like formatting syntax |
++--------------------+----------------------------------------------------+
+|textile | A formatting syntax similar to RST and markdown |
++--------------------+----------------------------------------------------+
+|twiki | Popular wiki formatting syntax |
++--------------------+----------------------------------------------------+
Fixing the converted document
-----------------------------
Web-based
~~~~~~~~~
-`rst.ninjs.org <http://rst.ninjs.org>`_ has an excellent RST previewing
-tool that highlights RST errors with line numbers.
+`Online Sphinx editor <https://livesphinx.herokuapp.com/>`_ is a RST previewing
+tool.
:maxdepth: 2
introduction
- setting-up-environment
setting-up
+ setting-up-environment
style-guide
api-swagger-guide
+ templates
converting-to-rst
addendum
repositories. Other ONAP projects will provide content that
is referenced from this structure.
-::
-
-docs
-├── guides
-│ ├── active-projects
-│ ├── onap-developer
-│ │ ├── apiref
-│ │ ├── architecture
-│ │ │ └── media
-│ │ ├── developing
-│ │ ├── how-to-use-docs
-│ │ ├── tutorials
-│ │ └── use-cases
-│ ├── onap-operator
-│ │ ├── cloud_site
-│ │ │ ├── aws
-│ │ │ ├── azure
-│ │ │ ├── k8s
-│ │ │ ├── openstack
-│ │ │ └── vmware
-│ │ ├── onap-portal-admin
-│ │ │ └── attachments
-│ │ └── settingup
-│ ├── onap-provider
-│ ├── onap-user
-│ │ ├── configure
-│ │ │ ├── change_config
-│ │ │ ├── pnf_connect
-│ │ │ └── vnf_connect
-│ │ ├── design
-│ │ │ ├── control-loop
-│ │ │ │ └── media
-│ │ │ ├── media
-│ │ │ ├── parameter_resolution
-│ │ │ │ └── ubuntu_example
-│ │ │ │ ├── cba-after-enrichment
-│ │ │ │ │ ├── Definitions
-│ │ │ │ │ ├── Templates
-│ │ │ │ │ └── TOSCA-Metadata
-│ │ │ │ ├── cba-before-enrichment
-│ │ │ │ │ ├── Definitions
-│ │ │ │ │ ├── Templates
-│ │ │ │ │ └── TOSCA-Metadata
-│ │ │ │ └── ubuntuCDS_heat
-│ │ │ ├── pre-onboarding
-│ │ │ │ └── media
-│ │ │ ├── resource-onboarding
-│ │ │ │ └── media
-│ │ │ ├── service-design
-│ │ │ │ └── media
-│ │ │ ├── service-distribution
-│ │ │ │ └── media
-│ │ │ └── vfcreation
-│ │ │ └── media
-│ │ ├── instantiate
-│ │ │ ├── instantiation
-│ │ │ │ ├── nbi
-│ │ │ │ ├── pnf_instance
-│ │ │ │ ├── service_instance
-│ │ │ │ ├── so1
-│ │ │ │ ├── so2
-│ │ │ │ ├── uui
-│ │ │ │ ├── vid
-│ │ │ │ ├── virtual_link_instance
-│ │ │ │ └── vnf_instance
-│ │ │ └── pre_instantiation
-│ │ └── onap-portal-user
-│ │ └── attachments
-│ └── overview
-│ └── media
-├── release
-├── templates
-│ ├── collections
-│ └── sections
-└── use-cases
+.. code-block::
+
+ docs
+ ├── guides
+ │ ├── onap-developer
+ │ │ ├── apiref
+ │ │ ├── architecture
+ │ │ │ └── media
+ │ │ ├── developing
+ │ │ └── how-to-use-docs
+ | | | ├── templates
+ │ | | | ├── collections
+ │ | | | └── sections
+ │ ├── onap-operator
+ │ │ ├── cloud_site
+ │ │ │ ├── aws
+ │ │ │ ├── azure
+ │ │ │ ├── k8s
+ │ │ │ ├── openstack
+ │ │ │ └── vmware
+ │ │ ├── onap-portal-admin
+ │ │ │ └── attachments
+ │ │ └── settingup
+ │ ├── onap-provider
+ │ ├── onap-user
+ │ │ ├── configure
+ │ │ │ ├── change_config
+ │ │ │ ├── pnf_connect
+ │ │ │ └── vnf_connect
+ │ │ ├── design
+ │ │ │ ├── control-loop
+ │ │ │ │ └── media
+ │ │ │ ├── media
+ │ │ │ ├── parameter_resolution
+ │ │ │ │ └── ubuntu_example
+ │ │ │ │ ├── cba-after-enrichment
+ │ │ │ │ │ ├── Definitions
+ │ │ │ │ │ ├── Templates
+ │ │ │ │ │ └── TOSCA-Metadata
+ │ │ │ │ ├── cba-before-enrichment
+ │ │ │ │ │ ├── Definitions
+ │ │ │ │ │ ├── Templates
+ │ │ │ │ │ └── TOSCA-Metadata
+ │ │ │ │ └── ubuntuCDS_heat
+ │ │ │ ├── pre-onboarding
+ │ │ │ │ └── media
+ │ │ │ ├── resource-onboarding
+ │ │ │ │ └── media
+ │ │ │ ├── service-design
+ │ │ │ │ └── media
+ │ │ │ ├── service-distribution
+ │ │ │ │ └── media
+ │ │ │ └── vfcreation
+ │ │ │ └── media
+ │ │ ├── instantiate
+ │ │ │ ├── instantiation
+ │ │ │ │ ├── nbi
+ │ │ │ │ ├── pnf_instance
+ │ │ │ │ ├── service_instance
+ │ │ │ │ ├── so1
+ │ │ │ │ ├── so2
+ │ │ │ │ ├── uui
+ │ │ │ │ ├── vid
+ │ │ │ │ ├── virtual_link_instance
+ │ │ │ │ └── vnf_instance
+ │ │ │ └── pre_instantiation
+ │ │ └── onap-portal-user
+ │ │ └── attachments
+ │ └── overview
+ │ └── media
+ └── release
Source Files
For example, a collection for a platform component, an SDK, etc.
You can: browse the template *collections* and *sections* below;
-show source to look at the Restructured Text and Sphinx directives used;
-copy the source either from a browser window or by downloading the
-file in raw form from
-the `gerrit doc repository <https://gerrit.onap.org/r/gitweb?p=doc.git;a=tree;f=docs/templates;/>`_ and
-then add them to your repository docs folder and index.rst.
-
+show source to look at the Restructured Text and Sphinx directives used.
Sections
++++++++
-
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|Sections |Description |
-+======================================================================================================================+======================================================================================================================================================================================================+
-|`Administration <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/administration.rst>`_ | This section is used to describe a software component from the perspective of on-going operation including regular processes and actions that are taken to configure and manage the component. |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`Architecture <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/architecture.rst>`_ | This section is used to describe a software component from a high level view of capability, common usage scenarios, and interactions with other components required in the usage scenarios. |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`Build <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/build.rst>`_ | This section is used to describe how a software component is built from source into something ready for use either in a run-time environment or to build other components. |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`Configuration <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/configuration.rst>`_ | This section is used to describe the options a software component offers for configuration. |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`Consumed APIs <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/consumedapis.rst>`_ | This section is used to reference APIs that a software component depends on and uses from other sources. |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`Delivery <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/delivery.rst>`_ | This section is used to describe a software component packaging. For a run-time component this might be executable images, containers, etc. For an SDK this might be libraries. |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`Design <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/design.rst>`_ | This section is used to describe the internal design structure of a software component. |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`Human interfaces <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/humaninterfaces.rst>`_ |This section is used to describe a software component's command line and graphical user interfaces. |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`Installation <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/installation.rst>`_ | This section is used to describe how a software component is acquired and installed. |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`Logging <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/logging.rst>`_ | This section is used to describe the informational or diagnostic messages emitted from a software component and the methods or collecting them. |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`Offered APIs <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/offeredapis.rst>`_ | This section is used to describe the external interfaces offered by a software component |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`Release notes <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/release-notes.rst>`_ | The release note needs to be updated for each ONAP release |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`VNF reference <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/sections/vnf-reference.rst>`_ | This section is used to describe Virtual Network Function software |
-| | |
-+----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+Section examples are available here: :ref:`Templates<templates>`
Collections
+++++++++++
directives/extensions to automatically generate restructured text
from other source you already have.
-+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------+
-|Collections |Description |
-+==============================================================================================================================+============================================================+
-|`Platform component <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/collections/platform-component.rst>`_ | This collection is used to describe a platform component. |
-+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------+
-|`SDK <https://gerrit.onap.org/r/gitweb?p=doc.git;a=blob;f=docs/templates/collections/sdk.rst>`_ | This collection is used to describe an SDK. |
-+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------+
+Collection examples are available here: :ref:`Templates<templates>`
Links and References
--------------------
+ Examples: an MSO component, a LAN, an L3-VPN
-ONAP terms
-^^^^^^^^^^
+ONAP terminology
+^^^^^^^^^^^^^^^^
- AA&I vs AAI: AAI should be used.
- APP-C vs APPC: APPC should be used.
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. Copyright 2020 ONAP community
+
+.. _templates:
+
+Templates
+=========
+
+This section provides templates for the projects
+
+Sections
+--------
+
+.. toctree::
+ :maxdepth: 1
+
+ templates/collections/platform-component.rst
+ templates/collections/sdk.rst
+
+Release notes
+-------------
+.. toctree::
+ :maxdepth: 1
+
+ templates/sections/release-notes.rst
../sections/offeredapis.rst
../sections/consumedapis.rst
../sections/delivery.rst
+ ../sections/design.rst
../sections/logging.rst
../sections/installation.rst
../sections/configuration.rst
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0
-.. International License.
-
-Tutorials
-=========
-
-.. note::
- This is an empty document as placeholder for future tutorials.
-
-
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-
-Use Cases
-=========
-
-Example uses case descriptions and sequence diagrams illustrating
-interactions between platform components.
-
-.. toctree::
- :maxdepth: 1
-
- vfw.rst
- volte.rst
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-
-vFirewall Use Case
-==================
-
-Description
------------
-
-Onboarding
-----------
-
-
-.. uml::
-
- @startuml
- title vFW/vFWCL and vDNS VNF Onboarding (R1)\nVFW/vFWCL and vDNS use the same flows but they are separate VNFs/Services
- ONAP_User -> SDC : vFW_vDNS resource onboarding (HEAT)
- note right : vFWCL (vpg & vfw,vsn)\nvFW (vpg, vfw, vsn)\nvDNS (vpg, vlb,vdns) + DNSScaling (vdns)\
- ONAP_User -> SDC : vFW_vDNS service onboarding
- ONAP_User -> SDC : vFW_vDNS distribution
- |||
- SDC -> SO : artifact distribution\nNOTIFY,DOWNLOAD,DEPLOY_OK
- SDC -> AAI : artifact distribution\nNOTIFY,DOWNLOAD,DEPLOY_OK
- SDC -> SDNC : artifact distribution\nNOTIFY,DOWNLOAD,DEPLOY_OK
- @enduml
-
-Instantiation
--------------
-
-.. uml::
-
- @startuml
- title vFW vDNS Instantiation (R1)\nvFW and vDNS use the same flows but they are separate VNFs/Services
- participant ONAP_User
- participant Robot
- Participant SDC
- Participant VID
- Participant SO
- ONAP_User -> AAI : populate cloud inventory
- note left of AAI: manual via curl or POSTMAN
- |||
- ONAP_User -> VID : vFW_vDNS deployment
- VID -> SDC : Lookup VNF artifacts
- VID -> AAI : Lookup cloud locations, subscriber
- VID -> SO : vFW_vDNS Service \nInstantiation\n(base modules)
- SO -> AAI : inventory update
- VID -> SO : vFW_vDNS VNF Instantiation\n(base modules)
- note left of AAI : VFWCL is two VNFs in one service\nso VNF instantiate occurs twice
- SO -> AAI : inventory update
- ONAP_User -> SDNC : VNF API Preload VNF/VF data
- VID -> SO : vFW_vDNS VF Instantiation\n(base modules)
- SO -> AAI : inventory update
- SO -> SDNC : Generic VNF API\n(assign)
- SO -> Multi_VIM : vFW_vDNS Heat template, \nENV file, preload parameters
- Multi_VIM -> CloudAPI : vFW_vDNS Heat template,\nENV file, preload parameters or
- CloudAPI -> Hypervisor : vFW_vDNS Infrastructure instantiation
- Hypervisor -> vFW_vDNS : Nova/Neutron Instantiation
- Hypervisor -> CloudAPI : complete
- CloudAPI -> Multi_VIM : complete
- Multi_VIM -> SO : complete
- note right : SO may poll for completion
- SO -> SDNC: Generic VNF API\n(activated)
- note left : on failure from Openstack SO issues rollback to SDNC
- SDNC -> AAI : L3 Network resource update
- SO -> VID : complete
- note right : VID will poll for completion
- ONAP_User -> Robot : run Heat Bridge
- Robot -> CloudAPI : retrieve cloud data
- Robot -> AAI : Update with cloud data
- |||
- @enduml
-
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. Copyright ONAP Community
+
|image2017-10-27_15-56-53.png|
ONAP Portal for Administrators
Access the ONAP Portal using Mozilla Firefox or Google Chrome(win/mac)
at the provided URL. For example: `https://<hostname:port>/ONAPPORTAL/login.html`.
-:ref:`Access the ONAP portal via the 8989 LoadBalancer documented `here<onap-oom:onap-on-kubernetes-with-rancher>`
+Access the ONAP portal via the 8989 LoadBalancer documented
+:ref:` here<onap-oom:onap-on-kubernetes-with-rancher>`
From the Portal, users access applications directly or by function using
the `Manage menu`.
From the ONAP Portal, administrators:
-- access the same functionality accessible to users (see `ONAP Portal
- for users <onap-#PAGE_1018759>`__)
+- access the same functionality accessible to users
+ (see :ref:`ONAP Portal for users<onap_portal_users>`)
- manage users and application admins
Left menu descriptions:
-.. _PAGE_1018764:
-
Admins Menu
-----------
The goal of the design process is to create all artifacts (models)
that are required to instantiate and manage resources, services,
-and products on the ONAP platform. The design process requires
-input from users with multiple roles.
+and products on the ONAP platform.
Design progresses logically through a series of phases. Each phase:
* is organized into steps that are completed in sequence
-* is accessed using a different role with specific responsibilities
- generates artifacts that are used in other phases of design or when
- instantiating or monitoring virtual functions.
+* generates artifacts that are used in other phases of design
+
+* is performed by multiple Design components
The following figure show the different phases and tools involved in
Onboarding, Design and Distribution process.
(b) manual creation and import of artefacts created via external
tools like the Controller Design Studio (CDS), responsible for the
Controller Blueprint Design
- The created VF will pass a testing workflow to be used
- in a Service Model
+ The created VF Model will be used in a Service Model
**Service Design**
A Service Model is created as a composition of resources
(e.g. V(N)Fs, PNFs,...), Policies, Workflows,...
- The created Service Model will ber certified and handed over to
+ The created Service Model will be certified and handed over to
the Service Distribution process
**Service Distribution**
The objective is to automate the resolution of resources for instantiation
and any config provisioning operation, such as day0, day1 or day2
configuration.
- The Controller Blueprint archive (CBA) is the overall service design,
- fully model-driven, intent based package needed to design self service
+ The Controller Blueprint archive (CBA) is a fully model-driven,
+ intent based package needed to design self service
provisioning and configuration management automation.
ONAP CDS (Controller Design Studio) is the controller that will process
the Controller Blueprint archive (CBA) at run-time.
**VNF LifeCycle Command templating**
APPC Controller Design Tool (CDT) is used for self-service onboarding of
- VNF’s. VNF owners can create templates and other artifacts for APPC
+ VNFs. 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.
modify workflows to support Service/Resource change management scenarios
executed by the Service Orchestrator.
-**Control Loop Design**
- This phase includes the Design of a closed loop template and associate it
- to a Service. The template represents the theoretical flow of the CL.
- It generates a deployment artifact that can be ingested by the DCAE in
- order to create the needed DCAE microservices in runtime.
- The design is done in the SDC DCAE-DS (Design Studio).
- The DCAE Design Studio enables to define and configure
- the monitoring flows of DCAE.
- The configuration and deployment of a Control Loop will be done with
- Control Loop Automation Management (CLAMP) tool.
+**DCAE Onboard/Design**
+ This phase includes the Onboarding of DCAE Microservices and their
+ Policy Models, the Service Assurance Design and Distribution to Policy
+ and CLAMP for Closed Loop Automation Management.
+ The DCAE Onboard/Design component contains an own Design Catalog, which is
+ not yet integrated with the SDC Design Catalog to exchange models and
+ artefacts.
-The follwing sections will focus on the different Design steps:
+The following sections focus on the different Design steps:
.. toctree::
:maxdepth: 1
:titlesonly:
Pre-Onboarding <./pre-onboarding/index.rst>
-
Resource-Onboarding <./resource-onboarding/index.rst>
-
VF Creation and Testing <./vfcreation/index.rst>
-
Service Design <./service-design/index.rst>
-
Service Distribution <./service-distribution/index.rst>
-
VNF parameter resolution Design <./parameter_resolution/index.rst>
+ Control Loop Design <./control-loop/index.rst>
-:ref:`Policy Design<onap-policy-parent:design-label>`
-
-:ref:`VNF LifeCycle Command templating<onap-appc:master_index>`
-
-:ref:`Workflow Design<onap-sdc:workflow>`
-
-:ref:`Control Loop Design<onap-sdc:dcaedesigner>`
-
-:ref:`Control Loop Automation Management<onap-clamp:master_index>`
-
+The following section provide links to the projects:
+- :ref:`Policy Design<onap-policy-parent:design-label>`
+- :ref:`VNF LifeCycle Command templating<onap-appc:master_index>`
+- :ref:`Workflow Design<onap-sdc:workflow>`
+- :ref:`DCAE Onboard/Design<onap-dcaegen2:master_index>`
+- :ref:`Control Loop Automation Management<onap-clamp:master_index>`
.. |image1| image:: media/Design-Overview.png
.. _generate-manifest.py: https://git.onap.org/sdc/tree/openecomp-be/tools/scripts/generate-manifest.py
-.. _example-packages: https://git.onap.org/sdc/tree/test-apis-ci/sdc-api-tests/chef-repo/cookbooks/sdc-api-tests/files/default/Files
+.. _example-packages: https://git.onap.org/sdc/tree/integration-tests/src/test/resources/Files/VNFs
|image0|
**Steps**
- * `Create a License Model`_
- * `Create a License Key Group [Optional]`_
- * `Create an Entitlement Pool`_
- * `Create a Feature Group`_
- * `Create a License Agreement`_
+ * `Create a License Model [Optional]`_
+ * `Create a License Key Group [Optional]`_
+ * `Create an Entitlement Pool`_
+ * `Create a Feature Group`_
+ * `Create a License Agreement`_
* `Create a Vendor Software Product`_
* `Update VFCs in a VSP [optional]`_
* `Update a VSP [optional]`_
.. _doc_guide_user_des_res-onb_cre-lic:
-Create a License Model
-----------------------
+Create a License Model [Optional]
+---------------------------------
VSPs optionally require a license and entitlements to enable the service
provider to track the usage.
-Note: For interim saving while creating the license model and its components,
-click |image2|
+.. note::
+ For interim saving while creating the license model and its components, click |image2|
**Prerequisites:** To obtain license information, contact the service
provider's Supply Chain Management (SCM) group.
-#. From the SDC HOME page, click *ONBOARD*.
+#. From the SDC HOME page, navigate to the ONBOARD Tab.
|image11|
#. Complete all fields.
#. Click *Create*.
-#. In the Overview Dialog.
+#. After creation of the VLM, you should be presented with the “Overview” tab of the VLM.
|image13|
|image14|
-#. Click *Submit* to add the license model to the catalog.
-After filling a comment, press *Commit&Submit*.
+#. Click *Submit* to add the license model to the catalog.After filling a comment, press *Commit&Submit*.
|image15|
If required by the resource model, create one or more license key groups;
otherwise the license key group is optional.
-**Prerequisites:** `Create a License Model`_
+**Prerequisites:** `Create a License Model [Optional]`_
#. Select the License Model in the Onboard section of the SDC.
-#. In the Overview click the + behind the *License Key Groups*.
+#. In the Overview click the + inside the License Key Groups OR Navigate to License Key Groups and click on “+ ADD LICENSE KEY GROUP”
|image4|
`Create a License Key Group [Optional]`_).
#. Select the License Model in the Onboard section of the SDC.
-#. In the Overview click the + behind the *Entitlement Pools*.
+#. In the Overview click the + sign inside the Entitlement Pools OR Navigate to Entitlement Pools and click on “+ ADD ENTITLEMENT POOL”
|image5|
* entitlement pools (see `Create an Entitlement Pool`_)
#. Select the License Model in the Onboard section of the SDC.
-#. In the Overview click the + behind the *Feature Groups*.
+#. In the Overview click the + sign inside the Feature Groups OR Navigate to Feature Groups and click on “+ ADD FEATURE GROUP”
|image6|
#. On the General tab, complete all fields.
-#. Click *Entitlement Pools*.
-#. Click *Available Entitlement Pools*.
-#. Select one or more entitlement pools and click the right arrow.
-#. Click *License Key Groups*.
-#. Click *Available License Key Groups*.
-#. Select one or more license key groups and click the right arrow.
+#. Navigate to the *Entitlement Pools*. Tab
+ * In the Available Entitlement Pools, select one or more entitlement pools and click on the “>” sign.
+ * Selected pools should now be seen under the Selected Entitlements Pools.
+#. Navigate to the *License Key Groups*. Tab
+ * In the Available License Key Groups, select one or more license key groups and click on the “>” sign.
+ * Selected pools should now be seen under the Selected License Key Groups.
#. Click *Save*.
Create a License Agreement
(see `Create a Feature Group`_).
#. Select the License Model in the Onboard section of the SDC.
-#. In the Overview click the + behind the *License Agreements*.
+#. In the Overview click the + sign inside the License Agreements OR Navigate to License Agreements and click on “+ Add FEATURE GROUP”
|image7|
#. On the General tab, complete required fields.
#. Click *Feature Groups*.
-#. If not selected, click *Available Feature Groups*.
-#. Select one or more groups and click the right arrow.
+#. If not selected, click Available *Feature Groups*.
+ * Select one or more groups in the Available Feature Groups, select one or more feature groups and click on the “>” sign.
+ * Selected feature groups should now be seen under the Selected Feature Groups.
#. Click *Save*.
-#. Return to step 6 of `Create a License Model`_ to complete the license model.
+#. Return to step 6 of `Create a License Model [Optional]`_ to complete the license model.
.. _doc_guide_user_des_res-onb_cre-vsp:
**Prerequisites:**
-* `Create a License Model`_
+* `Create a License Model [Optional]`_
* VNF HEAT package or VNF/PNF CSAR/Zip package is available.
See :ref:`sdc_onboarding_package_types` for a description
of the onboarding package types.
* If the package is a secure package then :ref:`pre-install the corresponding Root Certificate in SDC <doc_guide_user_des_res-onb_pre-install_root_certificate>`.
+.. note::
+ Example packages can be found in the SDC project: :ref:`SDC Packages<onap-sdc:sdc_onboarding_package_types>`
+
#. From the SDC HOME page, click *ONBOARD*.
|image11|
|image24|
-#. Press the Button *Procees to Validation*. After successful validation, SDC
+#. Press the Button *Proceed to Validation*. After successful validation, SDC
displays the files and a success message. If validation fails, SDC displays
the errors in the files.
|image24|
-#. Press the Button *Procees to Validation*. After successful validation, SDC
+#. Press the Button *Proceed to Validation*. After successful validation, SDC
displays the files and a success message. If validation fails, SDC displays
the errors in the files.
.. |image25| image:: media/sdro-vsp-version.png
-.. |image26| image:: media/sdro-vsp-version-dialog.png
\ No newline at end of file
+.. |image26| image:: media/sdro-vsp-version-dialog.png
**Goal:** Add models and other artifacts required to create, configure,
instantiate, and manage services. Validate and certify the services.
+Besides the manual creation of a Service Model, an existing model can
+be imported via a CSAR file
**Tool:** SDC
#. `Create Service`_
#. `Create a Management Workflow [optional]`_
#. `Create a Network Callflow [optional]`_
- #. `Add Service Inputs [optional]`_
+ #. `Manage Service Properties [optional]`_
#. `Update Service [optional]`_
#. `Certify Service`_
+ #. `Import Service CSAR [optional]`_
.. _doc_guide_user_des_ser-cre_serv:
action)
- **Management Workflow** model service lifecycle workflows for execution
in SO (see `Create a Management Workflow [optional]`_)
- - **Network Call Flow** model interactions among VFs (see `Create a
- Network Callflow [optional]`_)
+ - **Network Call Flow** model interactions among VFs (see
+ `Create a Network Callflow [optional]`_)
- **Deployment** view HEAT modules in VSPs
- **Properties Assignment** define or update properties,
- policies and input parameters used during Service instantiation
- (see `Add Service Inputs [optional]`_).
+ policies and input parameters used during Service instantiation.
- **Monitoring** ...
#. Click *Check In* to save changes.
.. _doc_guide_user_des_ser-para_in:
-Add Service Inputs [optional]
------------------------------
+Manage Service Properties [optional]
+------------------------------------
-Select parameters as input fields during Service instantiation.
+Add new Service parameters and define as input fields
+during Service instantiation.
**Prerequisites:** `Create service`_
#. [Optional] Click *Network Callflow* to edit the interactions among VFs
that comprise the service (see `Create a Network Callflow [optional]`_).
#. [Optional] Click *Properties Assignement* to select parameters as
- input fields during Service instantiation
- (see `Add Service Inputs [optional]`_).
+ input fields during Service instantiation.
#. Click *Check In* to save changes.
#. After updating a service and configuring optional fields, certify it
(see `Certify Service`_).
#. A Message appears, that the Service is certified.
+Import Service CSAR [optional]
+------------------------------
+
+Note: This step can be used, when a Service Model already exists
+
+**Steps**
+
+#. From the SDC HOME page, hover over IMPORT and select *IMPORT SERVICE CSAR*.
+
+ |image0|
+
+#. In the File Upload Dialog, select the csar file and press *Open*.
+
+ |image10|
+
+#. In the General section, complete all fields.
+
+ |image11|
+
+#. Click Create.
+
+ A message displays when Service creation is complete.
+
+#. Continue with Service Design steps mentioned above
+
.. |image0| image:: media/sdc-home.png
.. |image1| image:: media/sdc-service-workflow.png
.. |image2| image:: media/design_asdccanvas_connect_elements.png
.. |image6| image:: media/sdc-service-composition.png
.. |image7| image:: media/sdc-service-workflow.png
.. |image8| image:: media/sdc-service-properties.png
-.. |image9| image:: media/sdc-service-properties-input.png
\ No newline at end of file
+.. |image9| image:: media/sdc-service-properties-input.png
+.. |image10| image:: media/sdc-service-import.png
+.. |image11| image:: media/sdc-service-general-import.png
- `Distribute Service`_
- `Monitor Distribution`_
-- `Verify that the DCAE Blueprint is Deployed`_
-
.. _doc_guide_user_des_ser-dis-start:
**Steps**
-#. Sign in to SDC as Developer.
+#. Sign in to SDC as Designer.
#. From the SDC HOME page, click CATALOG and search for the service.
+ It should read *Waiting For Distribution*.
#. Select the service that is *Ready for Distribution*.
|image2|
**Steps**
-#. Sign in to SDC as Developer.
+#. Sign in to SDC as Designer.
#. From the SDC HOME page, click CATALOG and search for the service.
#. Select the service that is in *Distributed* state.
#. Click *Distribution* in the left pane.
#. If deploy errors are shown, the reason has to be investigated and the
Service can be *Redistributed*
-.. _doc_guide_user_des_ser-dis-dcae:
-
-Verify that the DCAE Blueprint is Deployed
-------------------------------------------
-
-The DCAE controller requires a blueprint (or guideline) to be available
-at the site on which the first VNF is deployed. This blueprint is a
-management workflow and configuration description for a given VNF, and
-it must be available after completing the service distribution process
-and before beginning the instantiation process.
.. |image1| image:: media/sdc-service-distribution-workflow.png
.. |image2| image:: media/sdc-service-distribute.png
**Steps**
-#. From the SDC HOME page, click the *Import VSP*
+#. From the SDC HOME page, hover over *Import*, then click on *IMPORT VSP*
|image2|
**Steps**
-#. From the SDC HOME page, click the *ADD VF* or *ADD PNF*
+#. From the SDC HOME page, hover over *Add*, then click on *ADD VF* or *ADD PNF*.
|image2|
**Steps**
-#. From the SDC HOME page, click *CATALOG* and search for the VF/PNF.
+#. From the SDC HOME page, click *CATALOG* and search for the VF/PNF, click on selected VF/PNF to update.
#. In the General section, click *Check Out*.
The *VSP* field is displays.
|image4|
#. Click *Update VSP*
- A progress bar displays.|image5|
+ A progress bar displays.
+ |image5|
#. Click *Deployment Artifact* to edit, upload, or delete associated [Optional]
deployment artifacts.
**Steps**
#. When a VF/PNF is ready for certification,
- click *CATALOG* and search for the checked-in VF/PNF.
+ On the SDC HOME page, click *CATALOG* and search for the checked-in VF/PNF.
+ Bottom half of the VN/PNF will say “In Design Check In”.
+
#. Click the VF/PNF and click *Certify*.
|image7|
In the following page you find all use cases and functional requirements
which have been officially verified in the actual release by the ONAP community.
-* :ref:`Verified Use Cases<onap-integration:docs_usecases>`
+* :ref:`Guilin Use Cases<onap-integration:docs_usecases_release>`
+* :ref:`Deprecated Use Cases<onap-integration:docs_usecases>`
\ No newline at end of file
Pre-instantiation operations <./pre_instantiation/index.rst>
Instantiation operation(s) <./instantiation/index.rst>
+
+ Instantiation via Use-Case UI portal <./instantiation/uui/index.rst>
.. International License. http://creativecommons.org/licenses/by/4.0
.. Copyright 2019 ONAP Contributors. All rights reserved.
-
Declare PNF instances:
.. toctree::
Instantiate a Service <./service_instance/index.rst>
-
Instantiate a VNF:
.. toctree::
Instantiate a VNF <./vnf_instance/index.rst>
-Configure a VNF:
-
-.. toctree::
- :maxdepth: 1
-
- Configure a VNF <./vnf_configure/index.rst>
-
-
Instantiate a Virtual Link:
.. toctree::
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. ONAP community
+.. _onap_portal_users:
+
|image2017-10-27_15-56-53.png|
ONAP Portal for Users
The Portal SDK for application developers includes bundled tools,
technologies, and built-in capabilities such as services, APIs, and UI
controls. Existing applications can migrate to the Portal with the
-provided APIs and libraries. :ref:`ONAP Portal SDK Documentation<onap-portal:master_index>`
+provided APIs and libraries.
+:ref:`ONAP Portal SDK Documentation<onap-portal:master_index>`
Access
------
Access the ONAP Portal using Mozilla Firefox or Google Chrome(win/mac)
at the provided URL. For example: `https://<hostname:port>/ONAPPORTAL/login.html`.
-:ref:`Access the ONAP portal via the 8989 LoadBalancer <onap-oom:onap-on-kubernetes-with-rancher>`
+:ref:`Access the ONAP portal via the 8989 LoadBalancer
+<onap-oom:onap-on-kubernetes-with-rancher>`
From the Portal, users access applications directly or by function using
the `Manage menu`.
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-
-
-ONAP Portal
-===========
-The ONAP Portal integrates different ONAP applications in one place.
-The Portal platform provides common management services and
-connectivity, while the applications run separately.
-
-From the Portal, users access applications. Administrators
-onboard and manage applications and widgets, and manage user access.
-
-The Portal SDK for application developers includes bundled tools,
-technologies, and built-in capabilities such as services, APIs,
-and UI controls. Existing applications can migrate to the Portal
-with the provided APIs and libraries.
-See Portal SDK_.
-
-:ref:`docs tutorials portal-sdk <onap-portal:master_index>`
-
-Access the ONAP Portal
-----------------------
-
-Access the ONAP Portal using a browser such as Mozilla Firefox or
-Google Chrome. The URL is dependent on a specific ONAP platform
-deployment.
-
-From the Portal, users access applications directly or by
-function using the Manage menu.
-
-.. figure:: onap-portal-home.png
- :width: 900 px
- :height: 600 px
-
-
-Roles in the ONAP Portal
-------------------------
-The Portal displays different menus for the following roles:
-
-* User
-
-* Portal Administrator
-
-* Application Administrator
-
-* Governor
-
-* Operator
-
-Each application also defines a distinct set of user roles.
-See Users.
-
-See also
---------
-
-* `Applications in the Portal <https://wiki.onap.org/x/h4sP>`_
the example of onboarding and instantiating a virtual network function
(VNF), the virtual Firewall (vFirewall). Following the guidelines and
steps of this example, any other VNF can be similarly onboarded
- and instantiated to ONAP. See :ref:`virtual Firewall Onboarding and
- Instantiating <vfirewall_usecase>` examples.
+ and instantiated to ONAP.
e. Controllers applying configuration on VNFs
+----------------------+----------------+----------------------+-----------------------------------------------------------+
|Release Name |Release version |Release Date |Features delivered |
+======================+================+======================+===========================================================+
-|Frankfurt |6.0.0 | 11 June 2020 | :ref:`Frankfurt Release Notes<release-notes>` |
+|Guilin |7.0.0 | 3 Deember 2020 | |
++----------------------+----------------+----------------------+-----------------------------------------------------------+
+|Frankfurt |6.0.0 | 11 June 2020 | |
+----------------------+----------------+----------------------+-----------------------------------------------------------+
|El Alto |5.0.1 | 24 October 2019 | |
+----------------------+----------------+----------------------+-----------------------------------------------------------+
+---------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------+
| Main documentation areas | Description |
+=================================================================================+===============================================================================================+
- | :ref:`Release Notes <release-notes>` | The Release Notes besides providing the basic information on the main release, also |
+ | :ref:`Release Notes <onap-release-notes>` | The Release Notes besides providing the basic information on the main release, also |
| | presents link to the release information of each, specific ONAP component. |
+---------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------+
| :ref:`ONAP Overview <overview>` | ONAP Overview provides generic and high-level guidance on the mission and main |
.. _doc_release_notes:
+:orphan:
+
Release Notes
=============
International License. http://creativecommons.org/licenses/by/4.0
-.. _release-notes:
+.. _onap-release-notes:
-Frankfurt Release Notes
-^^^^^^^^^^^^^^^^^^^^^^^
+Guilin Release Notes
+^^^^^^^^^^^^^^^^^^^^
-This page provides the release notes for the ONAP Frankfurt release. This
+This page provides the release notes for the ONAP Guilin release. This
includes details of software versions, known limitations, and outstanding
trouble reports.
Details on the specific items delivered in each release by each component is
maintained in the component specific release notes.
-Frankfurt Releases
-==================
+Guilin Releases
+===============
-The following releases are available for Frankfurt:
- - `Frankfurt Major Release 6.0.0`_
- - `Frankfurt Maintenance Release 6.0.1`_
+The following releases are available for Guilin:
+ - `Guilin Major Release 7.0.0`_
-Frankfurt Maintenance Release 6.0.1
-===================================
+Guilin Major Release 7.0.0
+==========================
Release data
============
| **Project** | Open Network Automation Platform |
| | (ONAP) |
+--------------------------------------+--------------------------------------+
-| **Release name** | Frankfurt |
+| **Release name** | Guilin |
| | |
+--------------------------------------+--------------------------------------+
-| **Release version** | 6.0.1 |
+| **Release version** | 7.0.0 |
| | |
+--------------------------------------+--------------------------------------+
-| **Release date** | August 17th 2020 |
+| **Release date** | December 3rd 2020 |
| | |
+--------------------------------------+--------------------------------------+
-Frankfurt Maintenance Release 6.0.1 delivered a number of fixes and updates
-across the following projects:
+Guilin Features
+===============
+ONAP Guilin focusses on:
+
+* 5G network automation and services such as network slicing through RAN, core
+ and transport
+* deepening O-RAN Software Community integration along with other leading SDOs
+* seamless orchestration of CNFs, VNFs and PNFs
+* and bringing several new ONAP Blueprint and docs updates.
+
+5G Network Slicing
+------------------
+In the industry evolution toward 5G networks, Guilin expands upon the
+end-to-end network slicing introduced with Frankfurt with the addition of RAN,
+core, and transport through Network Slice Subnet Management Function (NSSMF)
+which completes functionality with the Communication Service Management
+Function (CSMF) and Network Slice Management Function (NSMF) components. In
+addition to the NSSMF included in Guilin, ONAP supports an external RAN NSSMF.
+Next, the RAN domain also has initial support for a simple closed control loop
+and machine learning (ML) for intelligent slicing.
+
+ONAP/O-RAN Alignment
+--------------------
+The release also marks greater ONAP + O-RAN Software Community harmonization by
+adding support for the A1 interface (O-RAN A1-AP v1.1), adding to the existing
+O1 support. ONAP can now manage multiple A1 targets with different versions and
+includes a A1 Policy Management Service that interacts with the Near Real-Time
+RIC\19s policy instances and provides a transient cache for these policies.
+
+CNF, VNF and PNF integration
+----------------------------
+Guilin contains a large number of new features classified into design time,
+run time, and ONAP operations to optimize the self-serve control loop and
+dashboard, make it easier to reuse existing models, make xNF pre-onboarding and
+onboarding easier, speed up UI development, and more. For Documentation
+(Usability), ONAP documentation made improvements such as setting up ONAP,
+Platform Operations, Service Design and Deployment, and User Guides. Specific
+to cloud native, The Service Design & Creation (SDC) project, the unified
+design time tool, now supports Helm types to natively support Cloud Native
+Network Functions (CNF).
+
+Enhancements in ONAP Blueprints
+-------------------------------
+Other enhancements to the ONAP Blueprints includes a new Standard Defined VNF
+Event Stream (VES) event for Fault Management (FM) / Performance Management
+(PM) Data Collection, the first use of Machine Learning in Self-Organizing
+Networks (SON), and greater support for 5G RAN Wireless Network Resource Model
+(NRM) with Service Modeling and Definition and Intent Based Network supporting
+intent-drive 5G slice creation. The Cross Domain and Cross Layer VPN (CC-VPN)
+includes transport slicing and the MDONS (Multi-Domain Optical Network Service
+) has been extended.
+
+Functional Requirements
+-----------------------
+The following requirements have been introduced in the Guilin Release:
+
+xNF Integration
+...............
+
+- ONAP CNF orchestration - Enhancements
+- Extension of PNF Pre-onboarding/onboarding
+- Enhancements for PNF Plug & Play'
+- xNF License Management
+
+Lifecycle Management
+....................
+
+- Policy Based Filtering
+- CLAMP Deployment of Native policies
+- Bulk PM / PM Data Control Extension
+- Support xNF Software Upgrade in association to schema updates
+- Configuration & Persistency Service
+
+Security
+........
+
+- CMPv2 Enhancements
+
+Standard alignment
+..................
+
+- ETSI-Alignment for Guilin
+- ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES
+- Extend ORAN A1 Adapter and add A1 Policy Management
+
+NFV testing Automatic Platform
+...............................
+
+- Test Result Auto Analysis & Certification
+- Test Task Auto Execution
+- Test Environment Auto Deploy
+- Test Topology Auto Design
+
+Non-Functional Requirements
+---------------------------
+The following 'non-functional' requirements have been introduced in the Guilin
+Release:
+
+Best Practice
+.............
+
+- ONAP shall use STDOUT for logs collection
+- IPv4/IPv6 dual stack support in ONAP (Guilin)
+- Containers must crash properly when a failure occurs
+- Containers must have no more than one main process
+- Application config should be fully prepared before starting the
+ application container
+- No root (superuser) access to database from application container
+
+Code Quality
+............
+
+- Each ONAP project shall improve its CII Badging score by improving input
+ validation and documenting it in their CII Badging site
+- Each ONAP project shall define code coverage improvements and achieve at
+ least 55% code coverage
+
+Security
+........
+
+- ONAP must complete update of the Python language (from 2.7 -> 3.8)
+- ONAP must complete update of the java language (from v8 -> v11)
+- All containers must run as non-root user
+- Continue hardcoded passwords removal
+- Flow management must be activated for ONAP.
+- Each project will update the vulnerable direct dependencies in their code
+ base
+
+Tests
+.....
+
+- More tests integrated in CI/CD but enhancements expected in Honolulu
+- ONAP shall increase the number of Docker Benchmark tests
+
+Others
+......
+
+- ONAP to support Multi - tenancy
-- AAF
-- OOM
-- CCSDK
-- CLAMP
-- DCAEGEN2
-- Integration
-- POLICY
-- SDC
-- SO
-- TEST
+.. important::
+ Some non-functional requirements are not fully finalized. Please, check details
+ on the :ref:`Integration<onap-integration:release_non_functional_requirements>`
-Details on the specific Jira tickets addressed by each project can be found in
-the component specific Release Notes. Link can be found below in section
-`Project Specific Release Notes`_.
-
-Frankfurt Major Release 6.0.0
-=============================
-
-Release data
-============
-
-+--------------------------------------+--------------------------------------+
-| **Project** | Open Network Automation Platform |
-| | (ONAP) |
-+--------------------------------------+--------------------------------------+
-| **Release name** | Frankfurt |
-| | |
-+--------------------------------------+--------------------------------------+
-| **Release version** | 6.0.0 |
-| | |
-+--------------------------------------+--------------------------------------+
-| **Release date** | June 11th 2020 |
-| | |
-+--------------------------------------+--------------------------------------+
Project Specific Release Notes
==============================
Documentation
=============
-ONAP Frankfurt Release provides a set selection of documents,
-see `ONAP Documentation <https://docs.onap.org/en/frankfurt/index.html>`_.
+ONAP Guilin Release provides a set selection of documents,
+see `ONAP Documentation <https://docs.onap.org/en/guilin/index.html>`_.
The `developer wiki <http://wiki.onap.org>`_ remains a good source of
information on meeting plans and notes from committees, project teams and
- `Badging Requirements <https://github.com/coreinfrastructure/best-practices-badge>`_
- `Badging Status for all ONAP projects <https://bestpractices.coreinfrastructure.org/en/projects?q=onap>`_
+In the Guilin release,
+
+- 100% projects passed 90% of the CII badge
+- 85% projects passed the CII badge
+- 11% projects passed the CII Silver badge
+
Project specific details are in the :ref:`release notes<doc-releaserepos>` for
each project.
ONAP Maturity Testing Notes
===========================
-For the Frankfurt release, ONAP continues to improve in multiple areas of
+For the Guilin release, ONAP continues to improve in multiple areas of
Scalability, Security, Stability and Performance (S3P) metrics.
-The Integration team ran the 72 hours stability testing (100% passing rate)
-and full resilience testing (99.4% passing rate) at ONAP OpenLabs. More details
-in :ref:`ONAP Maturity Testing Notes <integration-s3p>`
+In Guilin the Integration team focussed in
+
+- Automating ONAP Testing to improve the overall quality
+- Adding security and E2E tests
+- Integrated new ONAP Python SDK in E2E testing
+
+More details in :ref:`ONAP Integration Project<onap-integration:master_index>`
Known Issues and Limitations
============================
.. _doc-releaserepos:
+:orphan:
+
Project Specific Release Notes
++++++++++++++++++++++++++++++
.. toctree::
:maxdepth: 1
-| :ref:`Active and Available Inventory<onap-aai-aai-common:release_notes>`
-| :ref:`Application Authorization Framework<onap-aaf-authz:release_notes>`
-| :ref:`Application Controller<onap-appc:release_notes>`
-| :ref:`Common Controller Software Development Kit<onap-ccsdk-distribution:release_notes>`
-| :ref:`Closed Loop Automation Platform<onap-clamp:release_notes>`
-| :ref:`Data Collection Analysis and Events<onap-dcaegen2:release_notes>`
-| :ref:`DMAAP Message Router (MR)<onap-dmaap-messagerouter-messageservice:release_notes>`
-| :ref:`DMAAP Dmaap Data Router (DR)<onap-dmaap-datarouter:release_notes>`
-| :ref:`DMAAP Dmaap Bus Controller (BC)<onap-dmaap-buscontroller:release_notes>`
-| :ref:`Documentation<doc_release_notes>`
-| :ref:`External API NorthBound Interface<onap-externalapi-nbi:release_notes>`
| :ref:`Integration<onap-integration:release_notes>`
-| :ref:`Modeling etsicatalog<onap-modeling-etsicatalog:release_notes>`
-| :ref:`Micro Services Bus<onap-msb-apigateway:release_notes>`
-| :ref:`Music<onap-music:release_notes>`
-| :ref:`MultiVIM Cloud <onap-multicloud-framework:master_index>`
-| :ref:`ONAP Operations Manager<onap-oom:release_notes>`
-| :ref:`Optimization Framework<onap-optf-osdf:release_notes>`
-| :ref:`Policy Framework<onap-policy-parent:release_notes>`
-| :ref:`Portal Platform<onap-portal:release_notes>`
-| :ref:`Service Design & Creation<onap-sdc:release_notes>`
-| :ref:`Service Orchestration<onap-so:release_notes>`
-| :ref:`Software Defined Network Controller<onap-sdnc-oam:release_notes>`
-| :ref:`Use Case User Interface<onap-usecase-ui:release_notes>`
-| :ref:`Virtual Function Controller<onap-vfc-nfvo-lcm:release_notes>`
-| :ref:`Virtual Infrastructure Deployment<onap-vid:release_notes>`
+| :ref:`Model Specification<onap-modeling-modelspec:release_notes>`
| :ref:`VNF Requirements<onap-vnfrqts-requirements:release_notes>`
-| :ref:`VNF Software Development Kit<onap-vnfsdk-model:release_notes>`
-| :ref:`VNF Validation Project<onap-vvp-documentation:release_notes>`
+| :ref:`AAI - Active and Available Inventory<onap-aai-aai-common:release_notes>`
+| :ref:`CCSDK - Common Controller Software Development Kit<onap-ccsdk-distribution:release_notes>`
+| :ref:`CLAMP - Control Loop Automation Platform<onap-clamp:release_notes>`
+| :ref:`CLI - Command Line Interface<onap-cli:release_notes>`
+| :ref:`DCAE - Data Collection Analysis and Events<onap-dcaegen2:release_notes>`
+| :ref:`DMAAP - Message Router (MR)<onap-dmaap-messagerouter-messageservice:release_notes>`
+| :ref:`DMAAP - Data Router (DR)<onap-dmaap-datarouter:release_notes>`
+| :ref:`DMAAP - Bus Controller (BC)<onap-dmaap-buscontroller:release_notes>`
+| :ref:`DOC - Documentation<doc_release_notes>`
+| :ref:`EXTAPI - External API NorthBound Interface<onap-externalapi-nbi:release_notes>`
+| :ref:`HOLMES - Rule Management<onap-holmes-rule-management:release_notes>`
+| :ref:`MODELING - Modeling ETSI catalog<onap-modeling-etsicatalog:release_notes>`
+| :ref:`MULTICLOUD - MultiCloud Framework<onap-multicloud-framework:release_notes>`
+| :ref:`OOF - Optimization Framework<onap-optf-osdf:release_notes>`
+| :ref:`OOM - ONAP Operations Manager<onap-oom:release_notes>`
+| :ref:`OOM - Certification Service<onap-oom-platform-cert-service:release_notes>`
+| :ref:`POLICY- Policy Framework<onap-policy-parent:release_notes>`
+| :ref:`PORTAL - Portal Platform<onap-portal:release_notes>`
+| :ref:`SDC - Service Design & Creation<onap-sdc:release_notes>`
+| :ref:`SDNC - Software Defined Network Controller<onap-sdnc-oam:release_notes>`
+| :ref:`SO - Service Orchestration<onap-so:release_notes>`
+| :ref:`UUI - Use Case User Interface<onap-usecase-ui:release_notes>`
+| :ref:`VFC - Virtual Function Controller<onap-vfc-nfvo-lcm:release_notes>`
+| :ref:`VID - Virtual Infrastructure Deployment<onap-vid:release_notes>`
+| :ref:`VNFSDK - VNF Software Development Kit<onap-vnfsdk-model:release_notes>`
+| :ref:`VVP - VNF Validation Project<onap-vvp-documentation:release_notes>`
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0
-.. International License. http://creativecommons.org/licenses/by/4.0
-.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-
-Contributing Submodule Summary
-==============================
-
-.. code-block:: console
-
-.. literalinclude:: _static/smsummary.out
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-VNF
-===
-
-.. note::
- * This section is used to describe Virtual Network Function software
-
- * This section is typically provided: as additional detail on use cases,
- to illustrate end to end platform architecture, and to describe
- compliance with ONAP VNF requirements.
-
- * The VNF Heading above should be replaced with the VNF NAME
-
- * This note must be removed after content has been added.
-
-Version
--------
-
-User Documentation
-------------------
-
-Source
-------
-
-ONAP VNF Requirements Compliance
---------------------------------
-
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-
-ONAP Use Cases
-==============
-
-Example uses case descriptions and sequence diagrams illustrating
-interactions between platform components.
-
-.. toctree::
- :maxdepth: 1
-
- vfw.rst
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-
-.. _vfirewall_usecase:
-
-vFirewall
-=========
-
-Description
------------
-
-Onboarding
-----------
-
-.. uml::
-
- @startuml
- title vFW/vFWCL and vDNS VNF Onboarding (R1)\nVFW/vFWCL and vDNS use the same flows but they are separate VNFs/Services
- ONAP_User -> SDC : vFW_vDNS resource onboarding (HEAT)
- note right : vFWCL (vpg & vfw,vsn)\nvFW (vpg, vfw, vsn)\nvDNS (vpg, vlb,vdns) + DNSScaling (vdns)\
- ONAP_User -> SDC : vFW_vDNS service onboarding
- ONAP_User -> SDC : vFW_vDNS distribution
- |||
- SDC -> SO : artifact distribution\nNOTIFY,DOWNLOAD,DEPLOY_OK
- SDC -> AAI : artifact distribution\nNOTIFY,DOWNLOAD,DEPLOY_OK
- SDC -> SDNC : artifact distribution\nNOTIFY,DOWNLOAD,DEPLOY_OK
- @enduml
-
-Instantiation
--------------
-
-.. uml::
-
- @startuml
- title vFW vDNS Instantiation (R1)\nvFW and vDNS use the same flows but they are separate VNFs/Services
- participant ONAP_User
- participant Robot
- Participant SDC
- Participant VID
- Participant SO
- ONAP_User -> AAI : populate cloud inventory
- note left of AAI: manual via curl or POSTMAN
- |||
- ONAP_User -> VID : vFW_vDNS deployment
- VID -> SDC : Lookup VNF artifacts
- VID -> AAI : Lookup cloud locations, subscriber
- VID -> SO : vFW_vDNS Service \nInstantiation\n(base modules)
- SO -> AAI : inventory update
- VID -> SO : vFW_vDNS VNF Instantiation\n(base modules)
- note left of AAI : VFWCL is two VNFs in one service\nso VNF instantiate occurs twice
- SO -> AAI : inventory update
- ONAP_User -> SDNC : VNF API Preload VNF/VF data
- VID -> SO : vFW_vDNS VF Instantiation\n(base modules)
- SO -> AAI : inventory update
- SO -> SDNC : Generic VNF API\n(assign)
- SO -> Multi_VIM : vFW_vDNS Heat template, \nENV file, preload parameters
- Multi_VIM -> CloudAPI : vFW_vDNS Heat template,\nENV file, preload parameters or
- CloudAPI -> Hypervisor : vFW_vDNS Infrastructure instantiation
- Hypervisor -> vFW_vDNS : Nova/Neutron Instantiation
- Hypervisor -> CloudAPI : complete
- CloudAPI -> Multi_VIM : complete
- Multi_VIM -> SO : complete
- note right : SO may poll for completion
- SO -> SDNC: Generic VNF API\n(activated)
- note left : on failure from Openstack SO issues rollback to SDNC
- SDNC -> AAI : L3 Network resource update
- SO -> VID : complete
- note right : VID will poll for completion
- ONAP_User -> Robot : run Heat Bridge
- Robot -> CloudAPI : retrieve cloud data
- Robot -> AAI : Update with cloud data
- |||
- @enduml
--- /dev/null
+#!/bin/bash
+#set -x # uncomment for bash script debugging
+
+### ============================================================================
+### 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.
+### ============LICENSE_END=====================================================
+
+###
+### checkdocs.sh
+###
+### AUTHOR(S):
+### Thomas Kulik, Deutsche Telekom AG, 2020
+###
+### DESCRIPTION:
+### Retrieves a full list of ONAP repos from gerrit inluding their state.
+### Clones all active repos of the ONAP master branch plus other requested ONAP
+### branches. Then the script does some docs related analyses depending on the
+### clone results. It creates logfiles containing filtered results. In addition
+### a table.csv is created which can be used to import it in a spreadsheed.
+### Also a zip-file is created which contains all the results.
+###
+### IMPORTANT:
+### - in the output, repo names are shown in square brackets for readability
+### e.g [aai/aai-common]/docs/release-notes.rst
+### - in the table.csv file you see data for the requested branch if available.
+### if not available, data is retrieved from the master branch. it will be
+### denoted in round brackets, e.g. (3) (tox.ini)
+###
+### REQUIREMENTS:
+### curl
+### jq
+###
+
+###
+### SOME HELPING COMMANDS TO PROCESS LOG FILES:
+### create repo list
+### curl -s https://git.onap.org/ | grep "^<tr><td class='toplevel-repo'><a title='" | sed -r "s:^<tr><td class='toplevel-repo'><a title='::" | sed -r "s:'.*::"
+###
+### remove branchname from the line
+### cat frankfurt_gerritclone.log | sed 's:frankfurt|::'
+###
+### list only image names
+### cat master_dockerimagesfull.log | grep image | sed -r 's:image\:::' | sed -r 's:^ +::' | sed '/^[[:space:]]*$/d'
+###
+### more interesting stuff ...
+### curl https://gerrit.onap.org/r/projects/?d
+### LONG: curl -s 'https://gerrit.onap.org/r/projects/?d' | awk '{if(NR>1)print}' | jq -c '.[] | {id, state}' | sed -r 's:%2F:/:g' | sed -r 's:["{}]::g' | sed -r 's:id\:::' | sed -r 's:,state\::|:' | sed '/All-Projects/d' | sed '/All-Users/d'
+### SHORT: curl -s 'https://gerrit.onap.org/r/projects/?d' | awk '{if(NR>1)print}' | jq -c '.[] | {id, state}' | sed -r 's:%2F:/:g; s:["{}]::g; s:id\:::; s:,state\::|:; /All-Projects/d; /All-Users/d'
+###
+
+script_version="1.2 (2020-11-18)"
+
+# save command for the restart with logging enabled
+command=$0
+arguments=$@
+fullcommand="${command} ${arguments}"
+
+###
+### functions
+###
+
+# print usage
+function usage() {
+ echo " "
+ echo " checkdocs.sh Version ${script_version}"
+ echo " "
+ echo " USAGE: "
+ echo " ./checkdocs.sh <arguments> "
+ echo " "
+ echo " ARGUMENTS: "
+ echo " -u|--user username "
+ echo " linux foundation username used to clone ONAP Gerrit repos"
+ echo " "
+ echo " -b|--branches branch1,branch2,branch3 "
+ echo " list of branches to be cloned. master is automatically "
+ echo " added to the list. do not add manually! "
+ echo " "
+ echo " -d|--dev "
+ echo " development-mode - limits number of repos to be cloned "
+ echo " "
+}
+
+# draw a simple line
+function drawline {
+ echo "*******************************************************************************"
+}
+
+# remove lockfile in case script is interrupted
+trap InterruptedScript SIGINT SIGTERM SIGHUP SIGKILL SIGSTOP
+function InterruptedScript {
+ echo " "
+ echo "Script was interrupted."
+ if [ -f $lockfile ] ; then
+ rm $lockfile
+ fi
+ exit 0
+}
+
+###
+### arguments handling
+###
+
+PARAMS=""
+
+while (( "$#" )); do
+ case "$1" in
+ -d|--dev)
+ devmode="TRUE"
+ shift
+ ;;
+ -b|--branches)
+ if [ -n "$2" ] && [ ${2:0:1} != "-" ]; then
+ branches_csv=$2
+ shift 2
+ else
+ echo "Error: Argument for $1 is missing" >&2
+ usage
+ exit 1
+ fi
+ ;;
+ -u|--user)
+ if [ -n "$2" ] && [ ${2:0:1} != "-" ]; then
+ lfusername=$2
+ shift 2
+ else
+ echo "Error: Argument for $1 is missing" >&2
+ usage
+ exit 1
+ fi
+ ;;
+ -*|--*=) # unsupported flags
+ echo "Error: Unsupported argument $1" >&2
+ usage
+ exit 1
+ ;;
+ *) # preserve positional arguments
+ PARAMS="$PARAMS $1"
+ shift
+ ;;
+ esac
+done
+
+# set positional arguments in their proper place
+eval set -- "$PARAMS"
+
+# old: declare -a branches=("master" "frankfurt" "guilin")
+if [[ $branches_csv == "" || $lfusername == "" ]]; then
+ usage
+ exit -1
+fi
+
+# master branch is automatically added and must not part of the user arguments
+if [[ $branches_csv == *"master"* ]]; then
+ usage
+ exit -1
+fi
+# clone master first, the the other branches
+branches_csv="master,${branches_csv}"
+
+# create the branches array by readinging in the values from the variable
+IFS=',' read -r -a branches <<< "${branches_csv}"
+
+#echo "DBUG: devmode = \"${devmode}\""
+#echo "DBUG: branches_csv = \"${branches_csv}\""
+#echo "DBUG: lfusername = \"${lfusername}\""
+#echo "DBUG: branches = \"${branches[@]}\""
+
+# restart script with logging enabled
+lockfile="checkdocs-runtime-lockfile"
+if [ ! -f $lockfile ] ; then
+ touch $lockfile
+ echo "Restarting script with logging enabled."
+ ${fullcommand} 2>&1 | tee checkdocs.log
+ rm $lockfile
+ exit
+fi
+
+echo " "
+echo "checkdocs.sh Version ${script_version}"
+echo " "
+
+# curl must be installed
+if ! command -v curl &> /dev/null
+then
+ echo "ERROR: curl command could not be found"
+ exit -1
+fi
+
+today=$(date '+%Y-%m-%d');
+repolist="gerrit-repos-master-"$today".txt";
+unique=$(date +%s)
+
+echo "Retrieving a full list of ONAP repositories (master) from gerrit.onap.org."
+
+# retrieve the full repolist from gerrit
+# workaround because of the (wrong?) response of gerrit.onap.org which makes jq command fail
+# "| awk '{if(NR>1)print}'" filters the first line of the response so that jq will work again (thx marek)
+curl -s 'https://gerrit.onap.org/r/projects/?d' | awk '{if(NR>1)print}' | jq -c '.[] | {id, state}' | sed -r 's:%2F:/:g; s:["{}]::g; s:id\:::; s:,state\::|:; /All-Projects/d; /All-Users/d' >./$repolist
+
+# process the created repolist
+# only active projects will be cloned in case the requested branch of the project exists
+echo "Accessing gerrit.onap.org with username \"${lfusername}\"."
+echo "Start cloning of repositories."
+
+for branch in "${branches[@]}"
+do
+
+ echo " "
+ echo "###"
+ echo "### ${branch}"
+ echo "###"
+ echo " "
+
+ branch_upper=$(echo "${branch}" | tr '[:lower:]' '[:upper:]')
+
+ mkdir $branch
+ cp $repolist $branch
+ cd $branch
+
+ devcounter=0
+
+ # process repolist
+ while read line
+ do
+
+ if [[ $devmode == "TRUE" ]]; then
+ devcounter=$((devcounter+1))
+ fi
+
+ if [[ $devcounter -lt "11" ]]; then
+
+ if [[ $devmode == "TRUE" ]]; then
+ echo "INFO: devmode! counter=${devcounter}"
+ fi
+
+ drawline
+ reponame=$(echo $line | awk -F "|" '{print $1}');
+ repostate=$(echo $line | awk -F "|" '{print $2}');
+ echo $reponame
+ echo $repostate
+
+ if [[ $repostate == "ACTIVE" ]]; then
+ echo "Cloning \"${branch}\" branch of ACTIVE project ${reponame}..."
+
+ git clone --branch ${branch} --recurse-submodules ssh://${lfusername}@gerrit.onap.org:29418/$reponame ./$reponame
+ gitexitcode=$?
+
+ if [[ ! ${gitexitcode} == "0" ]]; then
+ errormsg=$(tail -1 ../checkdocs.log)
+ else
+ errormsg="cloned"
+ fi
+
+ # gerritclone.log format: $1=gitexitcode|$2=reponame|$3=repostate|$4=errormsg
+ echo "${gitexitcode}|${reponame}|${repostate}|${errormsg}" | tee -a ${branch}_gerritclone.log
+
+ elif [[ $repostate == "READ_ONLY" ]]; then
+ echo "-|${reponame}|${repostate}|ignored" | tee -a ${branch}_gerritclone.log
+ else
+ echo "-|${reponame}|unknown repo state \"${repostate}\"|-" | tee -a ${branch}_gerritclone.log
+ fi
+
+ # examine repo
+ if [[ ${gitexitcode} == "0" ]]; then
+
+ printf "\ndocs directories:\n"
+ find ./$reponame -type d -name docs | sed -r 's:./::' | sed -r s:${reponame}:[${reponame}]: | tee -a ${branch}_docs.log
+
+ printf "\nrst files:\n"
+ find ./$reponame -type f -name *.rst | sed -r 's:./::' | sed -r s:${reponame}:[${reponame}]: | tee -a ${branch}_rstfiles.log
+
+ printf "\nrelease notes rst:\n"
+ find ./$reponame -type f | grep 'release.*note.*.rst' | sed -r 's:./::' | sed -r s:${reponame}:[${reponame}]: | tee -a ${branch}_releasenotes.log
+
+ printf "\ntox.ini files:\n"
+ find ./$reponame -type f -name tox.ini | sed -r 's:./::' | sed -r s:${reponame}:[${reponame}]: | tee -a ${branch}_toxini.log
+
+ printf "\nconf.py files:\n"
+ find ./$reponame -type f -name conf.py | sed -r 's:./::' | sed -r s:${reponame}:[${reponame}]: | tee -a ${branch}_confpy.log
+
+ printf "\nindex.rst files:\n"
+ find ./$reponame -type f -name index.rst | sed -r 's:./::' | sed -r s:${reponame}:[${reponame}]: | tee -a ${branch}_indexrst.log
+
+ fi
+
+ # end defcounter loop
+ fi
+
+ gitexitcode=""
+
+ done <${repolist}
+
+ # examine repos
+ drawline
+ find . -type f -name values.yaml -print -exec grep "image:" {} \; | sed -r 's:^ +::' | tee ${branch}_dockerimagesfull.log
+ drawline
+ ls --format single-column -d */ | sed 's:/$::' | tee ${branch}_directories.log
+ drawline
+ cat ${branch}_dockerimagesfull.log | grep image | sed -r 's:image\:::' | sed -r 's:^ +::' | sed '/^[[:space:]]*$/d' >${branch}_dockerimages.log
+ drawline
+ ls --format single-column -d oom/kubernetes/*/ | tee ${branch}_oomkubernetes.log
+ drawline
+
+ # examine docs
+ readarray -t docs_array < ./${branch}_docs.log;
+
+ for line in "${docs_array[@]}"
+ do
+
+ echo $line | tee -a ${branch}_docsconfig.log
+
+ # remove [ and ] which are distinguish the project name in the output
+ line=$(echo $line | sed -r 's:\[:: ; s:\]::')
+
+ if [ -f ./${line}/conf.py ] ; then
+ echo " conf.py ..... found" | tee -a ${branch}_docsconfig.log
+ else
+ echo " conf.py ..... NOT FOUND" | tee -a ${branch}_docsconfig.log
+ fi
+
+ if [ -f ./${line}/index.rst ] ; then
+ echo " index.rst ... found" | tee -a ${branch}_docsconfig.log
+ else
+ echo " index.rst ... NOT FOUND" | tee -a ${branch}_docsconfig.log
+ fi
+
+ if [ -f ./${line}/tox.ini ] ; then
+ echo " tox.ini ..... found" | tee -a ${branch}_docsconfig.log
+ else
+ echo " tox.ini ..... NOT FOUND" | tee -a ${branch}_docsconfig.log
+ fi
+
+ echo " " | tee -a ${branch}_docsconfig.log
+
+ done
+ unset docs_array
+
+ drawline
+
+ ###
+ ### build a csv table that combines results
+ ###
+
+ #
+ # csv column #1: project name
+ #
+
+ readarray -t array < ./${repolist};
+ i=0
+ csv[i]="project"
+ ((i++))
+ for line in "${array[@]}"
+ do
+ reponame=$(echo $line | awk -F "|" '{print $1}');
+ project=$(echo $reponame | sed 's:/.*$::')
+ #echo "DBUG: reponame=${reponame}"
+ #echo "DBUG: project=${project}"
+ #echo "DBUG: i=${i}"
+ csv[i]=${project}
+ ((i++))
+ done
+ unset array
+ unset i
+ unset reponame
+ unset project
+
+ #
+ # csv column #2: repo name
+ #
+
+ readarray -t array < ./${repolist};
+ i=0
+ csv[i]="${csv[i]},MASTER repo name"
+ ((i++))
+ for line in "${array[@]}"
+ do
+ reponame=$(echo $line | awk -F "|" '{print $1}');
+ csv[i]="${csv[i]},${reponame}"
+ ((i++))
+ done
+ unset array
+ unset i
+ unset reponame
+
+ #
+ # csv column #3: repo state
+ #
+
+ readarray -t array < ./${repolist};
+ i=0
+ csv[i]="${csv[i]},MASTER repo state"
+ ((i++))
+ for line in "${array[@]}"
+ do
+ repostate=$(echo $line | awk -F "|" '{print $2}');
+ csv[i]="${csv[i]},${repostate}"
+ ((i++))
+ done
+ unset array
+ unset i
+ unset repostate
+
+ #
+ # csv column #4: clone message
+ #
+
+ readarray -t array < ./${branch}_gerritclone.log;
+ i=0
+ csv[i]="${csv[i]},${branch_upper} clone message"
+ ((i++))
+ for line in "${array[@]}"
+ do
+ # gerritclone.log format: $1=gitexitcode|$2=reponame|$3=repostate|$4=errormsg
+ errormsg=$(echo $line | awk -F "|" '{print $4}');
+ csv[i]="${csv[i]},${errormsg}"
+ ((i++))
+ done
+ unset array
+ unset i
+ unset errormsg
+
+ #
+ # csv column #5: RELEASE component (yes|no|maybe)
+ # to be filled with values of the planned release config file maintained by
+ # the onap release manager
+ #
+
+ # gerritclone.log format: $1=gitexitcode|$2=reponame|$3=repostate|$4=errormsg
+ readarray -t array < ./${branch}_gerritclone.log;
+ i=0
+ csv[i]="${csv[i]},${branch_upper} component"
+ ((i++))
+ for line in "${array[@]}"
+ do
+
+ # gerritclone.log format: $1=gitexitcode|$2=reponame|$3=repostate|$4=errormsg
+ gitexitcode=$(echo $line | awk -F "|" '{print $1}');
+ reponame=$(echo $line | awk -F "|" '{print $2}');
+ repostate=$(echo $line | awk -F "|" '{print $3}');
+ errormsg=$(echo $line | awk -F "|" '{print $4}');
+
+ if [[ ${repostate} == "ACTIVE" && ${gitexitcode} == "0" ]]; then
+ releasecomponent="yes"
+ elif [[ ${repostate} == "ACTIVE" && ${gitexitcode} == "128" ]]; then
+ releasecomponent="maybe"
+ elif [ ${repostate} == "READ_ONLY" ]; then
+ releasecomponent="no"
+ else
+ releasecomponent="unknown"
+ fi
+
+ csv[i]="${csv[i]},${releasecomponent}"
+ ((i++))
+ done
+ unset array
+ unset i
+ unset gitexitcode
+ unset reponame
+ unset repostate
+ unset errormsg
+ unset releasecomponent
+
+ #
+ # csv column #6: docs (at repo root directory only; no recursive search!)
+ # csv column #7: conf.py
+ # csv column #8: tox.ini
+ # csv column #9: index.rst
+ #
+ # columns are filled with values from requested branch.
+ # if data is not available values from master branch are used.
+ # to identify master branch values, data is put into brackets "(...)"
+ #
+
+ readarray -t array < ./${repolist};
+ i=0
+ csv[$i]="${csv[i]},docs,conf.py,tox.ini,index.rst"
+ ((i++))
+ for line in "${array[@]}"
+ do
+ line=$(echo $line | sed 's:|.*$::')
+ #echo "DBUG: line=${line}"
+ #echo "DBUG: i=${i}"
+
+ # docs
+ if [ -d ./${line}/docs ] ; then
+ docs="docs"
+ elif [ -d ../master/${line}/docs ] ; then
+ docs="(docs)"
+ else
+ docs="-"
+ fi
+
+ # conf.py
+ if [ -f ./${line}/docs/conf.py ] ; then
+ docs="${docs},conf.py"
+ elif [ -f ../master/${line}/docs/conf.py ] ; then
+ docs="${docs},(conf.py)"
+ else
+ docs="${docs},-"
+ fi
+
+ # tox.ini
+ if [ -f ./${line}/docs/tox.ini ] ; then
+ docs="${docs},tox.ini"
+ elif [ -f ../master/${line}/docs/tox.ini ] ; then
+ docs="${docs},(tox.ini)"
+ else
+ docs="${docs},-"
+ fi
+
+ # index.rst
+ if [ -f ./${line}/docs/index.rst ] ; then
+ docs="${docs},index.rst"
+ elif [ -f ../master/${line}/docs/index.rst ] ; then
+ docs="${docs},(index.rst)"
+ else
+ docs="${docs},-"
+ fi
+
+ #echo "DBUG: docs=${docs}"
+ line="${csv[i]},${docs}"
+ csv[$i]=${line}
+ ((i++))
+ done
+ unset array
+ unset i
+ unset docs
+
+ #
+ # csv column #10: index.html@RTD accessibility check
+ # csv column #11: index.html url
+ #
+
+ readarray -t array < ./${branch}_gerritclone.log;
+ i=0
+ csv[i]="${csv[i]},index.html@RTD,index.html url"
+ ((i++))
+ for line in "${array[@]}"
+ do
+ # gerritclone.log format: $1=gitexitcode|$2=reponame|$3=repostate|$4=errormsg
+ gitexitcode=$(echo $line | awk -F "|" '{print $1}');
+ reponame=$(echo $line | awk -F "|" '{print $2}');
+ repostate=$(echo $line | awk -F "|" '{print $3}');
+ errormsg=$(echo $line | awk -F "|" '{print $4}');
+
+ url=""
+ curl_result=""
+
+ # this routine works only with release "frankfurt" and later because
+ # earlier releases are using submodule structure for documentation files
+ if echo "$branch" | grep -q '^[abcde]'; then
+ curl_result="unsupported release"
+ url="-"
+ else
+
+ # we are working on "frankfurt" branch or later ...
+ # only if repostate IS ACTIVE a curl test is required
+ if [[ ${repostate} == "ACTIVE" ]]; then
+
+ # OPTIONAL: USE ALSO GITEXITCODE AS A FILTER CRITERIA ???
+
+ # url base
+ # important! only doc project needs a different url base
+ if [[ ${reponame} == "doc" ]]; then
+ url_start="https://docs.onap.org"
+ else
+ url_start="https://docs.onap.org/projects/onap"
+ fi
+ url_lang="en"
+ url_branch=${branch}
+
+ # "master" branch documentation is available as "latest" in RTD
+ if [[ ${url_branch} == "master" ]]; then
+ url_branch="latest"
+ fi
+
+ # replace all / characters in repo name with - charachter
+ url_repo=$(echo ${reponame} | sed -r 's/\//-/g')
+ url_file="index.html"
+
+ # build the full url
+ if [[ ${reponame} == "doc" ]]; then
+ # build the full url for the doc project
+ url="${url_start}/${url_lang}/${url_branch}/${url_file}"
+ else
+ # build the full url for the other projects
+ url="${url_start}-${url_repo}/${url_lang}/${url_branch}/${url_file}"
+ fi
+ #echo "DBUG: url=$url"
+
+ # test accessibility of url
+ curl --head --silent --fail "${url}?${unique}" >/dev/null
+ curl_result=$?
+
+ # convert numeric results to text
+ if [ "${curl_result}" = "0" ]; then
+ curl_result="accessible"
+ elif [ "${curl_result}" = "22" ]; then
+ curl_result="does not exist"
+ else
+ curl_result="ERROR:${curl_result}"
+ fi
+
+ # url does not exist for this branch.
+ # in case the requested url is not already for "master" branch,
+ # we try to access the url of the master branch and denote the
+ # result by using round brackets (result)
+ if [[ ${curl_result} == "does not exist" && ! $branch == "master" ]]; then
+
+ # build the full (master/latest) url
+ url="${url_start}-${url_repo}/${url_lang}/latest/${url_file}"
+ #echo "DBUG: url=$url"
+
+ # test accessibility of url in "master branch" (latest)
+ curl --head --silent --fail "${url}?${unique}" >/dev/null
+ curl_result=$?
+ # denote result as a value from "master" branch (latest)
+ url="(${url})"
+
+ # convert numeric results to text
+ if [ "${curl_result}" = "0" ]; then
+ curl_result="(accessible)"
+ elif [ "${curl_result}" = "22" ]; then
+ curl_result="(does not exist)"
+ else
+ curl_result="(ERROR:${curl_result})"
+ fi
+
+ fi
+ else
+ # repostate IS NOT ACTIVE - no curl test required
+ curl_result="-"
+ url="-"
+ fi
+ fi
+
+ echo "$url ... $curl_result"
+ csv[i]="${csv[i]},${curl_result},${url}"
+ #echo "DBUG: csv line=${csv[i]}"
+
+ ((i++))
+ done
+
+ #
+ # csv column #12: release notes
+ #
+
+ readarray -t array < ../${repolist};
+ i=0
+ csv[i]="${csv[i]},release notes"
+ ((i++))
+ for line in "${array[@]}"
+ do
+ line=$(echo $line | sed 's:|.*$::')
+ #echo "DBUG: line=\"${line}\""
+ #echo "DBUG: i=${i}"
+ relnote=""
+
+ # put repo name in square brackets for increased grep hit rate
+ # escape minus and bracket characters to avoid problems with the grep command
+ #repo_grepable=$(echo ${line} | sed -r s:${line}:[${line}]: | sed -r 's/-/\\-/g' | sed -r 's/\[/\\[/g' | sed -r 's/\]/\\]/g')
+ #echo "DBUG: repo_grepable=\"${repo_grepable}\""
+
+ # check if repo dir exists in this branch
+ if [ -d ./${line} ] ; then
+ # if yes, check if repo name appears in the branch releasenotes.log
+ relnote=$(find "./${line}" -type f | grep 'release.*note.*.rst' | wc -l);
+ # repo dir DOES NOT exist in this branch - so check if repo dir exists in MASTER branch
+ elif [ -d ../master/${line} ] ; then
+ # if yes, check if repo name appears in the MASTER releasenotes.log
+ # count release notes files in MASTER branch (in repo root and its subdirectories)
+ relnote=$(find "../master/${line}" -type f | grep 'release.*note.*.rst' | wc -l);
+ # put results in round brackets to show that this is MASTER data
+ relnote=$(echo ${relnote} | sed -r s:${relnote}:\(${relnote}\):)
+ else
+ relnote="-"
+ fi
+
+ line="${csv[i]},${relnote}"
+ csv[i]=${line}
+ ((i++))
+
+ done
+ unset array
+ unset i
+ unset relnote
+ unset repo_grepable
+
+ #
+ # build the table.csv file
+ #
+
+ for i in "${csv[@]}"
+ do
+ echo "$i" | tee -a ./${branch}_table.csv
+ done
+
+ #
+ # create data package for this branch and zip it
+ #
+
+ datadir=${branch}_data
+ mkdir $datadir
+ cp $repolist $datadir
+ cp ${branch}_table.csv $datadir
+ cp ${branch}_*.log $datadir
+ zip -r ${datadir}.zip $datadir
+
+ # return from the branch directory
+ cd ..
+
+# return and work on the next requested branch ... or exit
+done
--- /dev/null
+#!/bin/bash
+#set -x # uncomment for bash script debugging
+
+# branch, e.g. "master" or "guilin"
+branch=$1
+# logfile produced by checkdocs that contains the list of links
+file_to_process=$2
+
+#
+# NOTE: works NOT with elalto release and below because of the submodule structure used for documentation
+#
+
+# url
+# important! only doc project needs a different url base
+url_lang="en"
+url_branch=${branch}
+unique=$(date +%s)
+
+# "master" branch documentation is available as "latest" in RTD
+if [[ ${url_branch} == "master" ]]; then
+ url_branch="latest"
+fi
+
+#readarray -t array < ./${branch}_releasenotes.log;
+readarray -t array < ${file_to_process};
+for line in "${array[@]}"
+do
+
+ reponame=$(echo ${line} | cut -d "[" -f2 | cut -d "]" -f1)
+ #reponame="[${reponame}]"
+ #echo "DBUG: reponame=${reponame}"
+
+ # example line: [dmaap/messagerouter/messageservice]/docs/release-notes/release-notes.rst
+ # example url: https://docs.onap.org/projects/onap-dmaap-messagerouter-messageservice/en/frankfurt/release-notes/release-notes.html
+
+ # extract repo name which comes in square bracktes ([...]) and convert slash (/) to minus (-)
+ # line: [dmaap/messagerouter/messageservice]/docs/release-notes/release-notes.rst
+ # output: dmaap-messagerouter-messageservice
+ url_repo=$(echo ${line} | sed -r 's/].+$//' | sed -r 's/\[//' | sed -r 's/\//-/g')
+
+ # extract rst filename and its path; replace .rst ending with .html
+ # warning: path does not always contain "docs"!
+ # line: [dmaap/messagerouter/messageservice]/docs/release-notes/release-notes.rst
+ # output: release-notes/release-notes.html
+ url_file=$(echo ${line} | sed -r 's/^.+\]//' | sed -r 's/^.*\/docs\///' | sed -r 's/\.rst$/\.html/' )
+
+ #echo "DBUG: line = ${line}"
+ #echo "DBUG: url_file = ${url_file}"
+ #echo "DBUG: url_repo = ${url_repo}"
+ #echo "DBUG: reponame = ${reponame}"
+
+ # build the full url
+ if [[ ${reponame} == "doc" ]]; then
+ # build the full url for the doc project
+ url_start="https://docs.onap.org"
+ url="${url_start}/${url_lang}/${url_branch}/${url_file}"
+ else
+ # build the full url for the other projects
+ url_start="https://docs.onap.org/projects/onap"
+ url="${url_start}-${url_repo}/${url_lang}/${url_branch}/${url_file}"
+ fi
+
+ #echo "DBUG: url = $url"
+
+ # check with curl if html page is accessible (no content check!)
+ # to prevent (server side) cached results a unique element is added to the request
+ curl --head --silent --fail "${url}?${unique}" >/dev/null
+ curl_result=$?
+
+ # "0" and "22" are expected as a curl result
+ if [ "${curl_result}" = "0" ]; then
+ curl_result="accessible"
+ elif [ "${curl_result}" = "22" ]; then
+ curl_result="does not exist"
+ fi
+
+ #echo -e "DBUG: ${line}"
+ #echo -e "DBUG: ${curl_result} ${url}"
+ #echo " "
+
+ echo "${line},${url},${curl_result}"
+
+ ((i++))
+done
+unset array
+unset i
Code Review / doc.git / commitdiff
