Skip to content

Commit

Permalink
Remove obsolete md references
Browse files Browse the repository at this point in the history 
They were all detected by linkcheck.

It doesn't leverage any title 3 links as they would ask Anuket to remove all duplicated at this level.
(see Synopsis or Introduction as blocking points)

Signed-off-by: Cédric Ollivier <cedric.ollivier@orange.com>
  • Loading branch information
@collivier
collivier committed Mar 6, 2022
1 parent 2881a46 commit 149061f
Show file tree
Hide file tree
Showing 13 changed files with 216 additions and 180 deletions.
2 changes: 1 addition & 1 deletion doc/ref_model/chapters/appendix-a.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ Relevant for sizing infrastructure and application operations (which often is an
VNF Design Guidelines
---------------------

A number of software design guidelines (industry best practices) have been developed over the years including micro-services, cohesion and coupling. In addition to the industry best-practices, there are additonal guidelines and requirements specified by ONAP in "`VNF or PNF Requirements Documentation <https://onap.readthedocs.io/en/latest/submodules/vnfrqts/requirements.git/docs/index.html>`__." This section does not supplant these well-known guidelines and practices. The content here only draws attention to some other design consideration that VNF Developers need to incorporate in their practices. Please note that some of these guidelines may be incorporated by operators in their contracts with VNF Vendors.
A number of software design guidelines (industry best practices) have been developed over the years including micro-services, cohesion and coupling. In addition to the industry best-practices, there are additonal guidelines and requirements specified by ONAP in "`VNF or PNF Requirements Documentation <https://docs.onap.org/projects/onap-vnfrqts-requirements/en/istanbul/>`__." This section does not supplant these well-known guidelines and practices. The content here only draws attention to some other design consideration that VNF Developers need to incorporate in their practices. Please note that some of these guidelines may be incorporated by operators in their contracts with VNF Vendors.

These guidelines are written in an informal style and any resemblance to requirements is incidental. The VNF Developer **should** ensure that their software and the resultant VNF image:

Expand Down
11 changes: 5 additions & 6 deletions doc/ref_model/chapters/chapter01.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ Introduction
Overview
--------

The Reference Model (RM) specifies a virtualisation technology agnostic (VM-based and container-based) cloud infrastructure abstraction and acts as a "catalogue" of the exposed infrastructure capabilities, resources, and interfaces required by the workloads. This document has been developed by the Linux Foundation Networking project `Anuket <../../common/chapter00.md>`__.
The Reference Model (RM) specifies a virtualisation technology agnostic (VM-based and container-based) cloud infrastructure abstraction and acts as a "catalogue" of the exposed infrastructure capabilities, resources, and interfaces required by the workloads. This document has been developed by the Linux Foundation Networking project :doc:`common/chapter00`.

**Problem Statement:** Based on community consultations, including telco operators, technology suppliers, and software developers, there is a realisation that there are significant technical, operational, and business challenges to the development and deployment of Virtual Network Functions (VNF) and Cloud Native Network Functions (CNF) due to the lack of a common cloud infrastructure platform. These include but are not limited to the following:

Expand Down Expand Up @@ -78,14 +78,14 @@ This document specifies:
Principles
----------

The Reference Model specifications conform to the overall principles defined in `Anuket Principles <../../common/chapter00.md#2.0>`__.
The Reference Model specifications conform to the overall principles defined in :ref:`common/chapter00:anuket general principles`.

Definitions/Terminology/Abbreviations
-------------------------------------

To help guide the reader, the Reference Model `Glossary <../../common/glossary.md>`__ provides an introduction to the main terms used within this document and throughout the project in general. These definitions are, with a few exceptions, based on the ETSI GR NFV 003 [1] definitions. In a few cases, they have been modified to avoid deployment technology dependencies only when it seems necessary to avoid confusion.
To help guide the reader, the Reference Model :doc:`common/glossary` provides an introduction to the main terms used within this document and throughout the project in general. These definitions are, with a few exceptions, based on the ETSI GR NFV 003 [1] definitions. In a few cases, they have been modified to avoid deployment technology dependencies only when it seems necessary to avoid confusion.

Please refer to `Abbreviations <../../common/abbreviations.md>`__ for a full list of abbreviations used in this document.
Please refer to :doc:`common/abbreviations` for a full list of abbreviations used in this document.

Conventions
-----------
Expand All @@ -95,5 +95,4 @@ Conventions
References
----------

Please refer to `References <../../common/references.md>`__ for a full list of references used in this document.

Please refer to :doc:`common/references` for a full list of references used in this document.
23 changes: 11 additions & 12 deletions doc/ref_model/chapters/chapter02.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -322,7 +322,7 @@ Two profile *layers* are proposed:
Workloads specify infrastructure capability requirements as workload metadata, indicating what kind of infrastructure they must run on to achieve functionality and/or the intended level of performance. Workloads request resources specifying the Profiles and Profile Extensions, and a set of sizing metadata that maybe expressed as flavours that are required for the workload to run as intended.
A resource request by a workload can be met by any infrastructure node that has the same or a more specialised profile and the necessary capacity to support the requested flavour or resource size.

Profiles, Profile Extensions and Flavours will be considered in greater detail in `Section 4.2 <./chapter04.md#4.2>`__.
Profiles, Profile Extensions and Flavours will be considered in greater detail in :ref:`ref_model/chapters/chapter04:profile extensions`.

Profiles (top-level partitions)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expand All @@ -337,7 +337,7 @@ Based on the above analysis, the following cloud infrastructure profiles are pro

**Figure 2-5:** Infrastructure profiles proposed based on VNFs categorisation.

In `Chapter 4 <./chapter04.md>`__ these **B (Basic)** and **H (High) Performance** infrastructure profiles will be defined in greater detail for use by workloads.
In :doc:`ref_model/chapters/chapter04` these **B (Basic)** and **H (High) Performance** infrastructure profiles will be defined in greater detail for use by workloads.

Profiles partition the infrastructure: an infrastructure object (host/node) **must** have one and only one profile associated to it.

Expand All @@ -351,21 +351,20 @@ The following **profile extensions** are proposed:
Profile Extension Name Mnemonic Applicable to Basic Profile Applicable to High Performance Profile Description Notes
================================================ ======================= =========================== ====================================== ================================================================================================================================================================= =============================================
Compute Intensive High-performance CPU compute-high-perf-cpu ❌ ✅ Nodes that have predictable computing performance and higher clock speeds. May use vanilla VIM/K8S scheduling instead.
Storage Intensive High-performance storage storage-high-perf ❌ ✅ Nodes that have low storage latency and/or high storage IOPS
Storage Intensive High-performance storage storage-high-perf ❌ ✅ Nodes that have low storage latency and/or high storage IOPS
Compute Intensive High memory compute-high-memory ❌ ✅ Nodes that have high amounts of RAM. May use vanilla VIM/K8S scheduling instead.
Compute Intensive GPU compute-gpu ❌ ✅ for compute intensive Workloads that requires GPU compute resource on the node May use Node Feature Discovery.
Network Intensive High speed network (25G) high-speed-network ❌ ✅ Denotes the presence of network links (to the DC network) of speed of 25 Gbps or greater on the node.
Network Intensive Very High speed network (100G) very-high-speed-network ❌ ✅ Denotes the presence of network links (to the DC network) of speed of 100 Gbps or greater on the node.
Low Latency - Edge Sites low-latency-edge ✅ ✅ Labels a host/node as located in an edge site, for workloads requiring low latency (specify value) to final users or geographical distribution.
Very Low Latency - Edge Sites very-low-latency-edge ✅ ✅ Labels a host/node as located in an edge site, for workloads requiring low latency (specify value) to final users or geographical distribution.
Ultra Low Latency - Edge Sites ultra-low-latency-edge ✅ ✅ Labels a host/node as located in an edge site, for workloads requiring low latency (specify value) to final users or geographical distribution.
Fixed function accelerator compute-ffa ❌ ✅ Labels a host/node that includes a consumable fixed function accelerator (non-programmable, e.g. Crypto, vRAN-specific adapter).
Network Intensive High speed network (25G) high-speed-network ❌ ✅ Denotes the presence of network links (to the DC network) of speed of 25 Gbps or greater on the node.
Network Intensive Very High speed network (100G) very-high-speed-network ❌ ✅ Denotes the presence of network links (to the DC network) of speed of 100 Gbps or greater on the node.
Low Latency - Edge Sites low-latency-edge ✅ ✅ Labels a host/node as located in an edge site, for workloads requiring low latency (specify value) to final users or geographical distribution.
Very Low Latency - Edge Sites very-low-latency-edge ✅ ✅ Labels a host/node as located in an edge site, for workloads requiring low latency (specify value) to final users or geographical distribution.
Ultra Low Latency - Edge Sites ultra-low-latency-edge ✅ ✅ Labels a host/node as located in an edge site, for workloads requiring low latency (specify value) to final users or geographical distribution.
Fixed function accelerator compute-ffa ❌ ✅ Labels a host/node that includes a consumable fixed function accelerator (non-programmable, e.g. Crypto, vRAN-specific adapter).
Firmware-programmable adapter compute-fpga ❌ ✅ Labels a host/node that includes a consumable Firmware-programmable adapter (programmable, e.g. Network/storage FPGA with programmable part of firmware image).
SmartNIC enabled network-smartnic ❌ ✅ Labels a host/node that includes a Programmable accelerator for vSwitch/vRouter, Network Function and/or Hardware Infrastructure.
SmartSwitch enabled network-smartswitch ❌ ✅ Labels a host/node that is connected to a Programmable Switch Fabric or TOR switch
SmartNIC enabled network-smartnic ❌ ✅ Labels a host/node that includes a Programmable accelerator for vSwitch/vRouter, Network Function and/or Hardware Infrastructure.
SmartSwitch enabled network-smartswitch ❌ ✅ Labels a host/node that is connected to a Programmable Switch Fabric or TOR switch
================================================ ======================= =========================== ====================================== ================================================================================================================================================================= =============================================

**Table 2-1:** Profile extensions

\*\ **Note:** This is an initial set of proposed profiles and profile extensions and it is expected that more profiles and/or profile extensions will be added as more requirements are gathered and as technology enhances and matures.

0 comments on commit 149061f

Please sign in to comment.