The Akraino technical project has been established as Akraino Project a Series of LF Projects, LLC (alternatively, the “Project”). LF Projects, LLC is a Delaware series limited liability company. Governance for the Project is detailed within the Project Technical Charter available at akraino.org (“Technical Charter”). This Technical Community Document is intended to provide additional operational guidelines for the Project, and is subject to the Technical Charter.
The Akraino Project a Series of LF Projects, LLC (“Akraino”) will operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.
The Technical Community consists of multiple projects and a Technical Steering Committee that spans across all projects.
The Akraino Technical mission to focus on following areas
In order to have focused work in support of initial releases, the Akraino community preference is to support Edge Blueprints related to enterprise and industrial IoT, and carrier edge network use cases. Board has the authority to define, modify, prioritize any additional industry sectors that need to be supported by the Akraino releases.
The Edge cloud stack placement could vary between Telco Offices to Customer premise and anything in between. Akraino community blueprints should be capable to deploy and address different edge cloud placement options.
As an example, the picture below illustrates the enterprise edge and carrier edge network Edge use cases and possible edge placement.
Figure 1 - Sector 1: Carrier edge network edge use case and edge placement
Figure 2 - Sector 2: Enterprise and Industrial IoT use cases
A Contributor is someone who contributes to a project. Contributions could take the form of code, code reviews,Wiki and documentation contributions, Jira activities 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 contributions to that project.
For each project there is a set of Contributors approved for the right to commit code to the source code management system (the “Committers”) for that project.
In order to preserve meritocracy in selection of Committers while ensuring diversity of Committers, each initial project is encouraged to take on at least two Committers from different companies (subject to meritocracy).
A project is required to elect a Project Technical Leader (“PTL”). The PTL acts as the de facto spokesperson for the project (feature projects and integration projects).
Candidates for the project’s Project Technical Leader will be derived from the Committers of the Project.
Candidates must self nominate.
Only Committers for a project are eligible to vote for a project’s Project Technical Lead.
An election for Project Technical Leader occurs when any of the following are true:
Technical and release decisions for a project should be made by consensus of that project’s Committers. If consensus cannot be reached, decisions are taken by majority vote of a project’s Committers. Committers may, by majority vote, delegate (or revoke delegation) of any portion of such decisions to an alternate open, documented (wiki), and traceable decision making process.
In the event that a project has no active committers (e.g., due to resignations, etc.), the TSC may appoint an interim Committer from a project’s active Contributors. This term shall last until the next release date, after which time the Committer must stand for election from amongst other Committers on the project to maintain his or her status. In this special case, approval requires a majority of committers who respond within two weeks. If no one responds by the deadline, then the committer status is approved. This provision allows a project to continue development following an unexpected change in personnel.
The method by which the TSC appoints an interim Committer is first by request to the Akraino-TSC email list indicating the request to appoint an interim Committer for a project. After the reception of such an email, the normal TSC decision process applies.
A Committer may voluntarily resign from a project by making a public request to the PTL to resign (via the project email list and cc to tsc@lists.akraino.org ).
A Committer for a project who is disruptive, or has been inactive on that project for an extended period (e.g., six or more months) may have his or her Committer status revoked by the project’s Project Technical Leader or by 2/3 supermajority vote of the project’s committers.
The Project Technical Leader is responsible for informing the Technical Steering Committee (TSC) of any committers who are removed or resigned via the email list: tsc@lists.akraino.org.
Former committers removed for reasons other than being disruptive may be listed as ‘Emeritus Committers’. That title expresses gratitude for their service, but conveys none of the privileges of being a Committer.
The activities of the Akraino community are articulated around projects and releases. The scope of each project is aligned with Akraino’s charter and the scope of each release is defined with the objective to fulfill a particular Edge use case(s).
A project is a long term endeavor setup to deliver features across multiple releases, which have a shorter lifespan. The project and release lifecycle should provide sufficient visibility to all community members and allow teams to coordinate with one another.
This document covers the Akraino project lifecycle. The Release Lifecycle will be documented in the wiki.
Akraino will support three categories of projects and upstream coordination activities related to the projects as shown in Figure 3 and further illustration are available under the section 3.3.2.1, 3.3.2.2 and 3.3.2.3 of this document.
The Akraino Community goal is to deliver fully integrated and production deployable solution for the users. The combination of Feature projects (developing missing edge functionalities on non-upstream open source components), Integration projects (integrated end to end stack) and End To End (ETE) validation projects of the blueprints along with edge applications running on top of it, delivers the production deployable solution needed by the industry.
Akraino community uses upstream-first principle to avoid technical debt on the upstream open source components: Akraino projects should not carry patches against upstream projects, but collaborate with and contribute designs and patches to the respective upstream projects to address gaps. Exceptions must be approved by the TSC.
Figure 3 – Akraino Project Types & Scope
The Akraino Feature projects develop edge features, functionalities, interfaces and modules required by an Akraino blueprint or multiple Akraino blueprints to satisfy the Edge use cases and requirements. Feature projects focus on the development work required by Akraino community instead of upstream open source components.
Examples of Feature Projects include Akraino Portal and Workflows to support common user experience, Blueprint testing modules or suites, Operational tools, Edge SDKs and APIs, etc..
It is a long term endeavor set up to deliver features across multiple releases, which have a shorter lifespan.
The feature project should address the functionality needed by Akraino specified use cases. During the feature project creation the scope should define whether it will support a single or multiple blueprints. Illustration is shown on Figure 4.
Figure 4 – Relationship between Feature Project, Upstream component and Integration project
Akraino Integration Projects create or modify Akraino Blueprints to support specific edge use cases.
A Blueprint is a declarative configuration of an edge Cloud Stack that includes a combination of infrastructure hardware components, software components, Point of Delivery (POD) options, tools to manage the life cycle and CI/CD to manage the blueprint’s code. The blueprint should be production deployable to support one or more Edge applications or Virtual Network Functions (VNFs).
A Blueprint family is a collection of blueprints that share common characteristics and numerous POD types. For example, Network Cloud is a family of blueprints to support any Telco Virtual Network Functions (VNFs). Network Cloud - Unicycle A is a blueprint that supports Unicycle POD and Network Cloud - Rover A is a blueprint which delivers single server POD.
Akraino Blueprints must include the description of the Edge use cases that articulates the desired business outcome, workload characteristics, design constraints, and operational cost ranges.
The Blueprint can either develop or use the upstream lifecycle management (LCM) tools and deployment automation to support the installation of the Blueprints. All Blueprints need to be tested by the Akraino community to prove that Edge applications and/or VNFs can operate effectively on the Blueprint as requested in the use case .
Community members will use a template for use case characteristics, blueprint family and blueprint approved by the TSC to describe the hardware, software, deployment configurations, workload characteristics when requesting the creation or modification of an Akraino Blueprint. The requestor should demonstrate the following aspects to the TSC:
After TSC review and approval of community member request, an integration Project will be launched to develop the Blueprint. In some cases, community may decide to support single or multiple family of blueprints for a use case depending upon the need and interest (Subject to TSC approval). A blueprint or blueprint family may address one or more Edge use cases.
TSC will decide which blueprints or blueprints family to include into a release based on the maturity status of an individual blueprint within a Blueprint family. Maturity of a blueprint is demonstrated with full CD deployment using a validation project and should have addressed the use case for which the blueprint was created. A release could support multiple blueprints. It is a long term endeavor set up to deliver a blueprint across multiple releases, which have a shorter lifespan.
Blueprint Specifications ultimately define the declarative configuration for each deployment model or Point of Delivery (POD) of a Blueprint. The Point of Delivery (POD) defines the method in which a blueprint is deployed to an edge site. PODs organize edge devices for deployment and enable a cookie-cutter approach to large scale deployments (e.g., 10,000 plus locations) at a reduced cost. For example, an edge location could have a single server or multiple servers in one or more racks. Blueprint families use YAML or similar configuration files. The use of YAML files with different manifest file contents will allow for different configurations within the same Akraino blueprint family.
The below diagram (Figure 5) illustrates the process.
Figure 5 – Akraino Blueprint Creation Process
At the Family level, blueprints are differentiated by high level technical attributes which are immutable. Removing or inserting one of these attributes would change any pod delivered by the blueprint to such an extent that it could not reasonably be considered part of the same blueprint family.
For example if a given blueprint family has a Family attribute of deploying a kubernetes based undercloud in a given Akraino release then any pod delivered by that blueprint must also do so.
The decision as to what technical attributes should define the blueprint family will be specific to each blueprint family (and release) and be approved by the TSC.
Each blueprint family should be flexible enough to allow reasonable variation to encourage widespread deployment without requiring the introduction of a new blueprint family. For example, the decision to use Ubuntu or CentOS as the operating system in the Network Cloud blueprint family, should not require a different blueprint family to be introduced instead just different POD configuration (Rover with Ubuntu vs. Rover with CentOS)
The ultimate and final level of classification must be sufficiently definitive to allow any user to reliably deploy a duplicate pod in their own environment. This level of blueprint specification does not prevent a deployable entity (POD) from having a range of possible values (for example Ubuntu 16.X). This ultimate level of technical classification is termed the blueprint Species.
Akraino releases will verify blueprints at this ultimate species level of technical specification to allow reliable and repeated pod replication.
Blueprint taxonomy of technical specification:
→ Family
→ Species (a.k.a blueprint, from which a replica pod can be deployed by anyone)
At the very minimum there would need to be one fully specified and thus deployable pod within a blueprint family (i.e. one species/POD of the blueprint). The number of species within a blueprint family may grow or diminish with Akraino releases.
Note: Specific named examples have been used in this section to help clarify. The use of “Network Cloud” as example only reflects the fact this blueprints had been submitted to Akraino when written.
A use case may be supported by one or more blueprint families i.e. there is not a 1:1 mapping from an Akraino use case to Blueprint families. Likewise a given Akraino blueprint may support multiple Akraino use cases. An example of a Blueprint family are Network Cloud.
Below picture illustrates the Network Cloud blueprint family and POD level specification which allows possibility of different component level.
Figure 6 - Illustration of blueprint family and its blueprints
Akraino use cases are business driven and must include a clear description of business requirements, operational considerations (cost, user interface, scale, power restrictions, etc…) , and applications expected to operate on the Blueprint. Any community member can submit a use case for review by TSC for further development.
The submitter should use the appropriate templates as described below for the creation or modification of blueprint families or blueprints for TSC review.
Use case template and blueprint family templates are required when requesting creation or modification of a blueprint family.
Blueprint templates are required to create or modify blueprints within a blueprint family. In some cases, new or modification to a blueprint may require updates to existing use case templates and/or blueprint family templates and the submitter should make changes to all 3 templates as required.
Figure 7 - Templates needed for blueprint family and blueprint creation and modification
When one or more fully defined blueprint addresses the same use case common test cases should be adopted where possible.
Below are the sample templates of a target family of blueprints and the full template will be maintained on the wiki. Certain attributes shall be defined as informational only. For example cost targets whilst key should not be used to pass or fail the verification of a blueprint
Below is a sample Use case template. The full template will be maintained on the Akraino Wiki.
Use Case Attributes | Description | Informational |
Type | New or Modification to an existing submission | |
Industry Sector | Telco and carrier networks | |
Business driver | Emerging technologies such as 5G (vRAN, Core) and associated Edge Services requires Cloud instance deployed at the edge of the provider network to support latency need. Without Edge Cloud, above said services cannot be enabled. | |
Business use cases | For Example:
| |
Business Cost - Initial Build | For Example:
| |
Business Cost - Operational | For Example:
| |
Operational need | For Example: Edge Solution should have role based access controls, Single Pane of Glass control, administrative and User Based GUIs to manage all network cloud family based blueprints. The automation should also support zero touch provisioning and management tools to keep operational cost lower | |
Security need | For Example: The solution should have granular access control and should support periodic scanning | |
Regulations | For Example: The Edge cloud solution should meet all the industry regulations of data privacy, telco standards (NEBS), etc., | |
Other restrictions | Consider the power restrictions of specific location in the design (example - Customer premise) | |
Additional details | The Edge Cloud Solution should be deployable across the globe and should be able to support more than 10,000 locations |
Below is a sample Blueprint family template. The full template will be maintained on the Akraino Wiki.
Use Case Attributes | Description | Informational |
Type | New or Modification to an existing submission | |
Blueprint Family - Proposed Name | Network Cloud Family | |
Use Case | Network Cloud | |
Blueprint proposed | Central Office deployments
Customer Premise deployments
| |
Initial POD Cost (capex) | Examples Only:
| |
Scale | Examples Only:
| |
Applications | Any type of Edge Virtual Network Functions | |
Power Restrictions | Example Only:
| |
Preferred Infrastructure orchestration | OpenStack - VM orchestration Docker/K8 - Container Orchestration OS - Linux VNF Orchestration - ONAP Under Cloud Orchestration - Airship | |
Additional Details | Submitter to provide additional use case details |
Below is a sample Blueprint template defining an Akraino species. The full template will be maintained on the Akraino Wiki.
Use Case Attributes | Description | Informational |
Type | New or Modification to an existing submission | |
Blueprint Family - Proposed Name | Network Cloud Family | |
Use Case | Network Cloud | |
Blueprint proposed Name | Unicycle A | |
Initial POD Cost (capex) | Examples Only:
| |
Scale & Type |
| |
Applications | 5G Core or vRAN (RIC) | |
Power Restrictions | Example Only:
| |
Infrastructure orchestration | OpenStack Pike or above - VM orchestration Docker 1.13.1 or above / K8 1.10.2 or above- Container Orchestration OS - Ubuntu 16.x VNF Orchestration - ONAP Beijing Under Cloud Orchestration - Airship v1.0 | |
SDN | SR-IOV & OVS-DPDK or VPP-DPDK | |
Workload Type | VMs and Containers | |
Additional Details | Submitter to provide additional use case details |
Multiple labs will be used to validate Akraino projects to ensure production quality of blueprint and/or feature project releases. The Community CI lab is owned by the Akraino community and LF. In addition a number of Edge Validation labs are owned by an Akraino community company, organization or participant.
Comprehensive validation of the blueprint within the community will include testing of the OS layer, the undercloud layer, the upper cloud layer, VNF layer and the application layer. Test results should be available to the Akraino community for review via automated push to the wiki. Any defects identified should be logged in JIRA and assigned to the responsible party. When defects are identified in upstream components, Akraino coordinators should be assigned defect ownership. Akraino coordinators will work with upstream communities to resolve defects. For defects that do not involve upstream communities, impacted Protect Technical Leaders should be assigned defect ownership.
Akraino Validation Projects will also include testing of Akraino releases.
An automation framework should be used for test procedures and leverage existing test automation suites for upstream projects as required. It is the responsibility of the blueprint submitter to ensure that the Edge Validation and Community CI labs can support comprehensive validation of the blueprint and cover all use case characteristics.
The TSC subcommittees tasked with the setup and structuring of operating procedures for the validation labs shall work to define the licensing requirements for the external labs.
The Akraino Community CI labs are owned by the Akraino community and LF. Access is controlled by LF best practices.
TSC will propose a subcommittee to maintain and coordinate the Community CI lab.
The following would be conducted in the Community CI lab:
A full CD that works with the Akraino CI pipeline should be included in the validation project.
Akraino Edge Validation labs are owned by an Akraino community company, organization or participant.
The Validation labs can be owned and operated by the supplier of the lab with limited access or no access to the hardware but results of the validation testing need to be shared to the community.
TSC will propose a subcommittee to maintain and coordinate the Validation labs.
Blueprint, application and VNF testing may be performed over a number of Validations labs concurrently in a coordinated manner as required.
The test plan and associated test cases to validate the blueprint will be published on the Akraino wiki and reviewed by blueprint stakeholders.
Open source test tools and vendor tools with appropriate configurations should drive test traffic profiles that mimic in-scope use cases. Akraino coordinators will engage upstream open source communities to get access to upstream community labs for the Akraino blueprint test team. The submitter is responsible to establish access to necessary vendor labs.
Akraino blueprint releases ensure that applications and virtual network functions (VNFs) can on-board and operate effectively on the Akraino solution. Validation labs can be further used for the validation of Edge applications and VNFs.
Application and VNF testing may take a number of forms including performance, scalability, security and usability, resilience etc.
Submission of results to the Akraino community is optional in case of commercially sensitive applications.
The project lifecycle provides the freedom for each team to conduct its project according to their needs, culture and work habits. Thus, the project lifecycle is not prescriptive on how each project operates.
Individual blueprint within a blueprint family shall not be tied to the overall Akraino release schedule (e.g. 6 months). An Akraino release can be composed of 1 to N fully verified blueprints or individual feature projects. As such the number of blueprints and contributing projects within a given Akraino release may vary overtime. Figure 8 show this with two blueprint families, Network Cloud and the imaginary Canis Edge and a number of individual blueprint species within each family.
Figure 8 - Project and Akraino release lifecycles
Each project shall provide an expected release plan document published with the blueprint on the wiki. From the project schedules an overall Akraino release schedule shall be maintained and published.
The project lifecycle process does not impose a duration for the project nor for individual project releases.
Akraino projects’ life cycles defines five states that all three project goes through. A project lifecycle may extend across multiple projects and Akraino releases.
The procedure of moving from one state to the next one is independent from the Akraino release lifecycle and the pace depends on each individual project.
In order to effectively review project progress, four reviews are built-in to the project life cycle.
The life cycle of a project is depicted in the following diagram:
Project State | Description |
Proposal | Project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to business needs. |
Incubation | Project has resources, but is recognized to be in the early stages of development. The outcome is a minimum viable product (MVP) that demonstrates the value of the project and is a useful vehicle for collecting feedback, but is not expected to be used in production environments. |
Mature | Project is fully functioning and stable, has achieved successful releases. |
Core | Project provides value to and receives interest from a broad audience. |
Archived | Project can reach Archived state for multiple reasons. Either project has successfully been completed and its artifacts provide business values, or project has been cancelled for unforeseen reasons (no value anymore, technical, etc.). Project in any state can be Archived through a Termination Review. |
Figure 9 – Akraino Project States
To move from one state to the next state, the Project Team has to formulate a Kick-Off release review to the TSC, by specifying its goal to move up the Project Lifecycle ladder.
From State | To State | Review Description |
Null | Proposal | |
Proposal | Incubation | Incubation review |
Incubation | Mature | Maturity review |
Mature | Core | Core review |
Core | Archived | Termination review |
Note 1: Project proposals are posted in the “Proposed Projects” section of the Akraino wiki. Approved projects are posted to the “Approved Projects” section of the Akraino wiki.
The TSC will review each project proposal request and then vote to approve or reject. Requestors should identify the different Point-of-Delivery options that should be enabled via the Blueprint creation / modification request, explain the continuous integration / continuous deployment (CI/CD) methodology that will be used, explain the test framework that will be used for the Blueprint and define the automation that will be needed to deploy Akraino based on the Blueprint.
Note 2: The proposal submitter can decide to remove projects in “proposal” state that do not progress to incubation state.
A project’s release cycle may be tailored by allowing some exceptions to the normal release process. Tailoring may be initiated in two ways:
Tailoring practices will be documented as we progress through our releases. The TSC should respond to requests in a timely manner.
Project promotion across states can only be done by TSC review and voting. During the reviews the candidate projects are evaluated based on predefined metrics and KPIs. The target numbers may vary for each project and state.
For each and every review the following steps are required:
Reviews for multiple projects can occur at the same time.
During Release Kick-Off, the project team may request that the TSC conduct a review to move up the ladder.
The goal of the Incubation Review is to officially launch the project and to support its needs until project Termination Review.
Once a project has passed the Incubation Review, the project is in Incubation State and may span over multiple releases.
Proposal template will be maintained in the wiki.
The following artifacts are expected:
The goal of the Maturity Review is to ensure:
Once a project has passed the Maturity Review, the project is in Mature State and may span over multiple releases.
Review metrics for Maturity review:
The goal of the Core Review is to ensure:
Once a project has passed the Core Review, the project is in Core State and may span over multiple releases.
Review metrics for Core review include the metrics for maturity review plus the following:
The goal of the Termination Review is to ensure that:
A Project’s Committers make all decisions about Releases of that Project. However, to be eligible to be considered ‘Mature’, the project must demonstrate a history of following the Mature Release Process. The purpose of the Mature Release Process is to insure openness and maximum opportunity for participation. The idea is to have a simple, clear, public declaration of what a project intends to do and when, and what was actually done in a release cycle. Towards that end, a project following the ‘Mature Release Process’ should have a Release Plan published at the beginning of its release cycle by its committers, and a Release Review just prior to the project release.
Both Release Plan and Release Review documents are intended to be relatively short, simple, and posted publicly on the wiki to assist project in coordinating amount themselves and the general world in gaining visibility.
These should contain roughly the following sections:
The TSC may make amendments to this Technical Community Document at any time with a simple majority of the members of a quorum of the TSC as defined in section 4.4.1.
Active Contributors are the cornerstone of the TSC.
Anyone Akraino community member with twenty (20) or more measurable contributions as assessed by the TSC during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, or JIRA activities.
At the transition time the qualification period will be from the point of project inception to the transition date.
TSC Members consist of an elected subset of up to 20 people from the community’s Active Contributors.
Only TSC members have voting rights for decisions taken by the TSC and each TSC member has a single vote.
TSC Membership is bestowed to a subset of Active Contributors through election(s) by the Active Contributors as defined in section 4.4.3.
The TSC functional roles of chair and co-chair will be held by TSC members.
Figure 10 - Akraino Community Structure
In addition to Active Contributors and TSC Members there are other roles within the community such as TSC Chair, TSC Co-Chair, Coordinators, project specific committers and others.
Community members with functional roles are not TSC members in their own right.
The TSC Chair and Co-Chair are elected by the TSC members.
The TSC Chair and Co-Chair are elected for a term of one year.
The TSC members shall hold elections to select a TSC Chair and Co-Chair at the Transition Point and subsequently every year within one month of the yearly anniversary of the date of the Transition Point.
There are no limits on the number of terms a TSC Chair and Co-Chair may serve.
The Chair and Co-Chair work together to share the responsibilities of chairing the TSC.
The primary responsibility of the TSC Chair and Co-Chair are to represent the technical community in communications with the LF Akraino Fund of The Linux Foundation and to be responsible for:
Leading TSC meetings;
This responsibility may be delegated to another TSC Member (in such case, this is to be informed via the TSC email list)
Representing the technical community to external organizations.
These responsibilities may be delegated to another member of the technical community.
Lead the TSC in the execution of the TSCs responsibilities (section 4.3).
Coordinators are not members of the TSC per se. However a Coordinator may also be a member of the TSC in their own right as an elected Active Contributor.
The TSC has multiple coordinator roles. Each coordinator role comes with its own set of responsibilities to discharge in serving the community via coordinating among various parties.
A coordinator can act as the ambassador to external upstream communities in communicating the requirements need to be addressed in the upstream community on behalf of Akraino Feature or Blueprint project. TSC can appoint either Akraino level or project level coordinators to facilitate upstream coordination work. Coordinators can act as a technical liaison only and cannot represent strategy aspects of the Akraino which will be handled by TSC.
A coordinator is an internal role, so while a coordinator may coordinate among various external liaisons in some instances, being a coordinator does not imply being the liaison to any particular external organization or group of organizations.
Coordinators support the TSC Chair in the execution of TSC responsibilities (Section 4.5) and the delivery of Akraino releases. They are responsible for fostering collaboration among the many parties that need to work together to identify, characterize, and solve problems, they do not direct solutions.
The TSC will solicit nominations for the role. Nominees should have subject matter experience in the relevant coordination area. In the event that multiple candidates self-nominate, the TSC will hold an election as defined in section 4.4.3.3.
The coordinator will regularly report status and issues to the TSC via the Akraino-TSC email list.
There is a lifecycle for the coordinator responsibility (coordination area) and the coordinator appointment.
Coordination Area Creation
A coordination area is created by sending a request to the TSC via the Akraino-TSC email list. The email shall have:
- Email Subject: Creation Request for coordination area: <coordination area name>
- Coordination Area responsibility description: <Description of the coordination area responsibilities>
- Reporting Cadence: <description of when reporting is expected to be delivered to the TSC>
- Area Coordinator: <Name of the TSC nominated area coordinator> (Can be blank)
The decision to create the coordination area is created by a TSC decision by simple majority as defined in section 4.4.1 . A decision can be made with modification, with the modifications captured in the TSC minutes. Once a coordination area is created, it will be documented in the Akraino Wiki.
Coordination Area Update
- A coordination area can be updated by sending a request to the TSC via the Akraino-TSC email list. The email shall have the following: Email subject: Update Request for coordination area: <coordination area name>
- Proposed Update: <Clearly described update of the coordination area. This could be the Area Responsibility Description; Reporting Cadence; Area Coordinator>.
The decision to update the coordination area is created by a TSC decision (according to the TSC voting rules). An update decision can be made with modification requests, with the proposed modifications captured in the TSC minutes. Once a coordination area is updated, the updates will be documented in the Akraino Wiki.
Coordination Area Termination
A coordination area can be terminated by sending an email to the TSC via the Akraino-TSC email list. The email shall have the following.
- Email Subject: Close Request for coordination area: <coordination area name>
- Motivation: <Motivation for closing the coordination area>.
The decision to close the coordination area is created by a TSC decision (according to the TSC voting rules). Once a coordination area is updated, the coordination area will be removed from the Akraino Wiki.
At the transition point and until changed by the TSC there shall be up to 20 seats on the TSC including the chair and co-chair.
Decisions of the TSC should be made by majority vote of TSC Members.
A TSC vote requires a quorum of TSC members to be valid, a quorum consisting of at least 51% of TSC Members present or casting a vote.
Any vote of TSC members that result in a tie shall be considered as not approved.
There are no limitations on the number of candidates that can run in an election for TSC membership, nor is there a limit to the number of candidates from any organization including its subsidiaries (hereon termed simply an ‘organization’) that can run for TSC membership. However the limits as defined in the TSC technical charter 4.4.3.2.1 section (TSC approved 9/5/19) for the total number of TSC members from a given organization shall be enforced by means of the election and interim election process described in 4.4.3
Candidates must self nominate.
Any Active Contributor community member is eligible to run for TSC membership
Any Active Contributor community member is eligible to vote in a TSC Member election
Eligibility is effective as of the date and time the nomination process starts
Elections for the role of TSC Chair and Co-Chair shall be held immediately after each year TSC Member election.
Candidates must self nominate.
All TSC members are eligible to run for the roles of Chair or Co-Chair.
There are no limits on the number of terms a TSC Chair and Co-Chair may serve.
All TSC Members are eligible to vote in a TSC Chair and Co-Chair election.
The TSC Coordinators shall be elected separately. There is no prohibition against a person holding the role of Chair or Co-Chair and Coordinator or other non TSC role.
Elections are held annually to re-elect existing Coordinator roles. Elections for new Coordination roles are as required. The TSC Members shall elect coordinators from community members as defined in section 4.4.3.3.
Candidates must self nominate (even if nominated by the TSC).
Any community member (regardless of TSC membership) is eligible to serve as a coordinator. Nominees should have subject matter experience in the relevant coordination area.
There are no limits to the number of terms an individual can serve.
All TSC members shall be elected at the Transition Point and subsequently every year within one month of the yearly anniversary of the date of the Transition Time.
The annual election of TSC Members shall consist of a single stack ranked vote of all candidates to select the remaining 20 TSC members via CIVS https://civs.cs.cornell.edu/
All TSC Active Contributors may cast a single vote
The CIVS election wil rank all standing candidates from 1 to N.
Only one (1) person from any company, or a group of related companies can be elected as a TSC member at any given time. (TSC approved 9/5/19)
If any organization entered more than the permitted limit of electable candidates all excess candidates shall be removed from the results from the least ranked upwards until the organization limit is reached.
Once this is done the remaining 20 highest ranked candidates shall be elected to the TSC.
In case a TSC member, including Chair or Co-Chair, steps down or is required to step down due to, no longer able to perform the TSC duties, moved to a different company (TSC approved 9/5/19), organization limits being exceeded or as a result of company acquisitions or mergers after each yearly election, an interim election may be called by the TSC . (TSC approved 9/5/19)
In all above cases, the TSC member may inform via an email to the TSC email list, an interim election may be called by the TSC for that single position within 60 days of the notification from the leaving TSC member. Interim election can be used to reelect the open TSC position. The period of the TSC member elected using the interim election can be up to next full election. (TSC approved 9/5/19)
In an interim election, any organization eligible contributors (TSC approved 9/5/19) may only enter candidates if their current representation on the TSC is below their organization’s TSC Member limit.
Interim elections shall otherwise follow all the same procedures and use the same voting schemes as the yearly elections.
The TSC will elect from amongst TSC Members a chairperson and co-chairperson for a term of one year.
The TSC shall hold elections to select a TSC Chair and Co-Chair at the Transition Point and subsequently every year within one month of the yearly anniversary of the date of the Transition Point.
Election of a TSC Chair/Vice Chair/Coordinator shall use a multiple-candidate method shall consist of a single stack ranked vote of all candidates using CIVS https://civs.cs.cornell.edu/
4.4.3.4 TSC Member Contributions (TSC approved 9/5/19)
Contributions to the Akraino Community may be counted as either ‘individual’ or “individual contribution on behalf of a company”. A ‘individual’ contribution is made by a named individual. An “Individual contribution on behalf of a company” are governed by the policy of an individual’s Organization to whom they were affiliated at the time of the contribution. Individual contributions cannot be transferred to other individual.
For the TSC election purpose, the Organization can request the TSC to count an “individual contribution on behalf of a company” to another named individual of their Organization at any time regardless of whether the original Contributor remains in or has left the Organization. If an individual Contribution leaves an Organization that Organization may at their sole discretion decide to: retain all their Contributions and reallocate them to another named individual within their Organization (for the TSC election purpose). Organization should inform TSC of such details of contributions and reallocation in writing.
OR
agree to transfer all their Contributions to the individual’s new Organization thereby releasing all interest in the previous Contributions to the Individual’s new Organization. Organization should inform TSC of such details of contributions and releasing in writing.
[[ Text below in this color proposed for TSC consideration, Jeff (JHB) 15Jan22. Text in this color added by Jeff per suggestions from Ike and Kural ]]
Subject to the Technical Charter, the TSC is responsible for:
The TSC shall be responsible for identifying and recruiting suitable organizations amenable to cooperation in establishing centers providing technical and marketing resources in geographically distinct areas to support Akraino blueprint teams and groups based in those areas. Such "localized" areas are typically characterized by language, time-zone, and international differences, for example the TSC might seek to establish a South America center, an Africa center, a Shenzhen center, etc.
When an organization has been identified, TSC members shall meet to discuss and evaluate the organization to determine its suitability, based on the following technical, marketing, and operational criteria:
During the discussion and evaluation phase, the TSC may at its option nominate and vote to approve an Akraino representative to act as "point person" to work with the candidate organization's senior / authorized management to resolve concerns, negotiate objectives and requirements, gather facts and data, and otherwise act on behalf of the TSC. This person might be a TSC member, subcommittee chair or co-chair, or other.
After the discussion and evaluation phase, the TSC shall vote to decide whether to formally engage with the candidate organization. Should the vote succeed, the TSC shall present the candidate organization, along with its evaluation results, to Akraino's parent LF Edge management for further, formal action.
The TSC, at its discretion, may establish subcommittees to assist the TSC with its responsibilities and provide expert guidance in technical subject areas (e.g., architecture or security).
The TSC may amend or introduce alternative approaches to convene and run subcommittees.
It is expected that subcommittee membership shall be open to all Akraino Contributors; however, subcommittees [or TSC] may impose restrictions such as the number of participants from a single company [organization]. While the desire may be to keep its size and scope limited, each subcommittee shall be open to the Akraino membership.
Each subcommittee may elect a Chair and optionally a Co-Chair who is responsible for leading meetings and representing the subcommittee to the TSC.
The Chair or Co-Chair will be elected by members of the subcommittee as of the date the nomination process starts for the election.
All members of the subcommittee are eligible to vote.
The elected Chair (and/or Co-Chair) is submitted to the TSC for confirmation. The TSC decides to accept the outcome or requests a new voting.
Subcommittees are advisory in nature, and not authoritative. They provide advice to projects and to the TSC.
Subcommittees operate on a rough consensus basis. If the subcommittee is unable to reach consensus on what advice to offer, the subcommittee Chair shall raise the issue with the TSC, where a formal vote can be taken, or advise the project that the subcommittee cannot reach consensus.
The TSC decides the creation of a subcommittee in accordance with TSC decision procedure.
In order to create a TSC subcommittee, a TSC member shall make a proposal to the TSC (via Akraino-TSC email list) that that shall cover at least the following:
In addition to the TSC nominated participants, members of the community who wish to participate shall self nominate to the TSC and shall become Subcommittee members without election
Members of the sub-committee who want to run for Chair for the subcommittee self nominate
The TSC can modify a TSC subcommittee via a TSC decision. To request such a modification, a request is made to the Akraino-TSC email list.
The TSC decides the termination of the TSC subcommittee in accordance with the TSC decision procedure. The submission of a request to terminate the TSC subcommittee should cover:
As a guideline, a subcommittee is most appropriate when the task to be addressed involves a relatively stable group of people with a high level of intersection of common involvement. A coordinator is more appropriate when there is a more dynamic group of people and issues may change frequently. A coordinator is also more appropriate for smaller efforts or topics requiring infrequent meetings.
Term | Full Meaning |
IoT | Internet of things |
PTL | Project technical lead |
ETE | End to end |
SDK | Software development kit |
API | Application program interface |
POD | Point of delivery |
CI/CD | Continuous integration and continuous delivery |
LCM | Lifecycle management |
YAML | YAML Ain't Markup Language. It's basically a human-readable structured data format. |
OS | Operating system |
EOL | End of life |
VNF | Virtual Network Function (VM or container based) |
CIVS | Condorcet Internet Voting Service |