Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

Table of Contents

Introduction

The Akraino Edge Stack technical project has been established as Akraino Project a Series of LF Projects, LLC (“Akraino Edge Stack” or, 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.  “Akraino” is the term used in this document that refers to ”Akraino Edge Stack” (full form).  

1   Guiding Principles 

The Akraino Edge Stack 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.

2.1   Technical Mission of Akraino

...

The Akraino Edge Stack 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 Edge Stack releases.

The Edge cloud stack placement could vary between Telco Offices to Customer premise and anything in between. Akraino Edge Stack community blueprints should be capable to deploy and address different edge cloud placement options. 

...

This document covers the Akraino project lifecycle. The Release Lifecycle will be documented in the  wiki.

3.3.2   Akraino

...

Project Types

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 Edge Stack 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 Edge Stack Project Types & Scope

3.3.2.1   Akraino

...

Feature Projects  (a.k.a Development Project)

The Akraino Edge Stack 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.

...

Figure 4 – Relationship between Feature Project, Upstream component and Integration project

 


3.3.2.2   Akraino

...

Integration Projects (Blueprints)

Akraino Integration Projects create or modify Akraino Blueprints to support specific edge use cases. 

...

  1. Each initial blueprint is encouraged to take on at least two Committers from different companies
  2. Complete all templates outlined in this document
  3. A lab with exact configuration required by the blueprint to connect with Akraino CI and demonstrate CD. User should demonstrate either an existing lab or the funding and commitment to build the needed configuration.
  4. Blueprint is aligned with the Akriano Akraino Edge Stack Charter
  5. Blueprint code that will be developed and used with Akraino repository should use only Open Source software components either from upstream or Akriano Akraino projects.
  6. For new blueprints submission, the submitter should review existing blueprints and ensure it is not a duplicate blueprint and explain how the submission differs . The functional fit of an existing blueprint for a use case does not prevent an additional blueprint being submitted.

...

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:

      
  1. Customer Edge deployable at Customer premises such as home, enterprises, offices to support Edge services such as SD-WAN
  2.   
  3. Customer Edge deployable at Public buildings such as Stadiums, Smart cities, etc., to support edge applications for example - Video Analytics, AI/ML based detection, etc.,
  4.   
  5. Edge Cloud deployable at Cell tower to support RAN related workload
  6.   
  7. Edge Cloud deployable at Central offices ranging from one rack to multiple racks

 


Business Cost - Initial Build

For Example:

      
  1. Edge Cloud deployable at Central offices with single rack should be less than 150K $

 


Business Cost - Operational

For Example:

      
  1. Edge Cloud deployable at Central offices with single rack should be less than 100K $ as operating cost per year.
  2.   
  3. In-place upgrade of the Edge cloud should be supported without impacting the availability of the edge applications

 


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 


 3.3.2.2.2.2   Template 2 - Blueprint family template

...

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

  •   Unicycle
  •   Tricycle
  •   Cruzer

Customer Premise deployments

  •   Rover
 


Initial POD Cost (capex)

Examples Only:

  •   Rover less than $20k
  •   Unicycle less than $150k
  •   Tricycle less than $300k
  •   Cruzer less than $800k
 


Scale

Examples Only:

  •   Rover - 1 server
  •   Unicycle - 1 rack
  •   Tricycle - 3 racks
  •   Cruzer - 6 racks
 


Applications

Any type of Edge Virtual Network Functions

 


Power Restrictions

Example Only:

  •   Cruzer - less than 50k watts

 


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

 


 3.3.2.2.2.3   Template 3 - Blueprint species template

Below is a sample Blueprint template defining an Akriano 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:

  •   Unicycle less than $150k
 


Scale & Type

  •   Up to 7 servers
  •   x86/ARM server or deep edge class

 


Applications

5G Core or vRAN (RIC) 


Power Restrictions

Example Only:

  •   Less than 10Kw
 


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 

 



3.3.2.3   Akraino Validation Projects

...

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 Edge Stack 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.

...

  • The Validation labs should be able to connect to Akriano Akraino Edge Stack CI hosted by LF to pull in Akraino blueprints for the validation. Necessary Firewalls can be opened by the Akriano Akraino Community on request.
  • All Validation labs should be available most of the year for the community use and if the lab is not used for validation more than 3 consecutive months then it will be removed from the community list.
  • Hardware and Network configuration used within the Validation labs should be declared and information should be documented in the wiki
  • All the Validation labs addition, modifications or removable need to be approved by TSC
  • All historic results (minimum of 1 year) of blueprint validation, Applications and VNF testing should be maintained in the wiki.

...

Submission of results to the Akriano Akraino community is optional in case of commercially sensitive applications.

...

From State

To State

Review Description

Null

Proposal 


Proposal

Incubation

Incubation review

Incubation

Mature

Maturity review

Mature

Core

Core review

Core

Archived

Termination review

...

The primary responsibility of the TSC Chair and Co-Chair are to represent the technical community in communications with the LF Akraino Edge Stack Fund of The Linux Foundation and to be responsible for:

...

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 Akriano Akraino Feature or Blueprint project. TSC can appoint either Akriano 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 Akriano Akraino which will be handled by TSC.

...

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

...

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.

...

In case a TSC member, including Chair or Co-Chair, steps down or is required to step down due to organization limits being exceeded or as a , 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 an organization may only enter candidates if their current representation on the TSC is below their organization’s TSC Member limit.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 Interim elections shall otherwise follow all the same procedures and use the same voting schemes as the yearly elections.

...

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

...

Subject to the Technical Charter, the TSC is responsible for:

...

.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.

4.5   Responsibilities of the TSC

Subject to the Technical Charter, the TSC is responsible for:

  • Defining Akraino’s release vehicles (such as a Coordinated Release) that align with the Project’s mission
  • Fostering cross-project collaboration
  • Serving as Akraino’s primary technical liaison body with other consortiums and groups
  • Developing an architecture
  • Setting simultaneous release dates
  • Defining release quality standards
  • Defining technical best practices and community norms (including the establishment and maintenance of a Development Process)
  • Monitoring technical progress
  • Mediating technical conflicts between Committers and PTLs
  • Organizing inter-project collaboration
  • Coordinating technical community engagement with the end-user community
  • Identifying and Recruiting Akraino Localized Organizations

4.5.1 Identifying and Recruiting Akraino Localized Organizations

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:

  • The organization must present a public website with goals and mission statement indicating a non-profit, open, collaborative nature, preferably with .org domain suffix. Examples include foundations, consortiums, development communities, user communities, etc.
  • The organization must be a technical organization, with emphasis on open source software and hardware
  • The organization must be engaged in sufficient marketing and promotional efforts, including online and social media. The organization must be able to incorporate Akraino web links, material, and blueprint documentation in substantial, appropriate, and prominent manner
  • The organization may be associated with academic institutions
  • The organization may have sponsor companies
  • The organization must demonstrate support, or an acceptable plan of support, for a range of CPU types, including but not limited to x86, Arm, RISC, SoC (e.g. FPGA with CPU cores)
  • The organization may provide working area(s), including WiFi or other Internet capable of online video/audio collaboration. Server and other development hardware resources are preferred but not required
  • The organization must agree to comply with Policy and Operational Procedures as listed on the Akraino Regional Communities page

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. The point person may be a TSC member, subcommittee chair or co-chair, or other. The point person may recruit others to help with the effort. As one example, the TSC might designate the "Outreach Subcommitee" chair as the point person, who then might recruit helpers from other subcommittees or blueprint projects.

After the discussion and evaluation phase, including updates from the point person if one has been designated, 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 Linux Foundation management for further, formal action

...

.

4.6   TSC Subcommittees

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 From time to time, (a) the TSC may amend or introduce alternative approaches to convene and run subcommittees and (b) decide to disband subcommittees that are no longer active or that no longer have any active members.

4.6.1   Membership

4.6.1.1   Subcommittee Membership Eligibility

...

Each subcommittee may elect a Chair and optionally a Co-Chair who is responsible for leading meetings and representing the subcommittee to the TSCthe subcommittee to the TSC.

4.6.1.3   Subcommittee Chair / Co-Chair Elections

The Chair or Co-Chair will be elected by members of the subcommittee as of the date the nomination process starts for the election.

4.6.1.

...

3.1   Subcommittee Interim Elections

In case a subcommittee The Chair or Co-Chair will be elected by members of the subcommittee as of the date the nomination process starts for the electionsteps down or isno longer able to perform subcommittee duties (for example, moved to a different company, no longer active in Akraino, etc), an interim election may be called by the TSC. The term of the subcommittee Chair or Co-Chair elected as a result of the interim election can be up to the next full election.

Interim elections shall otherwise follow all the same procedures and use the same voting schemes as yearly elections.

4.6.1.4   Subcommittee Voter Eligibility

...

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

...