- 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.
This is a list of active Anuket repos in the July of 2022
Location | Is active | |
airship | Gerrit |
|
apex | Gerrit |
|
apex-os-net-config | Gerrit |
|
apex-puppet-tripleo | Gerrit |
|
apex-tripleo-heat-templates | Gerrit |
|
armband | Gerrit |
|
auto | Gerrit |
|
availability | Gerrit |
|
bamboo | Gerrit |
|
barometer | Gerrit | yes |
bottlenecks | Gerrit |
|
calipso | Gerrit |
|
cirv | Gerrit | yes |
cirv-hdv | Gerrit | |
cirv-rapid | Gerrit | |
cirv-sdv | Gerrit | |
cirv-spirent | Gerrit | |
clover | Gerrit |
|
compass-containers | Gerrit |
|
compass4nfv | Gerrit |
|
conductor | Gerrit |
|
container4nfv | Gerrit |
|
copper | Gerrit |
|
cperf | Gerrit |
|
cran | Gerrit |
|
daisy | Gerrit |
|
doctor | Gerrit |
|
domino | Gerrit |
|
dovetail | Gerrit |
|
dovetail-webportal | Gerrit |
|
dpacc | Gerrit |
|
edgecloud | Gerrit |
|
enfv | Gerrit |
|
escalator | Gerrit |
|
fastpathmetrics | Gerrit |
|
fds | Gerrit |
|
fuel | Gerrit |
|
functest | Gerrit | yes |
functest-kubernetes | Gerrit | yes |
functest-requirements | Gerrit | yes |
functest-xtesting | Gerrit | yes |
genesis | Gerrit |
|
genesisreq | Gerrit |
|
infra | Gerrit |
|
inspector | Gerrit |
|
ipv6 | Gerrit |
|
joid | Gerrit |
|
kuberef | Gerrit | yes |
kvmfornfv | Gerrit |
|
laas | Gerrit | yes |
laas-reflab | Gerrit | yes |
lsoapi | Gerrit |
|
models | Gerrit |
|
moon | Gerrit | |
movie | Gerrit |
|
multisite | Gerrit |
|
netready | Gerrit |
|
nfvbench | Gerrit | yes |
octopus | Gerrit |
|
onosfw | Gerrit |
|
openretriever | Gerrit |
|
opera | Gerrit |
|
opnfvdocs | Gerrit | yes |
opnfvtsc | Gerrit |
|
orchestra | Gerrit |
|
oscar | Gerrit |
|
ovn4nfv | Gerrit |
|
ovn4nfv-k8s-plugin | Gerrit |
|
ovno | Gerrit |
|
ovsnfv | Gerrit |
|
parser | Gerrit |
|
pharos | Gerrit |
|
pharos-tools | Gerrit |
|
pinpoint | Gerrit |
|
policytest | Gerrit |
|
prediction | Gerrit |
|
promise | Gerrit |
|
puppet-barometer | Gerrit | |
qtip | Gerrit |
|
releng | Gerrit | yes |
releng-anteater | Gerrit |
|
releng-testresults | Gerrit | yes |
releng-utils | Gerrit |
|
releng-xci | Gerrit |
|
releng-xci-scenarios | Gerrit |
|
rocket | Gerrit |
|
rs | Gerrit |
|
samplevnf | Gerrit | yes |
sandbox | Gerrit |
|
sandbox-zuul-config | Gerrit |
|
sandbox-zuul-untrusted | Gerrit |
|
sdnvpn | Gerrit |
|
securedlab | Gerrit |
|
securityscanning | Gerrit |
|
sfc | Gerrit |
|
snaps | Gerrit |
|
spark-model-runner | Gerrit |
|
stor4nfv | Gerrit |
|
storperf | Gerrit |
|
test | Gerrit |
|
test/test | Gerrit |
|
test/test1 | Gerrit |
|
test2 | Gerrit |
|
thoth | Gerrit | yes |
ves | Gerrit |
|
vineperf | Gerrit | yes |
vnf_forwarding_graph | Gerrit | |
vswitchperf | Gerrit | |
yardstick | Gerrit |
|
CNTT | GitHub |
|
anuket-project/sphinxcontrib-relative-link-corrector | GitHub |
|
sphinxcontrib-readme-to-index | GitHub |
|
sphinxcontrib-direct-copy | GitHub |
|
Netready | GitLab |
|
Snaps | GitLab |
|
Sfc | GitLab |
|
Sdnvpn | GitLab |
|
Qtip | GitLab |
|
Promise | GitLab |
|
Prediction | GitLab |
|
Parser | GitLab |
|
Ovn4nfv K8s Plugin | GitLab |
|
Ovn4nfv | GitLab |
|
Openretriever | GitLab |
|
Onosfw | GitLab |
|
Octopus | GitLab |
|
Multisite | GitLab |
|
Lsoapi | GitLab |
|
Kvmfornfv | GitLab |
|
Ipv6 | GitLab |
|
Inspector | GitLab |
|
Genesisreq | GitLab |
|
Genesis | GitLab |
|
Compass4nfv | GitLab |
|
Compass Containers | GitLab |
|
Yardstick | GitLab |
|
VES | GitLab |
|
FastPathMetrics | GitLab |
Emma Foley this was the SFQM project repo, renamed to Barometer circa 2016 |
Escalator | GitLab |
|
DPACC | GitLab |
|
Domino | GitLab |
|
Daisy | GitLab |
|
CPerf | GitLab |
|
Copper | GitLab |
|
Opera | GitLab |
|
VNF Forwarding Graph | GitLab |
|
JOID | GitLab |
|
OVSNFV | GitLab |
|
CNTT | GitLab |
|
Bottlenecks | GitLab |
|
Availability | GitLab |
|
Auto | GitLab |
|
FastDataStacks | GitLab |
|
Apex-Puppet-TripleO | GitLab |
|
Fuel | GitLab |
|
Apex | GitLab |
|
Armband | GitLab |
|
Pharos-Tools | GitLab |
|
Stor4NFV | GitLab |
|
Doctor | GitLab |
|
VinePerf | GitLab |
|
Pharos | GitLab |
|
releng | GitLab |
|
vswitchperf | GitLab |
|
storperf | GitLab |
|
samplevnf | GitLab | |
opnfvdocs | GitLab | |
nfvbench | GitLab | currently mirror of gerrit |
laas-reflab | GitLab | currently mirror of gerrit |
laas | GitLab | currently mirror of gerrit |
kuberef | GitLab | currently mirror of gerrit |
functest-xtesting | GitLab |
|
functest-kubernetes | GitLab |
|
functest | GitLab |
|
dovetail-webportal | GitLab |
Dan Xu :
|
dovetail | GitLab |
Dan Xu :
|
cirv-spirent | GitLab |
|
cirv-sdv | GitLab |
|
cirv-rapid | GitLab |
|
cirv-hdv | GitLab |
|
cirv | GitLab |
|
Barometer | GitLab | currently mirror of gerrit |
Calipso | GitLab |
|
Airship | GitLab |
|
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”).):
- 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.
- 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
What | What to do | How to get there | Who makes the next step | Status |
---|---|---|---|---|
https://docs.opnfv.org/ |
|
|
| |
gerrit.opnfv.org/ |
|
| ||
https://www.opnfv.org/ |
|
| ||
https://github.com/cntt-n/cntt |
|
| ||
Anuket on GitLab |
|
| ||
cntt.readthedocs.io/ |
|
| ||
LF Networking |
|
| ||
Generic page to record issues |
|
| Gergely Csatari | Done |
|
| 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
- Template to be used: LFN Project Input for the Board template (1).pptx
- Material the TSC provided for the previous round of project reviews: 2021-10-06 Anuket Project to GB-rev.pptx
- 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
- Tests defined here: https://github.com/cncf/cnf-testsuite/blob/2d875c66352e8dc5650c6fe7a1c43e744a7a2871/embedded_files/points.yml (10 out of the 15 'essential' test must be passed to get the certification)
- Rationale of the tests: https://github.com/cncf/cnf-testsuite/blob/main/RATIONALE.md
Issues raised to CNCF CNF Testsuite during this work
The analyzis
Test | Id and Category in CNF Conformance | Note | Verdict |
---|---|---|---|
To test the increasing and decreasing of capacity | 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 ( |
Test if the Helm chart is published | helm_chart_published | We 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) ( |
Test if the Helm chart is valid | helm_chart_valid | ||
Test if the Helm deploys | helm_deploy | This should be more generic, like testing if the CNF deploys. | |
Test if the install script uses Helm v3 | |||
To test if the CNF can perform a rolling update | rolling_update | As 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 | 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 | rolling_downgrade | Same as above? | Needed (ra2.app.015 ) |
To check if a CNF version can be rolled back rollback | rollback | It 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 | 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 ( |
(PoC) To check if a CNF uses Kubernetes alpha APIs | alpha_k8s_apis | Alpha API-s are not recommended by 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 ( |
To check if the CNF has a reasonable image size | 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? should read "pod image size" ( |
To check if the CNF have a reasonable startup time | 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? should read "pod startup time" ( |
To check if the CNF has multiple process types within one container | 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? do not agree with rule |
To check if the CNF exposes any of its containers as a service | 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? |
To check if the CNF has multiple microservices that share a database | 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 |
Test if the CNF crashes when node drain and rescheduling occurs. All configuration should be stateless | 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
|
To test if the CNF uses a volume host path | 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 ( |
To test if the CNF uses local storage | no_local_volume_configuration | should fail if local storage configuration found What's the rationale? ok, add to RA2 (attach to previous) | ok - needed ( |
To test if the CNF uses elastic volumes | 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? |
To test if the CNF uses a database with either statefulsets, elastic volumes, or both | 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? |
Test if the CNF crashes when network latency occurs | 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
|
Test if the CNF crashes when disk fill occurs | 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 ( |
Test if the CNF crashes when pod delete occurs | pod_delete | 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 ( |
Test if the CNF crashes when pod memory hog occurs | 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:
| Needed issue on defining "crashing - it's probes ( |
Test if the CNF crashes when pod io stress occurs | 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 ( |
Test if the CNF crashes when pod network corruption occurs | 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:
| Needed issue on defining "crashing - it's probes ( |
Test if the CNF crashes when pod network duplication occurs | pod_network_duplication | It 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 ( |
To test if there is a liveness entry in the Helm chart | 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 ( |
To test if there is a readiness entry in the Helm chart | 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 ( |
To check if logs are being sent to stdout/stderr | 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 | 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 |
To check if logs and data are being routed through an Unified Logging Layer | 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 |
To check if Open Metrics is being used and or compatible. | 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 |
To check if tracing is being used with Jaeger | 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 |
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 ( |
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 | privileged_containers essential | ie NOT privileged? | Needed ( |
To check if a CNF is running services with external IP's | external_ips | does this mean "k8s service?" RA2 mandates that clusters must support Loadbalancer and ClusterIP, and should support Nodeport and ExternalName | |
To check if any containers are running as a root user | non_root_user | ie not Root? | Needed ( |
To check if any containers allow for privilege escalation | privilege_escalation | ie not allowed? | Needed ( |
To check if an attacker can use a symlink for arbitrary host file system access | symlink_file_system | ok if not According to the CVE this is not valid anymore in Kubernetes 1.23. | Not needed |
To check if there are service accounts that are automatically mapped | 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 |
To check if there is a host network attached to a pod | host_network | should be ok with or without - eg when exposing services via cluster network as opposed to nodeport? | Needed ( |
To check if there are service accounts that are automatically mapped | 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 | 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 | duplicate? | #1409 - [BUG]: Duplicate tests about privileged containers | |
To check for insecure capabilities | insecure_capabilities | what is the expectation? | issue to clarify name |
To check for dangerous capabilities | what is the expectation? | issue to clarify name | |
To check if namespaces have network policies defined | 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 | non_root_containers essential | duplicate? | ok ( |
To check if containers are running with hostPID or hostIPC privileges | host_pid_ipc_privileges | ok if not | ok if not ( |
To check if security services are being used to harden containers | 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 | resource_policies essential | ok | ok ( |
To check if containers have immutable file systems | immutable_file_systems | ok | ok ( |
To check if containers have hostPath mounts | hostpath_mounts essential | ok if not | ( |
To check if containers are using labels | require_labels | ok - maybe mandate some mandatory labels? | ok (ra2.app.043 ) |
To test if there are versioned tags on all images using OPA Gatekeeper | versioned_tag | ok | ok ( |
To test if there are any (non-declarative) hardcoded IP addresses or subnet masks | ip_addresses | ok - there shouldn't be any internal hardcoded nw anyway This was replaced by hardcoded_ip_addresses_in_k8s_runtime_configuration | ok ( |
To test if there are node ports used in the service configuration | nodeport_not_used | ok but service type LB should be better | ok, issue to clarify service types ( |
To test if there are host ports used in the service configuration | hostport_not_used essential | hostports should not be used | OK A: Add this to RA2 |
To test if there are any (non-declarative) hardcoded IP addresses or subnet masks in the K8s runtime configuration | hardcoded_ip_addresses_in_k8s_runtime_configuration essential | Not a duplicate anymore | ( A: Doublecheck if |
To check if a CNF version uses immutable configmaps | immutable_configmap | ok | ok ( |
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 ( |
To check if a CNF uses K8s secrets | secrets_used | ||
To check if any pods in the CNF use sysctls with restricted values | sysctls | New | |
helm_tiller | New There is no rationale for this | ||
To check if selinux has been configured properly | selinux_optionsessential | 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 | default_namespace | New | |
To test if mutable tags being used for image versioning(Using Kyverno) | latest_tagessential | "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
Ref | Specification | Details | Requirement Trace | Reference Implementation Trace |
---|---|---|---|---|
ra2.app.011 | Horizontal scaling | Increasing 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.012 | Published helm chart | Helm charts of the CNF must be published into a helm registry and must not be used from local copies. | CNCF CNF Testsuite | |
ra2.app.013 | Valid Helm chart | Helm charts of the CNF must be valid and should pass the `helm lint` validation. | CNCF CNF Testsuite | |
ra2.app.014 | Rolling update | The CNF must be able to perform a rolling update using Kubernetes deployments. | CNCF CNF Testsuite | |
ra2.app.015 | Rolling downgrade | The CNF must be able to perform a rolling downgrade using Kubernetes deployments. | CNCF CNF Testsuite | |
ra2.app.016 | CNI compatibility | The CNF must use CNI compatible networking plugins. | CNCF CNF Testsuite | |
ra2.app.017 | API stability | The CNF must not use any Kubernetes alpha API-s. | CNCF CNF Testsuite | |
ra2.app.018 | CNF image size | The different container images of the CNF should not be bigger than 5GB. | CNCF CNF Testsuite | |
ra2.app.019 | CNF startup time | Startup 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.020 | CNF resiliency | CNF 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.021 | CNF resiliency | CNF must not loose data, must continue to run and its readiness probe outcome must be Success even in case of network latency occurs | CNCF CNF Testsuite | |
ra2.app.022 | CNF resiliency | CNF 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.023 | CNF resiliency | CNF 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.024 | CNF resiliency | CNF 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.025 | CNF resiliency | CNF 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.026 | CNF resiliency | CNF 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.027 | CNF resiliency | CNF 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.028 | CNF resiliency | CNF 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.029 | CNF local storage | CNF must not use local storage. | CNCF CNF Testsuite | |
ra2.app.030 | Liveness probe | The CNF must have livenessProbe defined. | CNCF CNF Testsuite | |
ra2.app.031 | Readiness probe | The CNF must have readinessProbe defined. | CNCF CNF Testsuite | |
ra2.app.032 | No access to container daemon sockets | The 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.033 | No privileged mode | None of the Pods of the CNF should run in privileged mode. | CNCF CNF Testsuite | |
ra2.app.034 | No root user | None of the Pods of the CNF should run as a root user. | CNCF CNF Testsuite | |
ra2.app.035 | No privilege escalation | None of the containers of the CNF should allow privilege escalation. | CNCF CNF Testsuite | |
ra2.app.036 | No automatic service account mapping | Non 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.037 | No host network access | Host network must not be attached to any of the Pods of the CNF.
| CNCF CNF Testsuite | |
ra2.app.038 | Non-root user | All Pods of the CNF should be able to execute with a non-root user having a non-root group. Both
| CNCF CNF Testsuite | |
ra2.app.039 | Host process namespace separation | Pods of the CNF must not share the host process ID namespace or the host IPC namespace. Pod manifests must not have the
or the | CNCF CNF Testsuite | |
ra2.app.040 | Resource limits | All containers and namespaces of the CNF must have defined resource limits for at least CPU and memory resources. | CNCF CNF Testsuite | |
ra2.app.041 | Read only filesystem | It is recommended that the containers of the CNF have read only filesystem. The
| CNCF CNF Testsuite | |
ra2.app.042 | No host path mounts | Pods of the CNF must not use hostPath mounts. | Kubernetes documentation | |
ra2.app.043 | labels | Pods of the CNF should define at least the following labels: app.kubernetes.io/name , app.kubernetes.io/version and app.kubernetes.io/part-of | Kubernetes documentation | |
ra2.app.044 | Container image tags | All 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.045 | No hardcoded IP addresses | The CNF must not have any hardcoded IP addresses in its Pod specifications. | CNCF CNF Testsuite | |
ra2.app.046 | No node ports | Service declarations of the CNF must not contain
| Kubernetes documentation | |
ra2.app.047 | Immutable config maps | ConfigMaps used by the CNF must be immutable. | Kubernetes documentation |
- 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":
- 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.
- GitHub "code view". Here GFM is the default format, but GitHub can render rst also without any problem.
- 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
- Markdown issues
- 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
Document | Responsible | Markdown corrections | Conversion to rst | Separate build | Correction of links | Linewrap to 120 |
---|---|---|---|---|---|---|
RM | N/A | pr merged | done, build issues resolved. | |||
RA1 | Done | Done | Done | pull/2856: Done | Done | |
RA2 | pr created | pr merged | pr opened by Cedric Ollivier | |||
RI1 | N/A | pr merged | done | Cedric Ollivier is working on it | ||
RI2 | Georg Kunz | N/A | pr merged | done | #2965 | |
RC1 | Done | Done | done | done | Already wrapped | |
RC2 | Cedric Ollivier | Done | Done | done | done | Already wrapped |
Common | pr created | pr 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
- Agenda
- What is Anuket, how it is structured, who are contributing - Gergely Csatari
- What is RA2 - Gergely Csatari
- What did we do in the past (Kali included) - Riccardo Gasparetto Stori
- What are the plans for the future (Lakelse) - Riccardo Gasparetto Stori
- How to get involved? - Riccardo Gasparetto Stori
- Links to start reading, meetings and logistics
- Q&A
- What is Anuket, how it is structured, who are contributing - Gergely Csatari
- Actions
- Gergely Csatari to ask if we can survey the audience
- We can use this slideset as a basis
- This is the template: https://events.linuxfoundation.org/wp-content/uploads/2021/07/ONE-Summit_K8s-Edge_Final.ppt..pptx
- Add generic Anuket update
- Add Laklse updates - Riccardo Gasparetto Stori
Draft material
- Building the Cloud Native Reference Architecture for Telco Cloud – Update on Anuket RA2 - Gergely Csatari, Nokia & Riccardo Gasparetto Stori, Vodafone - v5.pptx
- Building the Cloud Native Reference Architecture for Telco Cloud – Update on Anuket RA2 - Gergely Csatari, Nokia & Riccardo Gasparetto Stori, Vodafone - v4.pptx
- Building the Cloud Native Reference Architecture for Telco Cloud – Update on Anuket RA2 - Gergely Csatari, Nokia & Riccardo Gasparetto Stori, Vodafone - v3.pptx
- Building the Cloud Native Reference Architecture for Telco Cloud – Update on Anuket RA2 - Gergely Csatari, Nokia & Riccardo Gasparetto Stori, Vodafone - v2.pptx
- Building the Cloud Native Reference Architecture for Telco Cloud – Update on Anuket RA2 - Gergely Csatari, Nokia & Riccardo Gasparetto Stori, Vodafone - v1.pptx
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
- Agenda
- What is Anuket, how it is structured, who are contributing - Gergely Csatari
- What is RA2 - Gergely Csatari
- What did we do in the past (Kali included) - Riccardo Gasparetto Stori
- What are the plans for the future (Lakelse) - Riccardo Gasparetto Stori
- How to get involved? - Riccardo Gasparetto Stori
- Links to start reading, meetings and logistics
- Q&A
- What is Anuket, how it is structured, who are contributing - Gergely Csatari
- Actions
- Gergely Csatari to ask if we can survey the audience
- We can use this slideset as a basis
- This is the template: https://events.linuxfoundation.org/wp-content/uploads/2021/07/ONE-Summit_K8s-Edge_Final.ppt..pptx
- Add generic Anuket update
- Add Laklse updates - Riccardo Gasparetto Stori
The document was accepted in the 2021-11-02 TSC meeting. The document was moved to Anuket Project Operations and Procedures .
Introduction
This page is created to provide a framework for the modifications of the proposed Anuket Charter. The baseline document was created by Pankaj Goyal based on the XGVela and CNCF and on the comments collected to the current Anuket charter.
History of this page was used to develop the now approved Anuket charter. This page is considered as retired.
The charter
The proposed charter was review-ed and approved by LF legal and voted by Anuket TSC.
Here is the charter in different formats:
- Full text of the charter
- Text of the charter in comparision with the current charter of Anuket
Previous versions
Are in the history of this page. Last agreed version sent for legal review is in version 14.
Introduction
This page is created to provide a framework for the modifications of the Anuket Charter and the TSC Operational Guidelines. Both of these documents were inherited from OPNFV and had one set of editing. The final aim of this activity is to reach a TSC consensus and finally an approval on the content of the documents.
References
Changes of the proposed Charter compared to the previous OPNFV Charter
- Clean version of the proposed Charter
- Clean version of the proposed TSC Operational Guidelines
Ways of working
- A copy of the proposed documents added to the following pages
- Please comment the text in the documents using the inline commenting feature of Confluence in a way that the whole text to be replaced is marked for commenting
- Propose a modified text in your comment if possible
- Once there is a consensus on the text to be modified it will be edited to the text
Obsolete documents to comment
These documents are the current Anuket Charter and TSC Operational Guidelines commented by the community. The commenting of the actual proposed document are in the following pages:
- Anuket Charter proposal for commenting
- Anuket TSC Operations and Procedures document proposal for commenting
- Anuket Project Operations and Guidelines document for commenting
These documents are kept in here to preserve the community comments of the original documents.
Please do not comment these anymore, but comment the referred pages instead. Any comments to this page will be deferred.