Difference between revisions of "Project Proposals/vppcfg"

Revision as of 20:56, 5 April 2022

Name

VPP Configuration utility, or vppcfg for short.

Project Contact Name and Email

Pim van Pelt <pim@ipng.nl>

Repository Name

vppcfg

Description

vppcfg is a commandline utility that applies a YAML based configuration file safely to a running VPP dataplane. It contains a strict syntax and semantic validation, and a path planner that brings the dataplane from any configuration state safely to any other configuration state, as defined by these YAML files.

vppcfg consumes YAML files of a specific format. Their validity is asserted by two main types of validation:

• syntax checks are performed and this ensures that all fields in the YAML file are correctly formed, that field-names are correctly spelled, that no extra fields are given, and their values are of the correct type.
• semantic validations are performed to ensure that configurations are safely applyable to a running VPP. Note: Some semantic checks are stricter than VPP, because applying them may leave the dataplane in a non-recoverable state.

Then, a path is planned from the current running VPP dataplane configuration to the desired target configuration.

The tool already exists on github.com/pimvanpelt/vppcfg

It would benefit to be adopted not only by downstream VPP users, but by the VPP developer community and fd.io for its integration testing, regression testing, and developer workflow, as that process ensures vppcfg develops into and stays a first class citizen. For this reason, more committers and maintainers are sought as a part of this application.

Scope

The scope of vppcfg is: - a declarative description of the configuration of anyone appropriate/required VPP APIs, in YAML format. - a set of syntax constraints that validate a YAML file is correctly formed - a set of semantic constraints that validate the config expressed in the YAML file can be correctly applied. - a set of temporal constraints and a DAG that create a path based on object pruning, object creation and object attribute synchronization

The APIs and object types that vppcfg is targeted to handle are:

• Any 'core' APIs that are stable
• Any 'plugin' APIs that are stable.
• (low-pri) any 'plugin' APIs that are in development.

APIs and object types that cannot be safely provisioned, or have runtime attributes that are not able to be programmatically get/set, will be opted out based on a friction report against the feature/plugin/API owner. As a by-product of this work, API and object friction reports (ie. poor error handling, bounds checking, crashes in API / CLI calls, etc) will be emitted against feature/plugin/API owners.

Details and two papers on the topic:

• https://ipng.ch/s/articles/2022/03/27/vppcfg-1.html
• https://ipng.ch/s/articles/2022/04/02/vppcfg-2.html

Initial Committers

Pim van Pelt <pim@ipng.nl>, Dave Wallace <dwallacelf@gmail.com>, ... two more

Vendor Neutral

There is no desire or need for vppcfg to commit or champion any given vendor. It's purpose is to configure the open source fd.io version of the VPP dataplane based a YAML configuration file. No external tools or projects/products will be in scope for vppcfg to configure. In principle, the only entity it will be talking to is the CLI and API endpoints provided by VPP itself.

Meets Board Policy (including IPR, being within Board defined Scope etc)

Meets board policy as expressed in Technical Community Charter and IP Policy

Administrata

• Request for Project proposal consideration
  • Email: (place link to email to TSC proposing project, this can be obtained from TSC Archives
  • Date: (date proposed, makes it simpler to calculate the pre-requisite 2 week time period of gestation before being permitted to be voted on)