Jump to: navigation, search

Computing Force Network Working Group guide

算力网络开源工作组手册 CFN WG Guide

Note: Not the finial version, will keep updating it to more reasonable and readable, feel free to add comments/suggestions,

本章程旨在描述OpenInfra Foundation 下的算力网络开源工作组参与角色的责任,以及开源项目流程,CFN WG 的参与者需要参考并遵守。

1.Mission and Scope CFNWG的使命是推广算力网络的理念和发展,并基于算力网络理念, 推动算力网络相关的关键技术的发展,逐步构建算力网络为目标的下一代信息基础设施,助力全球数字化经济发展。 The mission of CFN Working group is to promoting the concept and development of Computing Force Network, and promoting the development of CFN key technologies, to gradually build the next information infrastructure of CFN, to empower global digital economy.

CFN WG 基于算力网络应用场景,研究并制定算力网络开源参考架构、参考流程,提出关键技术需求,在关键技术领域形成开源技术方案,并推动关键技术开发与实现,形成算力网络开源实现方案并不断迭代优化。 CFN working group will collect use case scenarios, define opensource CFN reference architecture and procedure, identify key technologies, formulate solutions for technical challenges, then promote the development and implementation of key technologies, deliver opensource CFN prototype with combination of these key technologies and continuously optimize CFN with new scenarios.

CFN WG会根据关键技术领域的分类来形成子工作组,负责技术方案制定和实现,输出技术方案和代码实现。 CFN WG will setup sub-groups based on subjects and classification of technology, which will be responsible for solution making and technical implementing, delivery documents and code.

CFN WG 算力网络工作组聚焦于探讨并构建算力网络的新型信息基础设施,范围包括但不限于:

  1. 1,当前基于市场需求和技术发展的趋势下,讨论用户场景和用户需求
  2. 2,基于场景讨论和制定算力网络的总体架构、端到端流程;
  3. 3,讨论为构建算力网络的新型基础设施需要的关键技术,关键技术之间如何集成、协作,以及跨社区进行技术方案拉通
  4. 4,给算力网络涉及的技术进行分类,在技术领域中进行方案制定并推动技术实现,子技术领域包括但不限于:
  • 泛在算力操作系统:实现云、边、端各层算力统一管理统一调度的操作系统;涉及技术:基础设施的集群管理,端算力的管理,以及相应的安全技术,操作系统隔离技术等
  • 算力原生:构建基于异构算力的编译开发平台;涉及技术:异构芯片编译器,统一开发语言,操作系统适配,芯片驱动等
  • 算力交易:构建多方算力可信交易平台;涉及技术:算力并网,算力认证,算力封装,区块链平台等技术
  • 算力卸载:构建统一的计算平台底座; 涉及技术: DPU、 vSwitch、存储、Hypervisor 相关技术,服务器定制等。
  • 算网大脑:任务拆分、编排、分发,向下拉通算网全领域资源,向上支撑算网融合类全业务,
  • etc


CFN working group will focus on topics of how to build the new information infrastructure of CFN, which includs but not limited to:

  1. 1, Use case scenarios and users' requirements based on the current market and technical development trend
  2. 2, Discussions and specifications for Computing Force Network overall architecture
  3. 3, Discussions around key technologies for building new information infrastructure of CFN, how those technologies collaborate and integrate with each other, and generate a cross-community aligned technical solutions
  4. 4, Categorize CFN related technologies, host further discussions about technical solutions amd implementation in sub-groups, key technologies includes but not limited to:
  • # Operating System for ubiquitous computing: to realize a unified operating system of management and orchestration for cloud, edge and terminal computing. Related technologies includes: cluster management of infrastructure, terminal computing management, security, operating system isolation and etc.
  • # Computing Native: this is to build a development platform of unified compiling which based on heterogeneous computing hardware. Related technologies includes: compiler for heterogeneous chips, unified programming language for development, operating system adaption, chip driver and etc.
  • # Computing transaction: this is to build s trusted computing transaction platform for multi-party computing. Related technologies includes: 3rd-party computing cooperation, computing authentication, computing encapsulation, blockchain and etc.
  • # Computing offload: this is to build a unified computing platform basement. Related technologies includes: DPU, vSwitch, Storage, hypervisor related technologies, customized servers and etc
  • # CFN brain: build a CFN brain to realize task decomposition, orchestration, and distribution, which can connects computing and network resources in all fields in lower layer, and gives full support for computing network integrated services in upper layer.
  • # ... etc

2.Project Operations and Procedures 2.1Structure CFN WG 由多个子工作组组成,并且都在TSC的监督之下。 The CFN WG consists of multiple sub-groups and a Technical Steering Committee (TSC) that oversees all sub-projects.

CFN WG组织架构示意如下, 子工作组包括但不限于下图中的方向 CFN WG organization structure as below, sub-groups will include but not limited to those in below picture.


2.2Sub-group Role 2.2.1 Contributor A Contributor is someone who contributes to a project. Contributions could take the form of Use case, requirements, code, code reviews, or other artifacts. Contributors work with a project’s Committer and the project’s sub-community. A Contributor may be promoted to a Committer by the project’s Committers after demonstrating a history of meritocratic contribution to that project.

2.2.2 Committer For each project, there is a set of Committers approved for the right to commit to the version control system (the “Committers”) for that project.

  • Committer rights are per project; being a Committer on one project does not give an individual committer rights on any other project.
  • The Committers will be the decision makers on all matters for a project including design, code, patches, and releases for a project.
  • Once the project passed the Creation Review its committers have a sustained record of contributions to the project.


2.2.3 PTL A project is required to elect a Project Technical Leader (“PTL”). The PTL acts as the de facto spokesperson for the project.PTLs are responsible for:

  • steering the work towards a successful conclusion
  • ensuring that the work benefits from a wide spectrum of views
  • ensuring a consensus-based approach, as much as is possible, in achieving decision
  • organizing and conducting meetings with the objective of furthering the project objectives
  • ensuring quality of deliverables
  • Ensuring sufficient document about the sub-group, like wiki, meeting log,etc
  • Attend CFN WG TSC meeting, provide info in PTL standup

PTL Election Mechanics

  • Candidates for the project’s Project Technical Leader must be Committers of the Project.
  • Candidates must self nominate.
  • Only Committers for a project are eligible to vote for a project’s Project Technical Lead.
  • The majority of committers on a project vote to call a new election
  • Project Technical Leader election happens annually.


2.3Sub-group lifecycle The activities of the Community are organized into sub-groups targeting different areas within the scope of CFN WG.  These sub-groups might include, but not be limited to usecase and architecture research, key technologi research and code implementation, development of upstream code, integration of platform components.

The lifecycle of the sub-projects is depicted on the following diagrams: (Will add proposal status later)

The procedure of moving from one level to the next one is independent from the release process, the pace depends on each individual sub-project. Sub-group promotion, and demotion, across states can only be done by TSC review and voting.

Sub-group States Sub-group state Description Forming Sub-group doesn’t really exist yet, may not have real resources, but is proposed and is in the process of getting resources. Active Sub-group has resources and it in the process of being developed, might have on-going releases with new features or specifications over time. Archived Sub-project has been recognized as dead (could be for a variety of reasons, e.g. sub-project successfully accomplished its goals, sub-project failed, etc.), and has been archived as it is no longer an on-going sub-project.


2.4Release process TBD 2.5Project Creation Once TSC agreed to setup sub-group, you can start sub-group follow below guide 2.5.1 Instructions Create a new wiki page and link it to : https://wiki.openstack.org/wiki/Computing_Force_Network_Working_Group, under “Organization Structure” section, add a sub-group link with [forming] tag Fill in the page with informations like:

  • Status [forming, active, archived]
  • Introduction of sub-group like concept explanation, function definition etc
  • Mission and goals of work group
  • Initial scope
  • Sub-group work plan, please indicate the expected output, documents only or code implementation,  if code implementation is included, please also indicate contribute existing code, or start a new project from scratch.
  • Committers and PTL

Scheduled sub-group creation review in TSC meeting, bring slides or just use their proposal if it goes into sufficient detail. A few diagrams of the major components and how they interact are often useful.

Recommondations: If you would like to make contributions to CFN WG, and it is not covered in existing scope or future potential scope of sub-group, and think it is neccesary to setup a sub-group for it, you can:

  • Gather interested parterners regardless CFN WG existing membership, or ask TSC for help of collect interests. You can use the eixsting CFNWG maillling list for discussion, or raise a topic in CFN WG meeeting.
  • Select PTL within interested parterners or become PTL!
  • PTL usually leading the definiation, goals and plan of sub-group, as well as contribution resources
  • Once you have initial interested parterners and sub-group definition(please refer 2.5.2 Creation criteria of this guide), you can book TSC session in agenda for TSC review and vote. (https://etherpad.opendev.org/p/CFNWG-meetings)
  • Once it’s approve, it is in Forming status.
  • Then you can setup regular meeting with sub-group, collect more parterners, and make further discussion about defination, scope, plan, to make detailed definiation of function, solutions, architecture, target output, and roadmap of sub-group, once they are all well-defined and commonly agreed, PTL can raise a topic in TSC meeting for review and progress to “Active” status
  • keep TSC updated of the progress


2.5.2 Creation criteria

  • Goals align with CFN WG
  • Scope and sub-group plan is well defined
  • At least two (2) committers from different organisations identified
  • Initial list of committer identified (elected/proposed by initial contributors)
  • PTL is agreed within sub-group
  • Wiki page is created with below info and email notice to CFN WG mailling list is sent
  • Review by TSC: Confirm that the sub-group definition is complete and the above listed requirements are met.
  • Simple majority approval by voting TSC members

2.5.3 Guidelines for After Creation Review Once your project has been formally approved by the TSC, you'll want to start getting it set up.

  • Update the status of your sub-group in the wiki
  • Setup regular meeting and update the wiki with regular meeting info
  • Log meeting minutes to show the progress and content of each meeting, etherpad is commonly used.
  • Apply repository and update repository info in the wiki page ,上传work到repo
  • Run regular meeting and start working through the tasks
  • You can use existing mailling list for discussion, add tag with sub-group name, like [Use Case and Architecture].  https://lists.opendev.org/cgi-bin/mailman/listinfo/computing-force-network
  • Keep it running and active, and keep sub-group updated to TSC


2.5.4 Termination Review: TBD 2.5.5 Reactivation Review: TBD


3.TSC Community Member: Any person, regardless of OIF membership, that has joined CFN WG or one of the sub-projects or workstreams or teams. Anyone can join the CFN WG community by subscribing to the lists https://lists.opendev.org/cgi-bin/mailman/listinfo/computing-force-network

Active member: make at least *(TBD number) contributions

3.1人员构成 eligible TSC候选需要满足:

  • 必须是CFN WG活跃成员,参与CFN WG 或子工作组, 有具体贡献
  • 可以协调公司内部投入资源
  • 最少**贡献数量(待定)
  • TSC seats:暂定7-9位成员 包括1chair (1-2)co-chair

Eligible TSC candidates:

  • MUST be an active community member, and can demostrate contribution history
  • CAN coordinate resources to make contributions in CFN WG
  • Make AT LEAST ** contributions
  • TSC seats: 7-9 members, including 1 chair, 1-2 co-chair

3.2职责包括: CFN WG的技术委员会(TSC)将负责算力网络开源工作组的整体技术方向掌控和开源技术发展推动,包含但不限于:

  • 决定CFN WG的技术方向,包括比如批准CFN WG 的scope
  • 协同CFN WG成员共同推动算力网络开源原型实现
  • 参与需求与架构组的例会,进行场景梳理、CFN架构、关键技术等讨论
  • 参与TSC例会,关注推动各项目进展
  • 决策制定,包括但不限于创建、重构、关闭子WG/项目
  • Review社区章程、子工作组工作流程、工作目标、计划产出等
  • 促进CFN 架构、关键技术持续迭代演进,协调关键技术组件间协作
  • 促进CFN WG与其他相关社区协作,包括但不限与方案拉通,引用集成等

The Technical Steering Committee (the “TSC”) will be responsible for the all aspects of technical oversight of the open source CFN WG, and promote the CFN WG activitites, which include but not limited to:

  • Define and approve the technical directions of CFN W, for example: CFN WG scope
  • Coordinate CFN WG members to build CFN WG opensource prototype, and coordinate resources for contributions
  • Attend meetings of Use Case and Architecture sub-group, and participate discussions about use case , architecture, key technologies analyze
  • Attend TSC meeting, promote sub-group progesses
  • Disicison makings, include but not limited to: create, reactive, close sub-group
  • Review and approve charters, sub-group management procedure, goal and expected output of sub-group
  • Promote the development of CFN architecute, key technologies, and promote collaborations between sub-groups
  • Promote the collaboration of other open source communities, include but not limited to: align technical solutions, key technologies integration etc


TSC chair 职责:

  • 组织、主持、记录TSC 会议
  • 做为CFN WG 跟OIF 和其他社区、项目沟通时的主要联系人

TSC Chair and co-chair responsibility

  • Organising, presiding, and take meeting minutes over TSC meetings
  • Serve as the primary communication contact between the Project and the OIF


3.3TSC 会议和决策 3.2.1 会议

  • TSC 需要定期开会,可视agenda情况增加或更改例会,具体会议信息参见wiki
  • 社区成员均可以添加TSC会议的agenda,包括TSC成员,sub-group PTL,sub-groupmemeber, 其他人需要提前跟TSC 沟通
  • TSC会议公开,欢迎任何人参加和讨论
  • 一次有效的TSC 会议至少需要超过半数人参与,如果人数不够,TSC依然可以进行讨论,但不能进行决策制定
  • TSC 如果确实不能参会,可以在会议前指定Proxy,代替参加和决策

3.2.2 决策

  • 任何决策需要在TSC 会议、mailling list 或者公开的电子投票方式进行
  • TSC成员均有资格投赞成票、反对票、弃权
  • 有效投票数需要超过TSC 的半数
  • 平票情况下,可以对平票放展开讨论分析,如果仍出现平票,TSC chair可以有额外一票


3.4选举规则 3.4.1 TSC member

  • 每年换届选举
  • 2周时间开放提名候选人
  • CFN WG 的活跃成员, 均可提名或者被提名
  • TSC成员选举需要CFN WG 投票决定
  • 只有CFN WG 的活跃成员才能vote (何为活跃成员定义请参考2.**)
  • 每公司在TSC最多只有一个席位


3.4.2 TSC Chair and co-chair

  • 在每年TSC换届选举完成后进行
  • TSC确定后,开始提名TSC的chair 和Co-chair 候选人
  • TSC 确定成立后,2周时间开放提名候选人
  • 候选人必须是TSC 成员,且只有TSC 成员可以提名候选人,候选人本人必须同意作为备选人
  • 只有TSC成员有资格投票选举chair 和co-chair
  • 至少超过2/3 TSC数目的有效票,才能算作一次有效的投票




4.Compliance 4 Opens


5.Contribution Statistics Statictics counting: TBD

6.Amendments