...
2.1 Technical Mission of Akraino Edge Stack
The Akraino Edge Stack Technical mission to focus on following areas
...
Figure 3 – Akraino Edge Stack Project Types & Scope
...
3.3.2.1 Akraino Edge Stack Feature Projects (a.k.a Development Project)
...
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
3.3.2.2 Akraino Edge Stack Integration Projects (Blueprints)
...
Figure 5 – Akraino Blueprint Creation Process
3.3.2.2.1 Akraino Blueprint Family and Life Cycle of Blueprints
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.
...
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
3.3.2.2.2 Akraino Use Cases, blueprint families and 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.
...
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
...
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
3.3.2.2.2.1 Template 1 - Use case template
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 |
|
3.3.2.2.2.2 Template 2 - Blueprint family template
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 |
|
3.3.2.2.2.3 Template 3 - Blueprint species template
Below is a sample Blueprint template defining an Akriano species. The full template will be maintained on the Akraino Wiki.
...
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.
3.3.2.3.1 Feature project unit testing in Community CI lab
The Akraino Community CI labs are owned by the Akraino community and LF. Access is controlled by LF best practices.
...
A full CD that works with the Akraino CI pipeline should be included in the validation project.
3.2.2.3.2 Blueprint and application testing in Akraino Edge Flock lab
Akraino Edge flock labs are owned by an Akraino community company, organization or participant.
...
- The Flock labs should be able to connect to Akriano Edge Stack CI hosted by LF to pull in Akraino blueprints for the validation. Necessary Firewalls can be opened by the Akriano Community on request.
- All Flock 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 Flock labs should be declared and information should be documented in the wiki
- All the Flock 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.
3.2.2.3.2.1 Blueprint testing
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.
3.2.2.3.2.2 Application and VNF testing
Akraino blueprint releases ensure that applications and virtual network functions (VNFs) can on-board and operate effectively on the Akraino solution. Flock labs can be further used for the validation of Edge applications and VNFs.
...
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
...
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
...
- Introduction
- Release Deliverables
- Release Milestones
- Expected Dependencies on Other Projects
- Compatibility with Previous Release
- Themes and Priorities
- Features delivered
- Non-Code Aspects (user docs, examples, tutorials, articles)
- Architectural Issues (if any)
- Security Issues (if any)
- Quality Assurance (test coverage, etc)
- End-of-life (API/Features EOLed in Release)
- Summary of Outstanding Bugs
- Summary of Standards Compliance
- Delta between planned schedule and actual schedule
- Features delivered
- Non-Code Aspects (user docs, examples, tutorials, articles)
- Architectural Issues (if any)
- Security Issues (if any)
- Quality Assurance (test coverage, etc)
- End-of-life (API/Features EOLed in Release)
- Summary of Outstanding Bugs
- Summary of Standards Compliance
- Delta between planned schedule and actual schedule
3.3.8.2 Release Review
- Features delivered
- Non-Code Aspects (user docs, examples, tutorials, articles)
- Architectural Issues (if any)
- Security Issues (if any)
- Quality Assurance (test coverage, etc)
- End-of-life (API/Features EOLed in Release)
- Summary of Outstanding Bugs
- Summary of Standards Compliance
- Delta between planned schedule and actual schedule
3.4 Amendments to the Technical Community Document
...
Figure 10 - Akraino Community Structure
4.3 TSC Functional Roles
...
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.
4.3.3.2 Coordinator origin
...
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.
...
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.
...
Candidates must self nominate.
4.4.2.1.1 Candidate and Voter Eligibility
Any Active Contributor community member is eligible to run for TSC membership
...
Candidates must self nominate.
4.4.2.2.1 Candidate and Voter Eligibility
All TSC members are eligible to run for the roles of Chair or Co-Chair.
...
Candidates must self nominate (even if nominated by the TSC).
4.4.2.3.1 Candidate and Voter Eligibility
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.
...
All TSC Active Contributors may cast a single vote
4.4.3.2.1 Enforcement of organization TSC member limits.
The CIVS election wil rank all standing candidates from 1 to N.
...
Once this is done the remaining 20 highest ranked candidates shall be elected to the TSC.
4.4.3.2.2 Interim elections
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 result of company acquisitions or mergers after each yearly election, an interim election may be called by the TSC.
...