📞📱☎️📡🌐 The focus of the Cloud Native Telecom Initiative (CNTI) Best Practices community is to define cloud native networking best practices
Home Page: https://wiki.lfnetworking.org/display/LN/Best+Practices
License: Other
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Add CBPP-0002: Container should execute process(es) as non-root user to Table of Contents under security category
Description:
Containers have a list of their own users independent of the host system, one of which is UID 0, the root user. Containers should run processes as a user other than root which makes it easier to run the container images securely.
Reference: CBPP-0002
From Feb 01 meeting:
User stories as optional should be removed, if there is none, start a GitHub discussion
Caveats should also not be optional, or it should be renamed to tradeoffs
Watson to make PR
Instead look to use dynamic approaches, e.g. labels.
Need to be clear about what is dynamic configuration vs hard-coded static configuration.
Suggested changes:
[KubeCon NA 2021] Intro & Deep Dive to the CNF WG](https://sched.co/lV9e)
The meeting times will stay at the same "clock time" after daylight savings time changes.
Meetings will remain at:
while the UTC time shifts from 15:00 UTC to 16:00 UTC starting on Monday, November 7th, 2022.
https://github.com/cncf/cnf-wg/issues/232#tasklist-block-07a76d28-b3e3-4403-ac62-aeeb3cefad79
A production CNF should use an immutable tag that maps to a semantic version of the application.
"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."
Ref https://kubernetes.io/docs/concepts/containers/images/
No response
No response
No response
Using the latest tag is an anti-pattern..
The :latest tag is what is applied to an image which does not have a tag, which does not mean, as some people expect, that :latest always points to the most-recently-pushed version of an image.
No response
No response
As a related item we recommend locking image tags on the container registry for production releases to avoid overwriting a known good image. https://learn.microsoft.com/en-us/azure/container-registry/container-registry-image-tag-version#lock-deployed-image-tags
There are loads (e.g. https://github.com/cncf/cnf-wg/runs/7841086103?check_suite_focus=true#step:4:1200) that need resolving.
from: https://github.com/opengovernance/opengovernance.dev#process
How can the project contributors become committers?
How are project committers removed?
We have elected our co-chairs and say things can be merged after so many approvals, but we never actually defined who is able to commit to the repo or how someone can become a committer.
We may want to consider something from https://github.com/cncf/project-template/blob/main/GOVERNANCE-maintainer.md
Now that we all know the rules to commit from #131 I am personally in favor of having more people with commit access.
I believe we could add a best practice for 'don't use privilege'. We could add a user story to justify it (something about making the platform robust to application behaviour) but I believe the best practice can stand alone.
The higher level principle is:
See discussion https://github.com/cncf/cnf-wg/discussions/25 for not running containers with privilege flag.
Given the number of active members, we should lower the required number of approvers from 5 to 3.
There should be a place for users (CSPs) to submit their user stories and high level objectives. It could be structured similarly to the CCDPs. The user stories should be used to inform the cloud native best practices.
Proposal: Switch from org or individual to individual with org affiliation listed.
This will better represent our community which consists of individual contributors. It encourages participation and contributions regardless of your organization affiliation. If needed we can still make decisions based on representation of a single org based on the listed org for each individual.
Reference:
Originally posted by @taylor in https://github.com/cncf/cnf-wg/discussions/126
Suggestion:
Reason:
References:
There is a lot of content under discussion #30 for defining the roles, this should now be written up into the first draft of a PR
Common terms likely to be used in multiple use cases or in best practices should have a glossary. That way, many use cases can do without a glossary because the terms will be globally defined.
A microservice should have only one process (or set of parent/child processes) that is managed by a non home grown supervisor or orchestrator. The microservice should not spawn other process types (e.g. executables) as a way to contributeto the workload but rather should interact with other processes through a microservice API.
from CNF Test Suite
Reference(s):
It considers them to be broken links. Looks like a problem with the way the link checker thinks, and is most likely fixed by tweaking its settings.
'Blank lines' mistakes that must have gone in from another commit. Needs a quick fix.
Update / refactor introduction and final and final paragraph in the first section of the main README
The document https://github.com/cncf/cnf-wg/blob/main/cbpps/0003-exceptions.md was merged but is missing a few things including the title
CBPP-NNNN: Your short, descriptive title (TEMPLATE)
TODO:
What we have now:
One section for Elections:
https://github.com/cncf/cnf-wg/blob/master/charter.md#elections
What we’d like to have:
High-level section for Election Procedure
Sub-categories, inspired by https://github.com/cncf/project-template/blob/main/GOVERNANCE-elections.md#election-procedure
Co-chairs and tech leads will be elected for one year terms and may run for reelection.
Each organization listed in the interested parties document has one vote. Interested parties can be added at any time, but must be added at least one week before any election to have a vote. Any contributor from an organization may cast the vote for that organization. Each organization can cast one vote for a co-chair candidate in each of the communities (Kubernetes (K8s) Community, Service Provider (SP) Community, and CNF Developer (Dev) Community), three total votes. Each organization can vote for as many tech leads as they see fit.
Elections will be held using a time-limited Ranked Choice Voting ranking on CIVS. Ballots will be emailed to one representative of each organization listed in the interested parties document. Tech leads must win at least 60% of the votes cast to be elected.
I believe it is long overdue to have a clear documented understanding behind the requirements for multiple interfaces within a cloud-native network function, independent from the fact that technical implementations already exist to support them.
Is multi-interface required for :
a) traffic segmentation
b) isolation, security
c) performance
d) hardware dependencies
e) because this is how we did PNF, VNFs
f) all of the above
Understanding the real justification behind this will help better understand how CNFs and infrastructure might be evolving and potential simplification (ie avoiding too much toil).
Github lets you add change proposals to PRs, which is more efficient than reading someone's comment and writing up the change yourself. However, it's caught out several people, me included - it's not obvious you can do this if you've never done it before.
Add a note to the reviewer help to explain how this works and how to do it, and that changes are in fact welcome and preferred over comments when you know exactly what change you're looking for.
Description:
From https://docs.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository - When you add a pull request template to your repository, project contributors will automatically see the template's contents in the pull request body.
See meeting notes for 18/07/22 here: https://docs.google.com/document/d/1YFimQftjkTUsxNGTsKdakvP7cJtJgCTqViH2kwJOrsc/edit#
This covers the least privilege best practice of avoiding running processes as root in containers
See initial draft proposal in PR https://github.com/cncf/cnf-wg/pull/182
From #46 https://github.com/cncf/cnf-wg/pull/46#discussion_r566053891
@rabi-abdel
i think it will be useful to clearly specify what information we need to see in a use case, in a bullet list.
Problem statment.
impact to real-life actor.
etc.
@jeffsaelens
To Rabi's point, at some point we'd probably want a template for use cases and a means of pointing back to them from the best practices (this could also be a one to many scenario so some thought might be needed). I know we are trying to keep people's creative spirits soaring, but we might want more specificity as to when to use "discussions" for more free form thoughts on paper versus when a drafted proposal is appropriate.
The categories in best_cnf_dev.md are no longer in sync with the test categories in the related CNF Test Suite.
TODO:
cnf-testsuite.cnf-testsuiteWe should add our group values to make it clear.
Values / Principles
It is also good practice to include a statement of values or principles within your governance documentation. While the scope includes information about what your project does, your values / principles define how you work. They often include statements about openness, transparency, inclusion, being welcoming and respectful, and much more.
These are all living documents that should be expected to change over time as the project evolves. For sandbox projects, this might be a simple one or two sentence statement about what the project does, and by the time a project has graduated, they would probably have a more detailed mission statement, scope, and values / principles. All of this documentation should be consistent with the mission and values in the CNCF Charter.
https://docs.google.com/document/d/1QawLfsz2_n2Y0nPuMzTy9tF9Tu3iFanq5PJgXK-yr3Y/edit?ts=604bb3e4
We have a Use Case, it would be great if we can start to extract some best practices from it ...
https://github.com/cncf/cnf-wg/tree/main/use-case/0003-UC-stateful-cnf
I suggest we limit line length in MD files to 80 characters.
Now, I know that modern editors will word wrap MD files and I know that the MD format does not care about line length. However, github is making some really hard to interpret diffs of files when they have long line lengths in them.
I suggest we note this in our style guide and add CI to check for it on new pull requests.
Kube-Native has been used through some of our work, see #95 for one example, but has not yet been defined. It is also currently listed as TBD in the glossary https://github.com/cncf/cnf-wg/edit/main/doc/glossary.md.
It would be great to have a defintion so we are all on the same page.
Some are properties, some are areas, etc. Suggestion: use words that are of one type for each category name.
Examples:
Title: [KubeCon NA 2021] Intro & Deep Dive to the CNF WG
Speakers: CNF WG Co-chairs, @iawells @jeffsaelens @taylor
Event details:
Tasks:
Something about readiness for a CNF to receive real network traffic
They should be relative links so that our documents refer to each other in forked repositories properly, otherwise it's hard to check the work you've done in a pull request.
From discussions:
Once agreed, contribute the items to the CNCF Glossary: https://glossary.cncf.io/contribute/
From 2021-03-15 meeting:
What does it mean to be an interested party? - create issue. (Per above, does Frederick need to be an interested party to have voting rights?) Does being an interested party have any obligations, since that’s what legal depts will worry about?
For companies or individuals that want to add themselves as an interested parties, does it have any legal ramifications. Currently it gives them the right to vote in elections, but nothing else is defined.
Can we borrow something from SIG Contributor Strategy? https://github.com/cncf/sig-contributor-strategy/tree/master/governance/docs
2020-04-27:
From the discussion, the text we like most is:
As an aside, note that this is more about the reputation of this group being co-opted in the future than it is about it being seen as a mouthpiece for a vested interest in the present. If it's obviously a mouthpiece, that's an issue, but it will impact our reputation and therefore adoption of our recommendations. If our group is co-opted in the future, however, then a group will be able to take advantage of our established reputation.
- Define representation groups that we wish to control representation on. For instance: one chair per independent organisation, 30% of community votes, 30% of tech leads (to avoid majorities of conspirators).
- A organisation is defined as a single company.
- If a member (define 'member') raises a concern of independence: first they must demonstrate a relationship between organisations that lead to the conclusion they should be treated as a single organisation (e.g ownership, contractor-contractee); second, the relationship will be debated, since this does not necessarily demonstrate that the organisations are acting together; and third, action will be taken only if a majority of uninvolved members (choose your membership set and quorum here) votes for it. The action would be that the multiple entities would be considered one organisation under the charter.
- If, through this process, an organisation becomes overrepresented, the seats for that organisation will all be put up for a special election. The seats are open to all members, both previous holders and any other nominees.
- In any elections (presuming we use STV or something similar), the members with least votes in an overrepresented group will be excluded from election (this should already be in some other part of the charter). Where there are multiple candidates with the same number of least votes, it's a coin toss (ditto).
- The decision on independence or dependence may be revisited after a period of not less than three months. A member may raise it for discussion and the process in point 3 shall be repeated. No immediate re-election of members shall occur if the organisations now are deemed independent; this will be taken into consideration in the next natural election cycle.
To game the above rules, you'd require a majority of the membership conspiring against some part of the community that had overrepresentation if and only if it were considered a bloc, and that bloc would need some corporate relationship, so it would be an unproductive thing to try and do unless a real concern existed. (I can't claim 'everyone not in my company is conspiring against me', for instance, because I haven't got valid grounds to raise the concern.)It does not present multiple independent blocs agreeing to vote in concert. What prevents that is a healthy and diverse membership, and there's nothing the rules can do about that.
A cloud native principle is that application developers understand their own resilience requirements better than operators[1]. This is exemplified in the Kubernetes best practice of pods declaring how they should be managed through the liveness and readiness entries in the pod's configuration.
liveness probes are part of the onboarding and the ongoing health checks for CNFs.
No response
No response
No response
No response
No response
No response
liveness probes are part of the onboarding and the ongoing health checks for CNFs.
Title: CNF WG BoF: Bring Your Networking Challenge, We’ll Find a Cloud Native Best Practice
Speakers: CNF WG Co-chairs, @iawells @jeffsaelens @taylor
Event details:
Tasks:
Need to add a license. Probably only needed for non-code.
Reference:
Gergely:
At the moment there is no license on the repo
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.