Blog

Nile, the latest version of Anuket was released to the public on January 4, 2023, with add cloud native requirements and testing functionality!

Anuket Overview

Anuket is an LF Networking project occupies a unique position in the telecom industry incorporating both operator infrastructure specifications, implementations, and open source infrastructure test suite development, all under a single initiative. The community has subject matter expert representatives from telco operators and their technology suppliers, which means that it is well positioned to address the “real world” challenges of the telecommunications industry. If you or anyone you know would like to contribute to any of these important activities, the Anuket website is a great place to start.

Leadership

Anuket members, per its Charter, elected the 2023 Technology Steering Committee and Co-chairs: Scott Steele and Gergely Csatari. On behalf of outgoing 2022 TSC Co-chairs, Gergely and myself, we would like to thank all Anuket contributors for their fantastic efforts in 2022 and wish the new TSC and the new Co-chairs all the best in their 2023 work!

Anuket Nile Release

Numerous Anuket projects and work streams continued to strengthen container-based open infrastructure specifications and implementations – an area that is increasingly important to the telco industry. Some of the accomplishments include:

  • ViNePerf - The ViNePerf project continued development efforts to automate test setup and benchmarking of container networking with various CNI plug-ins (Multus, Cillium) and kernel acceleration (AF_XDP, eBPF), with the help of a Student Volunteer and an Intern from the LFN program.
  • Thoth - The Thoth project continues to focus on implementing E2E AI for NFV use case scenarios. The newly established NICIP project is a jointly organized data generation competition with ITU.  Thoth is also cooperating on AI frameworks such as Mindspore, and starting the R&D effort needed to create data anonymization tools to allow telecom companies to share without the fear of exposing actual customer data.

 

On the requirements side

  • Reference Model (RM) changes (major):
  • Infrastructure LCM Automation – re-edited and updated to improve readability and to ensure alignment with multi-cloud models
  • Security sections updated to reflect (and refer to) evolving 5G security standards and best practices
  • Added energy consumption metrics and related requirements
  • Reference Architecture 1 (RA1) OpenStack changes:
  • New chapter based on RC1 content integrates conformance and establishes the link between architecture requirements and tests, providing the mechanism to validate the cloud infrastructure against the set of defined requirements.
  • Chapter 1 has been restructured with the addition of a bibliography and an abbreviations table.
  • The whole document has been reviewed to ease the creation of version 2 of NG.133 GSMA document.
  • 133 v2 has been officially published the 9thof December.


  • Updates have been made for the support of containerized applicationsand Cyborg accelerators drivers.
  • Reference Conformance 2 (RC2) has been updated to align with the latest versions of Kubernetes and Functest.
    1. Added specific test references supporting workloads by referencing the CNCF CNF testsuite.


In the coming releases, Hybrid, Multi-Cloud model and AI/ML utilisation, will be the focus of Anuket work in the upcoming releases, reflecting a growing global interest in more sophisticated operating models for telecommunication operators facing the challenges of real-life 5G/Edge/IoT implementations.

NameEarliest time to start the TSC in UTCLatest time to start the TSC in UTCMeeting Window in Hours
8:0016:008
12:00 (if needed), 13:00 (preferred)01:00 +112
Pankaj Goyal 14:000500 +115
12:0016:0015
1:0015:0014
Georg Kunz 08:0016:008
Walter Kozlowski 20:00 (21:00 April - Oct)13:00 (next day) (14:00 April - Oct)17

In 2022, the Anuket Project continued its two release cadence with Moselle delivered in June and Nile following in December. As has been true for the last few years, Anuket has been focused on developing reference models, architectures and specifications in support of infrastructure for virtualized (CNF/VNF) telecom workloads.  The requirements have continued to evolve to cover more use cases in the Reference Model (RM), and align these use cases with changes in upstream communities in the Reference Architectures for OpenStack (RA1) and Kubernetes (RA2). The application requirement specification for the Reference Architecture for Kubernetes matches with the CNCF CNF Conformance program to avoid the fragmentation of conformance programs in the industry, while fostering continued collaboration with the CNCF community. Taking the Reference Model and the Reference Architecture for OpenStack, in 2022 the Reference Conformance for OpenStack has also been released as a GSMA Permanent Release document. We are working with the GSMA on a planned release of the Reference Architecture for Kubernetes (RA2) in 2023.  On top of the enhancement of collaboration with GSMA we plan to continue to evolve our specifications by adding new use cases, aligning with adjacent communities, such as Nephio, O-RAN and Sylva, and further increase the quality and coverage of our Reference Architecture for Kubernetes and conformance projects.  

On the testing side of the project, Functest, the testing framework that supports the conformance and Anuket Assured programs maintains continuous release updates in synch with the upstream OpenStack and Kubernetes releases.  The ViNePerf project continued development efforts to automate test setup and benchmarking of  container networking with various CNI plug-ins (Multus, Cillium) and kernel acceleration (AF_XDP, eBPF), with the help of a Student Volunteer and an Intern from the LF program. 

We also plan to continue the work we started in 2022 to increase the consumability of our project and our deliverables by enhancing our documentation, testing tools and web presence.


Intro

The target of this conspiracy to make Anuket more easy to understand for someone who is not involved in the project.

We would like to achieve this by tuning the already existing documentation created for the project. This includes applying consistent templates, linking the documents together in a meaningful way and many more listed in here.

This page is created to help the conspirators.

Current conspirators

Project management and communication

What is where


anuket-doc-structure



 

  • Problem statement from
  • We have a defined scope here: About Anuket
  • Conclusions
    • We do not need to change the scope
    • We would need to have a survery on Anuket among the industry actors about the role and adoption of Anuket.



Active Anuket repos

This is a list of active Anuket repos in the July of 2022


LocationIs active
airshipGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
apexGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
apex-os-net-configGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
apex-puppet-tripleoGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
apex-tripleo-heat-templatesGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
armbandGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
autoGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
availabilityGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
bambooGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
barometerGerrityes
bottlenecksGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
calipsoGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
cirvGerrityes
cirv-hdvGerrit
cirv-rapidGerrit
cirv-sdvGerrit
cirv-spirentGerrit
cloverGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
compass-containersGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
compass4nfvGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
conductorGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
container4nfvGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
copperGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
cperfGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
cranGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
daisyGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
doctorGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
dominoGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
dovetailGerrit

Dan Xu 

  • is archived
  • Gerrit must be set as RO
dovetail-webportalGerrit

Dan Xu 

  • is archived
  • Gerrit must be set as RO
dpaccGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
edgecloudGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
enfvGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
escalatorGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
fastpathmetricsGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
fdsGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
fuelGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
functestGerrityes
functest-kubernetesGerrityes
functest-requirementsGerrityes
functest-xtestingGerrityes
genesisGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
genesisreqGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
infraGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
inspectorGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
ipv6Gerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
joidGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
kuberefGerrityes
kvmfornfvGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
laasGerrityes
laas-reflabGerrityes
lsoapiGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
modelsGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
moonGerrit
movieGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
multisiteGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
netreadyGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
nfvbenchGerrityes
octopusGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
onosfwGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
openretrieverGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
operaGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
opnfvdocsGerrityes
opnfvtscGerrit

Cedric Ollivier  :

  • not used
  • Gerrit must be set as RO
orchestraGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
oscarGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
ovn4nfvGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
ovn4nfv-k8s-pluginGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
ovnoGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
ovsnfvGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
parserGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
pharosGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
pharos-toolsGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
pinpointGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
policytestGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
predictionGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
promiseGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
puppet-barometerGerrit
qtipGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
relengGerrityes
releng-anteaterGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
releng-testresultsGerrityes
releng-utilsGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
releng-xciGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
releng-xci-scenariosGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
rocketGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
rsGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
samplevnfGerrityes
sandboxGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
sandbox-zuul-configGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
sandbox-zuul-untrustedGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
sdnvpnGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
securedlabGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
securityscanningGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
sfcGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
snapsGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
spark-model-runnerGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
stor4nfvGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
storperfGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
testGerrit

Cedric Ollivier  :

  • LFN sandbox ??
  • must be deleted
test/testGerrit

Cedric Ollivier  :

  • LFN sandbox ??
  • must be deleted
test/test1Gerrit

Cedric Ollivier  :

  • LFN sandbox ??
  • must be deleted
test2Gerrit

Cedric Ollivier  :

  • LFN sandbox ??
  • must be deleted
thothGerrit

yes

vesGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
vineperfGerrityes
vnf_forwarding_graphGerrit
Cedric Ollivier  :
  • is archived
  • Gerrit must be set as RO
vswitchperfGerrit
yardstickGerrit

Cedric Ollivier  :

  • is archived
  • Gerrit must be set as RO
CNTTGitHub

Gergely Csatari :

  • This was moved to anuket-project/anuket-specification and it is active
 anuket-project/sphinxcontrib-relative-link-correctorGitHub

Cedric Ollivier

  • this shouldn't be hosted in CNTT.
  • Why not use the contributor's repo?

Gergely Csatari 

  • It was created to support CNTT doc compilation from md not relevant anymore. I can move it to an other home if Anuket does not want it.
sphinxcontrib-readme-to-indexGitHub

Cedric Ollivier 

  • this shouldn't be hosted in CNTT.
  • Why not use the contributor's repo?

Gergely Csatari 

  • It was created to support CNTT doc compilation from md not relevant anymore. I can move it to an other home if Anuket does not want it.
sphinxcontrib-direct-copyGitHub

Cedric Ollivier 

  • this shouldn't be hosted in CNTT.
  • Why not use the contributor's repo?

Gergely Csatari 

  • It was created to support CNTT doc compilation from md not relevant anymore. I can move it to an other home if Anuket does not want it.
NetreadyGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO if it's not done already
  • this Gitlab repo mustn't have been created and must be removed asap
SnapsGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO if it's not done already
  • this Gitlab repo mustn't have been created and must be removed asap
SfcGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
SdnvpnGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
QtipGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
PromiseGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
PredictionGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
ParserGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
Ovn4nfv K8s PluginGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
Ovn4nfvGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
OpenretrieverGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
OnosfwGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
OctopusGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
MultisiteGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
LsoapiGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
KvmfornfvGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
Ipv6GitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
InspectorGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
GenesisreqGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
GenesisGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
Compass4nfvGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
Compass ContainersGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
YardstickGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
VESGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
FastPathMetricsGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap

Emma Foley this was the SFQM project repo, renamed to Barometer circa 2016

EscalatorGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
DPACCGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
DominoGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
DaisyGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
CPerfGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
CopperGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
OperaGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
VNF Forwarding GraphGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
JOIDGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
OVSNFVGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
CNTTGitLab

Cedric Ollivier :

  • this repo is obsolete which is a big concern!
  • at worst this repo must be automatically synced as we have done for OPNFV projects in Github
  • I would have recommended not to create it until any TSC desicion.
BottlenecksGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
AvailabilityGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
AutoGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
FastDataStacksGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
Apex-Puppet-TripleOGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
FuelGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
ApexGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
ArmbandGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
Pharos-ToolsGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
Stor4NFVGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
DoctorGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
VinePerfGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
PharosGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
relengGitLab

Cedric Ollivier :

  • no point as Releng depends on Gerrit
  • this Gitlab repo mustn't have been created and must be removed asap
vswitchperfGitLab

Cedric Ollivier :

  • is archived (see vineperf)
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
storperfGitLab

Cedric Ollivier :

  • is archived
  • Gerrit must be set as RO
  • this Gitlab repo must be removed asap
samplevnfGitLab
opnfvdocsGitLab
nfvbenchGitLabcurrently mirror of gerrit
laas-reflabGitLabcurrently mirror of gerrit
laasGitLabcurrently mirror of gerrit
kuberefGitLabcurrently mirror of gerrit
functest-xtestingGitLab

Cedric Ollivier :

  • basically mislead the enduser (it would remain in Gerrit) and the contributor doesn't have any right there
  • this Gitlab repo mustn't have been created and must be removed asap
functest-kubernetesGitLab

Cedric Ollivier :

  • basically mislead the enduser (it would remain in Gerrit) and the contributor doesn't have any right there
  • this Gitlab repo mustn't have been created and must be removed asap
functestGitLab

Cedric Ollivier :

  • basically mislead the enduser (it would remain in Gerrit) and the contributor doesn't have any right there
  • this Gitlab repo mustn't have been created and must be removed asap
dovetail-webportalGitLab

Cedric Ollivier :

  • is it still active (last change was done many months ago) ?
  • this Gitlab repo could be removed

Dan Xu :

  • It's mirror of Gerrit
  • Not active, could be removed
dovetailGitLab

Cedric Ollivier :

  • is it still active (last change was done many months ago) ?
  • this Gitlab repo could be removed

Dan Xu :

  • It's mirror of Gerrit
  • Not active, could be removed
cirv-spirentGitLab

Cedric Ollivier :

  • is it still active (last change was done many months ago) ?
  • this Gitlab repo could be removed
cirv-sdvGitLab

Cedric Ollivier :

  • is it still active (last change was done many months ago) ?
  • this Gitlab repo could be removed
cirv-rapidGitLab

Cedric Ollivier :

  • is it still active (last change was done many months ago) ?
  • this Gitlab repo could be removed
cirv-hdvGitLab

Cedric Ollivier :

  • is it still active (last change was done many months ago) ?
  • this Gitlab repo could be removed
cirvGitLab

Cedric Ollivier :

  • is it still active (last change was done many months ago) ?
  • this Gitlab repo could be removed
BarometerGitLabcurrently mirror of gerrit
CalipsoGitLab

Cedric Ollivier :

  • was archived before any GitLab discussion
  • Gerrit must be set as RO
  • this Gitlab repo mustn't have been created and must be removed asap
AirshipGitLab

Cedric Ollivier :

  • is archived
  • Gerrit must be set as RO
  • this Gitlab repo must be removed asap

Toc

Logistics

  • Conference time: November 15 – 16, 2022
  • Conference place: Seattle, WA
  • CFP deadline: Friday, July 8 at 11:59 PM PDT

Proposal template

  • Speaker info:
    • Primary Speaker Full Name
    • Primary Speaker Company
    • Primary Speaker Job Title
    • Primary Speaker Email
    • Primary Speaker Country of Residence
    • Primary Speaker Biography (provide a biography that includes your employer (if any), ongoing projects and your previous speaking experience)
    • Primary Speaker Twitter Handle
    • Primary Speaker LinkedIn Profile
    • What gender does the primary speaker identify with?
    • Does the primary speaker identify as a person of color? 
    • If the primary speaker identifies with any other underrepresented group (disability, LGBTQIA+, etc.) please indicate below.
  • Select a Track
  • Type of Submission

  • What Skill Level is this Best Suited for?
  • Abstract Title (If your talk is selected, the Abstract Title you choose will be the Title shown in the conference schedule; often what attendees use as a starting point to determine if they will be interested in the talk. Choose your title carefully - make sure that it accurately describes what your talk will cover. )
  • Abstract (Provide an abstract that briefly summarizes your proposal. Provide as much information as possible about what the content will include. Do not be vague. This is the description that will be posted on the website schedule if your talk is selected, so be sure to spell check, use complete sentences (and not just bullet points), and write in the third person (use your name instead of “I”).)
  • Audience (Describe who the audience is and what you expect them to gain from your presentation.)
  • Benefits to the Ecosystem (Tell us how the content of your presentation will help better the ecosystem. (We realize that this can be a difficult question to answer, but as with the abstract, the relevance of your presentation, and why people should attend the session, is just as important as the content).)
  • Audience Engagement (In keeping with the spirit of bringing the “hallway track” into the program, please tell us how you intend to engage with the audience to foster interaction and collaboration.)
  • Have you given this presentation before?
  • If your session is accepted, would you be open to our PR team contacting you about speaking with media and press onsite?
  • Additional Details & Speaker Agreements
  • Travel Funding
  • Code of Conduct
  • Slide Deadline Agreement

Draft proposals

How to find a way to a harmonized and collaborative CNF conformance verification?

  • Status: Submitted
  • Speaker info: Georg Kunz , Gergely Csatari 
  • Select a Track
  • Type of Submission

  • What Skill Level is this Best Suited for?
  • Abstract (Provide an abstract that briefly summarizes your proposal. Provide as much information as possible about what the content will include. Do not be vague. This is the description that will be posted on the website schedule if your talk is selected, so be sure to spell check, use complete sentences (and not just bullet points), and write in the third person (use your name instead of “I”).)

    Cloud infrastructure and workload verification has a history in the telecom industry. As the workloads are dealing with extreme amount of traffic and/or extreme low latency requirements it is natural that they are more sensitive to their cloud platform than other applications. To decrease the cost of integration and expensive surprises during deployment there is a need to agree on what a telecom application can expect from its runtime environment and there is a need to certify if the applications expectations are correct and the platform can fullfill the expectations. Anuket defines a set of application requirements in its Kubernetes based Reference Architecture and plans to build the certification for it in its Anuket Assured certification program while CNCF announced in the 2022 KubeCon EU their CNF Certification program. While Anuket RA2 defines an opinionated Kubernetes distribution and its workload requirements ensure that the CNF is able to run in the distribution, the CNF Certification tests the adherence to cloud native principles. For a CNF vendor the ideal situation would be to run only one set of open source CNF certification tests, but due to the different targets of these certifications this is not the case today.
    In this presentation Georg and Gergely will discuss how these two communities could work together to achieve a good collaboration between the initiatives, how to draw the limit of the testings scope and how to minimalize the testing overhead for CNF vendors. For this the presenters will invite a set of key community members to disucss what is the common denominator of the tests and focus on the distinguishing parts.
  • Audience (Describe who the audience is and what you expect them to gain from your presentation.)

CNF vendors and network operators who are using the CNF-s and paying the integration bill.

  • Benefits to the Ecosystem (Tell us how the content of your presentation will help better the ecosystem. (We realize that this can be a difficult question to answer, but as with the abstract, the relevance of your presentation, and why people should attend the session, is just as important as the content).)

Due to the flexibility of cloud platforms and the sensitivity of CNF-s the integration of CNF-s and their platforms is a continuous issue. The industry tries to address this with different conformance programs. This panel is about the collaboration of these certification programs.

  • Audience Engagement (In keeping with the spirit of bringing the “hallway track” into the program, please tell us how you intend to engage with the audience to foster interaction and collaboration.)

We plan to invite some key contributors form the CNCF CNF Certification program, Anuket Assured and Anuket RC2 programs and initiate a discussion in the last part of the presentation.

  • Have you given this presentation before?

No

  • If your session is accepted, would you be open to our PR team contacting you about speaking with media and press onsite?

Yes

  • Additional Details & Speaker Agreements
  • Travel Funding
  • Code of Conduct
  • Slide Deadline Agreement
  • Panelists (4+1): Georg Kunz (Rihab), Gergely Csatari , Heather, Taylor (tentative), Olivier Smith  

How difficult can be to define a Kubernetes reference stack for CNF-s?

  • Status: submitted
  • Speaker info: Gergely Csatari , Riccardo Gasparetto Stori 
    • Primary Speaker Full Name
    • Primary Speaker Company
    • Primary Speaker Job Title
    • Primary Speaker Email
    • Primary Speaker Country of Residence
    • Primary Speaker Biography (provide a biography that includes your employer (if any), ongoing projects and your previous speaking experience)
    • Primary Speaker Twitter Handle
    • Primary Speaker LinkedIn Profile
    • What gender does the primary speaker identify with?
    • Does the primary speaker identify as a person of color? 
    • If the primary speaker identifies with any other underrepresented group (disability, LGBTQIA+, etc.) please indicate below.
  • Select a Track
  • Type of Submission

  • What Skill Level is this Best Suited for?
  • Abstract (Provide an abstract that briefly summarizes your proposal. Provide as much information as possible about what the content will include. Do not be vague. This is the description that will be posted on the website schedule if your talk is selected, so be sure to spell check, use complete sentences (and not just bullet points), and write in the third person (use your name instead of “I”).)

“Anuket specifications are a family of LFN initiatives to design, implement and test the conformance for Telco Cloud infrastructures. The aim of the specification work is to decrease the time and money needed to integrate Telco Cloud infrastructures and their workloads (Network Functions). Anuket specifications consist of a technology agnostic Reference Model (RM) and two technology-specific Reference Architectures and Reference Implementations, for OpenStack and Kubernetes, aligning with the Anuket Reference Model. In this talk Riccardo and Gergely will describe how RA2, the Kubernetes based Reference Architecture is enabling Telecommunications Providers and Vendors to deploy Containerised Network Functions (CNFs) on Kubernetes efficiently, and what’s new in Moselle, the current Anuket release, and what are the plans for the next one, Nile.”

  • Audience (Describe who the audience is and what you expect them to gain from your presentation.)

Architects in telecom network operators and in CNF and cloud platform vendors.

  • Benefits to the Ecosystem (Tell us how the content of your presentation will help better the ecosystem. (We realize that this can be a difficult question to answer, but as with the abstract, the relevance of your presentation, and why people should attend the session, is just as important as the content).)

This talk is a generic information sharing about Anuket RA2, a release update on its Moselle additions and information about the plans for Nile. 

  • Audience Engagement (In keeping with the spirit of bringing the “hallway track” into the program, please tell us how you intend to engage with the audience to foster interaction and collaboration.)

Participate in the hallway track after the session.

  • Have you given this presentation before?

A very similar about the previous release.

  • If your session is accepted, would you be open to our PR team contacting you about speaking with media and press onsite?

Yes

  • Additional Details & Speaker Agreements
  • Travel Funding
  • Code of Conduct
  • Slide Deadline Agreement

Working towards a shared model for Telecom Cloud Infrastructure, an Overview of Anuket

  • Status: submitted
  • Speaker info: Beth Cohen and Gergely Csatari 
  • Select a Track
  • Type of Submission

  • What Skill Level is this Best Suited for?
  • Abstract (Provide an abstract that briefly summarizes your proposal. Provide as much information as possible about what the content will include. Do not be vague. This is the description that will be posted on the website schedule if your talk is selected, so be sure to spell check, use complete sentences (and not just bullet points), and write in the third person (use your name instead of “I”).):

Anuket grew out of a marriage of a requirements task force (CNTT) and a infrastructure test project (OPNFV).   The idea is to create a  single project that not only defines the reference requirements for infrastructure, but also creates and supports the code needed to test and valid these infrastructures,  As you can imagine, it is an LFN project with a difficult mission. In this session, the co-chairs of the Anuket TSC will explain the structure of Anuket sub-projects, the activities in these different sub-projects and how all of this works towards the mission. The presentation will cover release highlights from the latest Moselle release and provide some insights to the targets for the ongoing Nile release.

  • Audience (Describe who the audience is and what you expect them to gain from your presentation.)

Anuket is a project that was designed to be a joint effort by and for Telecom vendors and operators.  This session will allow those who are Anuket curious to learn more about it a and those always wanted to ask what Anuket was but never had the chance.

  • Benefits to the Ecosystem (Tell us how the content of your presentation will help better the ecosystem. (We realize that this can be a difficult question to answer, but as with the abstract, the relevance of your presentation, and why people should attend the session, is just as important as the content).)

Actors in the telecom industry need better understanding of the mission of Anuket and how the project works to make this mission reality.  Anuket is a project that supports other projects in LFN and across the Open Standards community in general.

  • Audience Engagement (In keeping with the spirit of bringing the “hallway track” into the program, please tell us how you intend to engage with the audience to foster interaction and collaboration.)

This is intended as a fully interactive session with lots of opportunities for the audience to participate and ask questions.

  • Have you given this presentation before?

No

  • If your session is accepted, would you be open to our PR team contacting you about speaking with media and press onsite? Yes
  • Additional Details & Speaker Agreements
  • Travel Funding
  • Code of Conduct
  • Slide Deadline Agreement


Day 0, 1 and 2 in the life of an Edge Computing Deployment

  • Speaker info: Beth Cohen and Gergely Csatari Ildiko Vancsa 
  • Select a Track
  • Type of Submission

  • What Skill Level is this Best Suited for?
  • Abstract (Provide an abstract that briefly summarizes your proposal. Provide as much information as possible about what the content will include. Do not be vague. This is the description that will be posted on the website schedule if your talk is selected, so be sure to spell check, use complete sentences (and not just bullet points), and write in the third person (use your name instead of “I”).):

Theory and use cases are important, but what happens when the rubber hits the road, or in other words, when your edge infrastructure is ready to be deployed and run in production.  During this session we will look at the dependencies and requirements for successfully launching and managing edge architectures in the field. Grouped around the Telecom concept of what happens over the three "days" it takes to take an edge infrastructure from development to deployment and into production. Starting from “Day 0”, the preparation/development phase before the deployment so to speak, and moving into “Day 1”, the actual deployment into the field, followed by “Day 2” or Day N (depending on who you talk to) which includes the management of the systems in production, each step calls for different components that interrelate with each other. 

    • Day-0: "product development". Focus on bootstrapping, develop templates
    • Day-1: "service delivery". Instantiate/customize templates according to customer needs and deploy them. Validation.
    • Day-2: "production/operations"
  • Audience (Describe who the audience is and what you expect them to gain from your presentation.)

Any person who is serious about Edge and operating an edge deployment in production.

  • Benefits to the Ecosystem (Tell us how the content of your presentation will help better the ecosystem. (We realize that this can be a difficult question to answer, but as with the abstract, the relevance of your presentation, and why people should attend the session, is just as important as the content).)

The Open Source community tends to focus  on Day 0 or requirements, but increasingly the telecom industry is looking for community to standardize operations and deployment activities.  While the nomenclature is borrowed from the  telecommunications industry, but the steps are applicable on a much wider scale and many more industries

  • Audience Engagement (In keeping with the spirit of bringing the “hallway track” into the program, please tell us how you intend to engage with the audience to foster interaction and collaboration.)

This is intended as a fully interactive session with lots of opportunities for the audience to participate and ask questions.

  • Have you given this presentation before?

No

  • If your session is accepted, would you be open to our PR team contacting you about speaking with media and press onsite? Yes
  • Additional Details & Speaker Agreements
  • Travel Funding
  • Code of Conduct
  • Slide Deadline Agreement

Building an Open Reference Cloud Native Platform for Telco Cloud -- Benefits Cost Saving Throughout whole process of development, testing and deployment.

  • Speaker info:
    • Primary Speaker Dan Xu
    • Primary Speaker Company Huawei Technologies Co., Ltd.
    • Primary Speaker Title: Software Engineer
    • Primary Speaker Email: xudan16@huawei.com
    • Primary Speaker Country of Residence China
    • Primary Speaker Biography (provide a biography that includes your employer
      • Dan Xu is working in Huawei Technologies Co., Ltd for more than 6 years. I used to work on LFN OPNFV community for about 4 years and was the PTL of project Dovetail. Then she contributed in EdgeGallery community to be the leader of its CI/CD development for about 2 years. This year she is back to LFN Anuket community as the PTL of RI2 task force to do the k8s and infrastructure deployment. Dan Xu has given presentations and lead discussions about Dovetail Projects in ETSI Plugtest and OPNFV Plugfest for several times.

         
    • Primary Speaker Twitter Handle: None
    • Primary Speaker LinkedIn profile: None
    • What gender does the primary speaker identify with? Female
    • Does the primary speaker identify as a person of color? Asian
    • If the primary speaker identifies with any other underrepresented group (disability, LGBTQIA+, etc.) please indicate below. None
  • Select a Track
  • Type of Submission

  • What Skill Level is this Best Suited for?
  • Abstract Title
    • Cost Benefits of Building an Open Reference Cloud Native Platform for Telco Cloud

  • Abstract 
    • Kubernetes-based Reference Implementation (RI2) is a project in LFN Anuket which focuses on providing reference k8s based Telco Cloud infrastructures for Telco Providers, Telco Cloud vendors and CNF software vendors. As a bridge of providers and vendors, RI2 gives providers a reference platform to test and choose both commercial Cloud infrastructures and CNFs running on it. Also it serves as a reference platform for Cloud vendors and CNF vendors to develop and test against. With this bridge, both providers and vendors can reduce the time and cost for developing, testing and integrating Telco Cloud infrastructures and CNFs. In this session, Dan Xu and Scot will give an introduction about what RI2 is, how to use RI2 to deploy a reference k8s based Telco Cloud infrastructure on bare metal and virtual machine, what’s new in Anuket Nile release, and what benefits users can get from RI2. Also will give a demo about how to use the tool kuberef to setup the k8s infrastructure on Baremetal.

  • Audience 
    • All suppliers/operators that are considering the ways to reduce deployment costs of their cloud native Network/Network functions
  • Benefits to the Ecosystem (Tell us how the content of your presentation will help better the ecosystem.
    • Adoption of the Anuket specifications will improve the Time to Install and Market for Operators and Suppliers 
  • Audience Engagement (In keeping with the spirit of bringing the “hallway track” into the program, please tell us how you intend to engage with the audience to foster interaction and collaboration.)
  • Have you given this presentation before?

No

  • If your session is accepted, would you be open to our PR team contacting you about speaking with media and press onsite?

Yes

  • Additional Details & Speaker Agreements
  • Travel Funding
  • Code of Conduct
  • Slide Deadline Agreement

Cultural Transition: Open Source Across Telecom and Hyperscalers

  • Speaker info:
    • Primary Speaker Scot Steele
    • Primary Speaker Microsoft
    • Primary Speaker Sr. Program Manager
    • Primary Speaker scotsteele@microsoft.com
    • Primary Speaker USA
    • Primary Speaker Biography (provide a biography that includes your employer (if any), ongoing projects and your previous speaking experience)
    • Primary Speaker Twitter Handle
    • Primary Speaker www.linkedin.com/in/scotsteele
    • What gender does the primary speaker identify with? Male
    • Does the primary speaker identify as a person of color? No
    • If the primary speaker identifies with any other underrepresented group (disability, LGBTQIA+, etc.) please indicate below. None
  • Select a Track
  • Type of Submission

  • What Skill Level is this Best Suited for?
  • Abstract Title Cultural Transition: Open Source Across Telecom and Hyperscalers
  • Abstract 

    As telecommunications is a backbone service to society the industry has been highly regulated since its inception. Thus Telcos must demonstrate a culture of high levels of operational availability, reliability, and recoverability in performance and cost management. Hyperscalers are relatively new entities in the communications space that leverage a more collaborative/adoptive culture with lesser concern for the operational efficiency. Open-Source specifications/code, and Hyperscaler partnerships can provide new features and greater capacities to their consumers with reduced time to market and lower capital costs. However, deltas between the operational efficiency culture of operators and the collaboration/adoption of hyperscalers could inhibit success on either side of the relationship. We posit that resolving conflict between cultures would allow consumer access to beneficial features that would improve the operator’s bottom line at a time when labor and cost challenges impact the industry’s overall growth and health.

    In this discussion, we ask the question “How can Open-Source impact and affect culture to support telco industry growth and health?” We will explore insights and possible paths through the lens of a significant and multi-faceted telco hyperscaler partnership.

  • Audience: anyone Involved with technology selection, deployment, management, and leadership in the telco industry
  • Benefits to the Ecosystem Transforming the culture of the industry to a more trusting, collaborative, and adoption mentality will provide numerous benefits to all participants through the improving the speed of development and adoption. This will generally support lower cost of implementation.
  • Audience Engagement (In keeping with the spirit of bringing the “hallway track” into the program, please tell us how you intend to engage with the audience to foster interaction and collaboration.)
  • Have you given this presentation before? o
  • If your session is accepted, would you be open to our PR team contacting you about speaking with media and press onsite? Yes
  • Additional Details & Speaker Agreements
  • Travel Funding
  • Code of Conduct
  • Slide Deadline Agreement



WhatWhat to doHow to get thereWho makes the next stepStatus
https://docs.opnfv.org/
  • Raise a simple DNS redirect request to LF IT
  • Also we should add a pointer to the original readthedocs OPNFV Jerma documentation


gerrit.opnfv.org/
  • Raise a request to LF IT

https://www.opnfv.org/
  • Raise a simple DNS redirect request to LF IT

https://github.com/cntt-n/cntt
  • Get the Anuket org
  • Rename the org to anuket
  • Rename the repo to specifications
  • Get Sphinx credentials
  • Reconfigure Sphinx
  • Archive the sphinx extensions

Anuket on GitLab
  • Remove dead repos from GitLab
  • Collect the repos what we should remove from GitLab
  • Remove them

cntt.readthedocs.io/



LF Networking
  • Webpage contains OPNFV

Generic page to record issues
  • A confluence page to collect remaining leftovers
    • Move this table also there
  • Create a confleunce and move this table there
Gergely CsatariDone
  • file an LF IT issue about this.
Issue filed. Now we are waiting for LF IT.

Intro

LFN projects have the possibility to participate in review by the GB in every 6 months. This page was created to collect information about the 2022 mid year review by Anuket TSC.

Timeline

  • Apr 15: Notification, template distribution & invites
  • May 6: Completed slides are due in to your Project’s TCA
  • May 10: Assembled GB deck completed by TCAs
  • May 11: Final deck review by staff
  • May 12: deck distributed to the GB
  • May 18: TSC Chairs (or delegate) present to the GB

Final Presentation

Updated with input from TSC April 26 meeting. I included the notes from below and the notes from the email discussions.

Issues to address

  • Response from GB companies to the Anuket Assured staffing request on the 2021 October review

EUAG is NOT the right place to validate Anuket's relevance, as I am planning on sunsetting the group as it has little participation and has outlived its usefulness.  I think that we can gain validation from within Anuket (the telco members) and the hopeful success of the Anuket Assured program.


Progress Against 2022 Project Objectives:

  • I think we are okay with producing the releases -- Agree the releases have been more or less on time and had significant new requirements and features.
  • We did not grew the technical community. Without knowing the numbers I have a feeling that we are losing technical contributors. I think this should be indicated -- Agree, my sense is that we have lost some of the less involved members, many reasons for it, but it is something that we should mention as an issue.
  • We are working on the conversion and evolution. It is slower than what I’ve expected, but it is progressing. -- Yup.
  • Validation: I think there was no progress here. We should indicate this to the GB and request feedback. -- I think that the launch of the ANuket Assured program was a step in the right direction, it just has not gotten the traction that we expected.  Or rather it has been going slower than expected.
  • Linking the RC-s and Anuket Assured: I do not have any insights on this. Any opinion here? -- Needs more coordination.  I think that the Anuket Assured program is good, needs more publicity and better alignment/integration with the RC work.  The RC workstreams have been understaffed so that is something we should mention to the GB.

 

Key Call Outs for the LFN Governing Board (Gergely’s opinion, please comment):  Beth's adds

  • What our community is doing well
    • Producing releases
    • Doing document conversion at the same time
    • Broad support across the telecom and vendors in the community
  • Areas that we can improve upon
    • There are some sub-projects with very low resources. Even some are down to a single person, which makes them vulnerable. This is very bad bus factor.  Need to review the viability of some of the sub-projects and possibly archive them if they are no longer supportable or supported by the community.
    • This is a documentation heavy project, we still do not have a functioning doc project and doc PTL
  • Where we need help from the GB
    • We need help from the GB member companies in supporting and validating that Anuket project is in alignment with their needs and requirements.
    • We need help from the GB member companies in staffing the project with concrete resources. The same request was formulated in the previous review with no followup or response from the GB representatives.
    • We would like to have better communication between the LFN Projects and the GB.

Stats

References



  1. Template to be used: LFN Project Input for the Board template (1).pptx
  2. Material the TSC provided for the previous round of project reviews: 2021-10-06 Anuket Project to GB-rev.pptx
  3. Material presented for the GB during the previous round of project reviews, for reference: LFN Governing Board Meeting Day 2 - (Oct 20) Project Reviews (1).pdf




Anuket TSC decided to require a CLA for incoming contributions. There is a CLA text proposed by LF for ICLA and CCLA here.

Some TSC members requested the comparison of the old CLA and the new CLA. As OPNFV had no CLA, but it had IPR related sections in its Charter the closest thing to fulfill this request is to compare the IPR related sections of the OPNFV Charter with the proposed CLA texts.

The result of the comparison is here: OPNFV Charter vs Anuket CLA.pdf

This page contains an analyzis on the list of test cases listed in the CNCF CNF Testsuite to determine if RA2 should contain related workload requirements.


Each test should be clearly documented - there is no documentation currently.
The test case description should be written describing expectation clearly 

(eg Test if the CNF crashes when disk fill occurs

should be written as

Test that the CNF does not crash when disk fill occurs)


Notes


Issues raised to CNCF CNF Testsuite during this work

IssueStatus
#1242 - [BUG]: Test case descriptions are not clearOpen, requested to create separate issues.
[BUG]: Link for rolling-update-replication-controller is broken
[BUG]: Bugs in "To check if the CNF is compatible with different CNIs"Fix merged in [BUG] 1243 1244 usage doc URL and description fixes #1245

[BUG] Test titles are ambigous

Work on a fix is ongoing

[BUG]: Some tests are not clear on service types

Open, discussion is ongoing in the issue.

[BUG]: Elastic volume is not defined

Open, discussion is ongoing in the issue.

[BUG]: Test if the CNF crashes when node drain and rescheduling occurs. All configuration should be stateless test should be separated to two cases

Open, discussion is ongoing in the issue.

[BUG]: Crashing is not defined in several test cases

Open, discussion is ongoing in the issue.

[BUG] list of mandatory PaaS components is not clarified and justified

Closed, discussion is ongoing in the issue

[BUG] Network policies are under defined


#1321 - [Documentation]: Upgrade related terms are not explained in the the testcase descriptions

Subcase of #1242

#1322 - [Documentation]: To check if a CNF uses Kubernetes alpha APIs test case description does not define when the tescase pass

Subcase of #1242

#1337 - [Documentation]: reasonable image size test description is unclear

Subcase of #1242

#1338 - [Documentation]: Description of To check if the CNF have a reasonable startup time are not clear

Subcase of #1242

#1339 - [Documentation]: Rationale of To check if the CNF has multiple process types within one container: single_process_type is incorrect 

Subcase of #1242

#1340 - [Documentation]: Rationale of To test if the CNF uses local storage is unclear

Subcase of #1242

#1341 - [Documentation]: Description of To test if the CNF uses elastic volumes is not clear 

Subcase of #1242

#1409 - [BUG]: Duplicate tests about privileged containers 


The analyzis


TestId and Category in CNF ConformanceNoteVerdict
To test the increasing and decreasing of capacity

Rationale

increase_decrease_capacity
essential

Do we request horizontal scaling from all CNF-s?

Most (data plane, signalling, etc) but not all (eg OSS)

should be optional, or just fail if it scales incorrectly in case the CNF scales

(ra2.app.011)

Test if the Helm chart is published

Rationale

helm_chart_publishedWe should first decide on CNF packaging. RA2 can stay neutral, follow the O-RAN/ONAP ASD path or propose own solution.

should be fine - no HELM specs in RA2 today, unless some incompatible CNFs packaging specs (unlikely)


(ra2.app.012, ra2.app.013)

Test if the Helm chart is valid

Rationale

helm_chart_valid
Test if the Helm deploys

Rationale

helm_deployThis should be more generic, like testing if the CNF deploys.
Test if the install script uses Helm v3

Rationale



To test if the CNF can perform a rolling update

Rationale

rolling_updateAs there's some CNFs that actually use rolling update without keeping the service alive (because they require some post-configuration), the test should make sure that there is service continuity. this might just be a health probe or testing the k8s service, or something sufficiently straightforward. In other words, CNF service/traffic should work during the whole process (before during and after a rolling upgrade)Needed (ra2.app.014)
To check if a CNF version can be downgraded through a rolling_version_change

Rationale

rolling_version_change

It is not clear what is the difference between a rolling downgrade and a rolling version change.

A: Defined in the external docs in the usage guide. Some these are relevant for a ReplicaSet some of them are for a Deployment.

Maybe when you request an arbitrary version?


To check if a CNF version can be downgraded through a rolling_downgrade

Rationale

rolling_downgradeSame as above?Needed (ra2.app.015)
To check if a CNF version can be rolled back rollback

Rationale

rollbackIt is not clear what is the difference between a rolling downgrade and a rolled back rollback.
To check if the CNF is compatible with different CNIs

Rationale

cni_compatible

This covers only the default CNI, does not cover the metaplugin part.

Need additional tests for cases with multiple interfaces.

Ok but needs additional tests for multiple interfaces

(ra2.app.016)

(PoC) To check if a CNF uses Kubernetes alpha APIs

Rationale

alpha_k8s_apis

Alpha API-s are not recommended by ra2.k8s.012. It fails with alpha

PoC: it might happen that these testcases are removed from the Testsuite and this will be not part of the CNF certification.  Probably will be a bonus case.

Ok

(ra2.app.017)

To check if the CNF has a reasonable image size

Rationale

reasonable_image_size

It passes if the image size is smaller than 5GB.

A: Whenever it is possible tests are configurable or parameters can be overwritten from the outside. This will be part of the CNF Certification. Valid for each image referred from the Helm chart.


Ok but should be documented or configurable?

issue to clarify name

should read "pod image size"

(ra2.app.018)

To check if the CNF have a reasonable startup time

Rationale

reasonable_startup_time

It is not clear what reasonable startup time is. It is about the startup time of the microservices inside the CNF.

Should be Check if all the Pods in the CNF have a reasonable startup time.

A: Reasonable time is 60 sec.

Ok but should be documented or configurable?

issue to clarify name

should read "pod startup time"

(ra2.app.019)

To check if the CNF has multiple process types within one container

Rationale

single_process_type
essential

Containers in the CNF should have only one process type.

even for exposing an API a separate process is required - should this test if the number of processes is less than a certain number instead?

Multiple process types can lead also to memory leaks.

A: Gergely to provide examples where this requirement restricts the architecture of telco apps. 

Not required

What's the rationale?

issue to clarify name

do not agree with rule

To check if the CNF exposes any of its containers as a service

Rationale

service_discovery

Service type what?

RA2 mandates that clusters must support Loadbalancer and ClusterIP, and should support Nodeport and ExternalName

Should there be a test for the CNF to use Ingress or Gateway objects as well?

May need tweaking to add Ingress?

issue to clarify service types

To check if the CNF has multiple microservices that share a database

Rationale

shared_database

Clarify rationale? In some cases it is good for multiple Microservices to share a DB, eg when restoring the state of a transaction from a failed service.

Also good to have a shared DB across multiple services for things like HSS etc.

should not be required

Clarify

issue to clarify name


Test if the CNF crashes when node drain and rescheduling occurs. All configuration should be stateless

Rationale

node_drain

essential

CNF should react gracefully (no loss of context/sessions/data/logs & service continues to run) to eviction and node draining

The statelessness test should be made independent & Should be skipped for stateful pods eg Dns

"crashes" actually means that either the liveness or readiness probe fails - this should be made explicit and the presence of probes should be made mandatory - added issue in RA2

Needed - but replace "crash" with "react gracefully" (no loss of context/sessions/data/logs & service continues to run)

issue: Statelessness test should be separate

(ra2.app.020)

To test if the CNF uses a volume host path

Rationale

volume_hostpath_not_found

should pass if the cnf doesn't have a hostPath volume

What's the rationale?

- A: When a cnf uses a volume host path or local storage it makes the application tightly coupled to the node that it is on.

ok - just fix title

(ra2.app.007)

To test if the CNF uses local storage

Rationale

no_local_volume_configuration

should fail if local storage configuration found

What's the rationale?

ok, add to RA2 (attach to previous)

ok - needed 

(ra2.app.021)

To test if the CNF uses elastic volumes

Rationale

elastic_volumes

should pass if the cnf uses an elastic volume

What's an elastic volume? Does this mean Ephemeral? Or is this an AWS-specific test?

There should be a definition of what an elastic volume is (besides ELASTIC_PROVISIONING_DRIVERS_REGEX)

What's an elastic volume? Does this mean Ephemeral? Or is this an AWS-specific test?

issue to clarify elastic volume

To test if the CNF uses a database with either statefulsets, elastic volumes, or both

Rationale

database_persistence

A database may use statefulsets along with elastic volumes to achieve a high level of resiliency. Any database in K8s should at least use elastic volumes to achieve a minimum level of resilience regardless of whether a statefulset is used. Statefulsets without elastic volumes is not recommended, especially if it explicitly uses local storage. The least optimal storage configuration for a database managed by K8s is local storage and no statefulsets, as this is not tolerant to node failure.

There should be a definition of what an elastic volume is (besides ELASTIC_PROVISIONING_DRIVERS_REGEX)

What's an elastic volume? Does this mean Ephemeral? Or is this an AWS-specific test?

issue to clarify elastic volume

Test if the CNF crashes when network latency occurs

Rationale

pod_network_latency

How is this tested? Where is the test running? Some traffic against a service? Latency should be configurable (default is 2s)?

What should happen if latency is exceeded? Should this be more stringent than "not crashing?"

What is the expectation? (not crashing = not exit with error code or (better) not stopping to process traffic)

A: Explanation added to https://github.com/cncf/cnf-testsuite/blob/main/USAGE.md#heavy_check_mark-test-if-the-cnf-crashes-when-network-latency-occurs

Check this with RA2 - should be ok

Needed but needs clarification

issue on defining "crashing - it's probes

(ra2.app.028)

Test if the CNF crashes when disk fill occurs

Rationale

disk_fill

What is the expectation? (not crashing = not exit with error code or (better) not stopping to process traffic)

RM/RA2 should add infra monitoring recommendation for disk usage alerting

Needed

issue on defining "crashing - it's probes

(ra2.app.022)

Test if the CNF crashes when pod delete occurs

Rationale

pod_deleteWhat is the expectation? (not crashing = not exit with error code or (better) not stopping to process traffic)

Needed

issue on defining "crashing - it's probes

(ra2.app.023)

Test if the CNF crashes when pod memory hog occurs

Rationale

pod_memory_hog

What is the expectation? (not crashing = not exit with error code or (better) not stopping to process traffic)

title should read "CNF pod runs out of memory"?

RA2 should add recommendation to add pod memory reservation: 

A CNF can fail due to running out of memory. This can be mitigated by using two levels of memory policies (pod level and node level) in K8s. If the memory policies for a CNF are not fine grained enough, the CNFs out-of-memory failure blast radius will result in using all of the system memory on the node.

Needed

issue on defining "crashing - it's probes

(ra2.app.024)

Test if the CNF crashes when pod io stress occurs

Ratoinale

pod_io_stress

What is the expectation? (not crashing = not exit with error code or (better) not stopping to process traffic)

title should read "pod disk I/O"

Needed

issue on defining "crashing

(ra2.app.025)

Test if the CNF crashes when pod network corruption occurs

Rationale

pod_network_corruption

It is not clear what network corruption is in this context. What is the expectation? (not crashing = not exit with error code or (better) not stopping to process traffic)

Rationale explains traffic manipulation: 

A higher quality CNF should be resilient to a lossy/flaky network. This test injects packet corruption on the specified CNF's container by starting a traffic control (tc) process with netem rules to add egress packet corruption.

Needed

issue on defining "crashing - it's probes

(ra2.app.026)

Test if the CNF crashes when pod network duplication occurs

Rationale

pod_network_duplicationIt is not clear what network duplication is in this context. What is the expectation? (not crashing = not exit with error code or (better) not stopping to process traffic)

Needed

issue on defining "crashing - it's probes

(ra2.app.027)

To test if there is a liveness entry in the Helm chart

Rationale

liveness
essential

Liveness probe should be mandatory, but RA2 does not mandate Helm at the moment. (it's in the pod definition rather than helm - maybe fix the title)

RA2 now mandates helm3 - it's the pod definition - added issue to recommend probes in RA2 CH4

Needed

(ra2.app.030)

To test if there is a readiness entry in the Helm chart

Rationale

readiness
essential

Readiness probe should be mandatory, but RA2 does not mandate Helm at the moment. (it's in the pod definition rather than helm - maybe fix the title)

RA2 now mandates helm3 - it's the pod definition - added issue to recommend probes in RA2 CH4

Needed

(ra2.app.031)

To check if logs are being sent to stdout/stderr

Rationale

log_output

essential

optional, as there's no way to accurately figure out if we're missing something from stdout/stderr 

title reads "instead of a log file"

A: RA2 should recommend that the application streams logs out of stdout/stderr

Needed
Add this
To check if prometheus is installed and configured for the cnf

Rationale

prometheus_traffic

There is a chapter for Additional required components (4.10), but without any content. should ra2 mandate prometheus?

A: All the PaaS components are optionally tested, as bonus tests.

RM/RA right now doesn't require specific PaaS tools

Not needed

question on mandatory paas tools

To check if logs and data are being routed through an Unified Logging Layer

Rationale

routed_logs

There is a chapter for Additional required components (4.10), but without any content. should ra2 mandate fluent?

A: All the PaaS components are optionally tested, as bonus tests.

Not needed

question on mandatory paas tools

To check if Open Metrics is being used and or compatible.

Rationale

open_metrics

There is a chapter for Additional required components (4.10), but without any content. should ra2 mandate open metrics?

A: All the PaaS components are optionally tested, as bonus tests.

Not needed

question on mandatory paas tools

To check if tracing is being used with Jaeger

Rationale

tracing

There is a chapter for Additional required components (4.10), but without any content. should ra2 mandate jaeger?

A: All the PaaS components are optionally tested, as bonus tests.

Not needed

question on mandatory paas tools

To check if a CNF is using container socket mounts

container_sock_mounts

essential

what is being tested? Make sure to not mount /var/run/docker.sock, /var/run/containerd.sock or /var/run/crio.sock on the containers?

Needed

(ra2.app.032)

To check if containers are using any tiller images

ie test if it's NOT helm v2?ok if not helm v2
To check if any containers are running in privileged mode

Rationale

privileged_containers

essential

ie NOT privileged?

Needed

issue to clarify name

(ra2.app.033)

To check if a CNF is running services with external IP's
external_ipsdoes this mean "k8s service?" RA2 mandates that clusters must support Loadbalancer and ClusterIP, and should support Nodeport and ExternalName

issue to clarify name

issue to clarify service types

To check if any containers are running as a root user

Rationale

non_root_userie not Root?

Needed

issue to clarify name

(ra2.app.034)

To check if any containers allow for privilege escalation

Rationale

privilege_escalationie not allowed?

Needed

issue to clarify name

(ra2.app.035)

To check if an attacker can use a symlink for arbitrary host file system access

Rationale

symlink_file_system

ok if not

According to the CVE this is not valid anymore in Kubernetes 1.23.

Not needed

issue to clarify name

To check if there are service accounts that are automatically mapped

Rationale

application_credentials

what is the expectation?

Application Credentials: Developers store secrets in the Kubernetes configuration files, such as environment variables in the pod configuration. Such behavior is commonly seen in clusters that are monitored by Azure Security Center. Attackers who have access to those configurations, by querying the API server or by accessing those files on the developer’s endpoint, can steal the stored secrets and use them.

Check if the pod has sensitive information in environment variables, by using list of known sensitive key names. Check if there are configmaps with sensitive information.

Remediation: Use Kubernetes secrets or Key Management Systems to store credentials.

See more at ARMO-C0012

Needed

issue to clarify name
(ra2.app.036)

To check if there is a host network attached to a pod

Rationale

host_networkshould be ok with or without - eg when exposing services via cluster network as opposed to nodeport?

Needed

(ra2.app.037)

To check if there are service accounts that are automatically mapped

Rationale


Disable automatic mounting of service account tokens to PODs either at the service account level or at the individual POD level, by specifying the automountServiceAccountToken: false. Note that POD level takes precedence.

See more at ARMO-C0034

Seems to be a duplicate.
To check if there is an ingress and egress policy defined

Rationale

ingress_egress_blocked

ok - maybe more stringent?

A: There is an answer here: https://github.com/cncf/cnf-testsuite/issues/1282#issuecomment-1081228008

Check this with RA2

issue to have more stringent network policies
 (only allow predefined subnets ie not 0/0 for ingress, only allow limited number of protocols/ports)
To check if there are any privileged containers

Rationale


duplicate?#1409 - [BUG]: Duplicate tests about privileged containers
To check for insecure capabilities

Rationale

insecure_capabilities

what is the expectation?

issue to clarify name
To check for dangerous capabilities

Rationale


what is the expectation?

issue to clarify name
To check if namespaces have network policies defined

Rationale


ok - maybe more stringent? duplicate?issue to have more stringent network policies
To check if containers are running with non-root user with non-root membership

Rationale

non_root_containers

essential

duplicate?

ok

(ra2.app.038)

To check if containers are running with hostPID or hostIPC privileges

Rationale

host_pid_ipc_privilegesok if not

ok if not

(ra2.app.039)

To check if security services are being used to harden containers

Rationale

linux_hardening

what services? should be configurable or optional

Linux Hardening: Check if there is AppArmor, Seccomp, SELinux or Capabilities are defined in the securityContext of container and pod. If none of these fields are defined for both the container and pod, alert.

Remediation: In order to reduce the attack surface, it is recommended to harden your application using security services such as SELinux®, AppArmor®, and seccomp. Starting from Kubernetes version 1.22, SELinux is enabled by default, therefore I do not think that we need to require anything in RA2.

Read more at ARMO-C0055


not needed
To check if containers have resource limits defined

Rationale

resource_policies

essential

ok

ok

(ra2.app.040)

To check if containers have immutable file systems

Rationale

immutable_file_systemsok

ok

(ra2.app.041)

To check if containers have hostPath mounts

Rationale

hostpath_mounts

essential

ok if not

ok, issue to clarify name

(ra2.app.042)

To check if containers are using labels


require_labelsok - maybe mandate some mandatory labels?ok (ra2.app.043)
To test if there are versioned tags on all images using OPA Gatekeeper

Rationale

versioned_tagok 

ok

(ra2.app.044)

To test if there are any (non-declarative) hardcoded IP addresses or subnet masks

Rationale

ip_addresses

ok - there shouldn't be any internal hardcoded nw anyway

This was replaced by hardcoded_ip_addresses_in_k8s_runtime_configuration

ok

(ra2.app.045)

To test if there are node ports used in the service configuration

Rationale

nodeport_not_usedok but service type LB should be better

ok, issue to clarify service types

(ra2.app.046)

To test if there are host ports used in the service configuration

Rationale

hostport_not_used

essential

hostports should not be usedOK
A: Add this to RA2
To test if there are any (non-declarative) hardcoded IP addresses or subnet masks in the K8s runtime configuration

Rationale

hardcoded_ip_addresses_in_k8s_runtime_configuration

essential

Not a duplicate anymore

(ra2.app.045)

A: Doublecheck if ra2.app.045 is aligned with the rationale

To check if a CNF version uses immutable configmaps

Rationale

immutable_configmapok

ok

(ra2.app.047)

Test if the CNF crashes when pod dns error occurs

pod_dns_error

What is the expectation? (not crashing = not exit with error code or (better) not stopping to process traffic)

Not crashing = answering to probes

ok

(ra2.app.028)

To check if a CNF uses K8s secrets

Rationale

secrets_used



To check if any pods in the CNF use sysctls with restricted values

Rationale

sysctls


New

helm_tiller

New

There is no rationale for this

To check if selinux has been configured properly

Rationale

selinux_options

essential

If SELinux options is configured improperly it can be used to escalate privileges and should not be allowed.

Not applicable if SELinux is not installed, but if SELinux is installed a proper configuration is needed.

ok

A: Add a requirement.

Refer to the NSA doc

To check if a CNF is using the default namespace

Rationale

default_namespace
New

To test if mutable tags being used for image versioning(Using Kyverno)
Rationale

latest_tag

essential

"You should avoid using the :latest tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly."

ok

A: Add requirement.

Derived RA2 requirements

RefSpecificationDetailsRequirement TraceReference Implementation Trace
ra2.app.011Horizontal scalingIncreasing and decreasing of the CNF capacity must be implemented using horizontal scaling. If horizontal scaling is supported automatic scaling must be possible using Kubernetes Horizontal Pod Autoscale (HPA) feature.CNCF CNF Testsuite
ra2.app.012Published helm chartHelm charts of the CNF must be published into a helm registry and must not be used from local copies.CNCF CNF Testsuite
ra2.app.013Valid Helm chartHelm charts of the CNF must be valid and should pass the `helm lint` validation.CNCF CNF Testsuite
ra2.app.014Rolling updateThe CNF must be able to perform a rolling update using Kubernetes deployments.CNCF CNF Testsuite
ra2.app.015Rolling downgradeThe CNF must be able to perform a rolling downgrade using Kubernetes deployments.CNCF CNF Testsuite
ra2.app.016CNI compatibilityThe CNF must use CNI compatible networking plugins.CNCF CNF Testsuite
ra2.app.017API stabilityThe CNF must not use any Kubernetes alpha API-s.CNCF CNF Testsuite
ra2.app.018CNF image sizeThe different container images of the CNF should not be bigger than 5GB.CNCF CNF Testsuite
ra2.app.019CNF startup timeStartup time of the Pods of a CNF should not be more than 60s where startup time is the time between starting the Pod until the readiness probe outcome is Success.CNCF CNF Testsuite
ra2.app.020CNF resiliencyCNF must not loose data, must continue to run and its readiness probe outcome must be Success even in case of a node drain and rescheduling occurs.CNCF CNF Testsuite
ra2.app.021CNF resiliencyCNF must not loose data, must continue to run and its readiness probe outcome must be Success even in case of network latency occursCNCF CNF Testsuite
ra2.app.022CNF resiliencyCNF must not loose data, must continue to run and its readiness probe outcome must be Success even in case of disk fill occurs.CNCF CNF Testsuite
ra2.app.023CNF resiliencyCNF must not loose data, must continue to run and its readiness probe outcome must be Success even in case of pod delete occurs.CNCF CNF Testsuite
ra2.app.024CNF resiliencyCNF must not loose data, must continue to run and its readiness probe outcome must be Success even in case of pod memory hog occurs.CNCF CNF Testsuite
ra2.app.025CNF resiliencyCNF must not loose data, must continue to run and its readiness probe outcome must be Success even in case of pod I/O stress occurs.

CNCF CNF Testsuite
ra2.app.026CNF resiliencyCNF must not loose data, must continue to run and its readiness probe outcome must be Success even in case of pod network corruption occurs.CNCF CNF Testsuite
ra2.app.027CNF resiliencyCNF must not loose data, must continue to run and its readiness probe outcome must be Success even in case of pod network duplication occurs.CNCF CNF Testsuite
ra2.app.028CNF resiliencyCNF must not loose data, shmust ould continue to run and its readiness probe outcome must be Success even in case of pod DNS error occurs.

ra2.app.029CNF local storageCNF must not use local storage.CNCF CNF Testsuite
ra2.app.030Liveness probeThe CNF must have livenessProbe defined.CNCF CNF Testsuite
ra2.app.031Readiness probeThe CNF must have readinessProbe defined.CNCF CNF Testsuite
ra2.app.032No access to container daemon socketsThe CNF must not have any of the container daemon sockets (e.g.: /var/run/docker.sock, /var/run/containerd.sock or /var/run/crio.sock) mounted.CNCF CNF Testsuite
ra2.app.033No privileged modeNone of the Pods of the CNF should run in privileged mode.CNCF CNF Testsuite
ra2.app.034No root userNone of the Pods of the CNF should run as a root user.CNCF CNF Testsuite
ra2.app.035No privilege escalationNone of the containers of the CNF should allow privilege escalation.CNCF CNF Testsuite
ra2.app.036No automatic service account mappingNon specified service accounts must not be automatically mapped. To prevent this automountServiceAccountToken: false flag must be set in all Pods of the CNF.CNCF CNF Testsuite
ra2.app.037No host network accessHost network must not be attached to any of the Pods of the CNF.
hostNetwork attribute of the Pod specifications must be False or should not be specified. 
CNCF CNF Testsuite
ra2.app.038Non-root userAll Pods of the CNF should be able to execute with a non-root user having a non-root group. Both
runAsUser and
runAsGroup attributes should be set to a greater value than 999.
CNCF CNF Testsuite
ra2.app.039Host process namespace separationPods of the CNF must not share the host process ID namespace or the host IPC namespace. Pod manifests must not have the
hostPID
or the hostIPC attribute set to true.
CNCF CNF Testsuite
ra2.app.040Resource limitsAll containers and namespaces of the CNF must have defined resource limits for at least CPU and memory resources.CNCF CNF Testsuite
ra2.app.041Read only filesystemIt is recommended that the containers of the CNF have read only filesystem. The
readOnlyRootFilesystem attribute of the Pods in the their
securityContext should be set to true.
CNCF CNF Testsuite
ra2.app.042No host path mountsPods of the CNF must not use hostPath mounts.Kubernetes documentation
ra2.app.043labelsPods of the CNF should define at least the following labels:  app.kubernetes.io/name, app.kubernetes.io/version and app.kubernetes.io/part-ofKubernetes documentation
ra2.app.044Container image tagsAll referred container images in the Pod manifests must be referred by a version tag pointing to a concrete version of the image. latest tag must not be used.

ra2.app.045No hardcoded IP addressesThe CNF must not have any hardcoded IP addresses in its Pod specifications.CNCF CNF Testsuite
ra2.app.046No node portsService declarations of the CNF must not contain
nodePort definition. 
Kubernetes documentation
ra2.app.047Immutable config mapsConfigMaps used by the CNF must be immutable.Kubernetes documentation


Submitted: PDF

  • CFP Closes: Monday, February 21 at 11:59 pm PST

Link: https://events.linuxfoundation.org/cloud-native-telco-day-europe/register/

Must be registered for Kubecon (IN-PERSON pre-registration is required): https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/register/

Speakers (2 max plus backup):

Category (choice):

Session type:

Session Presentation/Deep Dives (typically 30-40 minutes in length)


Session level: All-Levels


Title options:

  • Cloud Native Matchmaking with Anuket
  • Open Source Telco Cloud with Anuket
  • Building an open, interoperable CNF platform in Anuket
  • Anuket - The open telco cloud platform
  • What does Anuket bring to cloud native

Abstract (max 1200 chars):

The Anuket Open Source Project empowers the global telco community to deliver network services faster, more reliably and securely, by developing reference cloud models, architectures and conformance programs.

Today, telcos need to spend high effort for the integration of CNFs with the different cloud native telco platforms. 

To reduce this effort, Anuket defines a Kubernetes Telco Cloud reference - this includes the mandatory capabilities, the reference implementation and conformance testing.

The presentation will introduce the RA2, RI2 and RC2 projects, their content and status, and how to benefit from them.

Participation is open to all - making collaboration between telcos and network vendors an ingredient for success.

The audience are telecom professionals in any phase of their cloud native journey. The audience of the presentation will get an overview on how Anuket decreases the integration cost of CNFs to Kubernetes platforms.


The Anuket projects are working to decrease the time and effort needed to integrate CNFs and Kubernetes platforms. This will make the ecosystem more effective and agile.


Have you or anyone else given this presentation before?*

No


If your session is accepted, would you be open to our PR team contacting you about speaking with media & press onsite?*

Yes




Intro

Anuket specifications are written in GFM (GitHub flavored Markdown) what is a pretty weak markdown language (e.g.: It is not possible to scale images). These documents have three "output formats":

  1. Readthedocs uses recommonmark to convert the documents to rst in compile time. Recommonmark is not supported anymore and should be changed to something else anyways.
  2. GitHub "code view". Here GFM is the default format, but GitHub can render rst also without any problem.
  3. Some of the documents are converted to word document and published by GSMA. Conversion fomr rst would be less difficult than form md

For these reasons we would like to convert the documents from markdown to rst. This page contains information and status progress for this work.

Issues

There are some issues what we need to solve on top of converting the documents.

  • Things to be corrected in markdowns
    • Markdown issues
      • Removal of manual heading numbers
      • Removal of heading numbers from links (replace "[0-9]+\-" with "")
      • Replace raw html to markdown
        • images
        • br-s
        • Image captions ()
        • other <p>-s
        • remove internal references (html anchors)
    • Markdown best praciices
      • remove the ToC-s
    • Things needed for the conversion
      • Add blank lines before lists (like here)
    • Remove the bogometers from the chapters
  • After the rst converison
    • Re-align the table line breaks
    • Move the (n)-s to supertext (if possible)


  • Generate heading during the build
  • fixing of broken intra-document links to GitHub generated anchors. These references/links only work on GitHub, but are broken in the Rtd builds already today
  • consistent use of intra-document linking to auto-generated header anchors without including header numbers


Document responsibles

DocumentResponsibleMarkdown correctionsConversion to rstSeparate buildCorrection of linksLinewrap to 120
RMN/Apr mergeddone, build issues resolved.
RA1DoneDoneDonepull/2856: Done

Done

RA2pr createdpr mergedpr opened by Cedric Ollivier
RI1N/Apr mergeddone

Cedric Ollivier is working on it

RI2Georg KunzN/Apr merged

done


#2965
RC1DoneDonedonedoneAlready wrapped
RC2Cedric OllivierDoneDonedonedoneAlready wrapped
Commonpr createdpr created


All index.rst-s and files outside of subproject scopes






Details

  • Schedule: https://sched.co/lStw
  • Abstract:

    “Anuket References are a family of LFN initiatives to design, implement and test the conformance for Telco Cloud infrastructures. The aim of the specification work is to decrease the time and money needed to integrate Telco Cloud infrastructures and their workloads (Network Functions). Anuket specifications consist of a technology agnostic Reference Model (RM) and two technology-specific Reference Architectures and Reference Implementations, for OpenStack and Kubernetes, aligning with the Anuket Reference Model. In this talk Riccardo and Gergely will describe how RA2, the Kubernetes based Reference Architecture is enabling Telecommunications Providers and Vendors to deploy Containerised Network Functions (CNFs) on Kubernetes efficiently, and what’s new in Kali, the current Anuket release, and what are the plans for the next one, Lakelse.”

  • Duration 30 min
  • Speakers guide: https://events.linuxfoundation.org/open-networking-edge-summit-north-america/program/virtual-speaker-guide/#schedule-information
  • Virtual Speaker Pre-Recording File Submission Due Date: Tuesday, September 14
  • Upload Presentation Slides to Sched: Wednesday, October 6

Notes

Draft material

Details

  • Schedule: https://sched.co/lStw
  • Abstract:

    “Anuket References are a family of LFN initiatives to design, implement and test the conformance for Telco Cloud infrastructures. The aim of the specification work is to decrease the time and money needed to integrate Telco Cloud infrastructures and their workloads (Network Functions). Anuket specifications consist of a technology agnostic Reference Model (RM) and two technology-specific Reference Architectures and Reference Implementations, for OpenStack and Kubernetes, aligning with the Anuket Reference Model. In this talk Riccardo and Gergely will describe how RA2, the Kubernetes based Reference Architecture is enabling Telecommunications Providers and Vendors to deploy Containerised Network Functions (CNFs) on Kubernetes efficiently, and what’s new in Kali, the current Anuket release, and what are the plans for the next one, Lakelse.”

  • Duration 30 min
  • Speakers guide: https://events.linuxfoundation.org/open-networking-edge-summit-north-america/program/virtual-speaker-guide/#schedule-information
  • Virtual Speaker Pre-Recording File Submission Due Date: Tuesday, September 14
  • Upload Presentation Slides to Sched: Wednesday, October 6

Notes