IMPORTANT NOTE Beginning with the 'Jakarta' release a project/repository contributing to the documentation of the release needs to ...
|
|---|
TABLE OF CONTENTS
Short Explanation
Table: Maintained Repositories
- Containing documentation repositories for the upcoming release
- Table handled commonly by the ONAP projects and the Documentation team.
- In the column header you find the responsibility for this column (DOC|PROJECT).
Table: Non-Relevant Repositories
- Containing documentation repositories no longer relevant for the upcoming release
Unmaintained Repositories
Beginning with the 'Jakarta' release, unmaintained projects/repositories are no longer contributing to the documentation if there is no TSC exception.
Maintained Repositories Table
| # | Project Name (common abbreviation of the project or subcommittee) Responsibility: | Repository Name (contains documentation to be published with the upcoming release) Responsibility: | ReadTheDocs Link (link pointing to RTD 'latest' main index.rst; main title used in index.rst) Responsibility: | Repository Status (new | changed | remove ; status of documentation; needed to e.g. identify changes in the intersphinx linking) Responsibility: | Documentation Owner(s) (responsible for documentation in this repo; please use @ notation for the name) Responsibility: | Documentation available: (relevant for new repos which are participating the first time)
Responsibility: | Documentation available:
Responsibility: |
|---|---|---|---|---|---|---|---|
| M2 | M2 | M2 | M2 | M2 | M4 | RC0 | |
| 01 | AAI | aai/aai-common | AAI Documentation Repository | changed |
|
| |
| 02 | AAI | aai/sparky-be | Sparky - Inventory UI Service | no updates |
|
| |
| 03 | CCSDK | ccsdk/apps | CCSDK APPS DOCUMENTATION REPOSITORY |
|
| ||
| 04 | CCSDK | ccsdk/cds | CONTROLLER DESIGN STUDIO (CDS) |
|
| ||
| 05 | CCSDK | ccsdk/distribution | Common Controller Software Development Kit |
|
| ||
| 06 | CCSDK | ccsdk/features | SDN-R Online help |
|
| ||
| 07 | CCSDK | ccsdk/oran | ccsdk/oran |
|
| ||
| 08 | CLI | cli | ONAP CLI |
|
| ||
| 09 | CPS | cps | CPS Documentation |
|
| ||
| 10 | CPS | cps/cps-temporal | CPS Temporal |
|
| ||
| 11 | CPS | cps/ncmp-dmi-plugin | DMI-Plugin Documentation |
|
| ||
| 12 | DCAE | dcaegen2 | Data Collection Analytics and Events (DCAE) |
|
| ||
| 13 | DMAAP | dmaap/buscontroller | dmaap/buscontroller |
|
| ||
| 14 | DMAAP | dmaap/datarouter | DMaaP Data Router |
|
| ||
| 15 | DMAAP | dmaap/messagerouter/messageservice | dmaap/message router(MR) |
|
| ||
| 16 | DOC ArchSubCom | doc | Open Network Automation Platform | Architecture Updates |
|
| |
| 17 | HOLMES | holmes/engine-management | Holmes |
|
| ||
| 18 | HOLMES | holmes/rule-management | Holmes |
|
| ||
| 19 | INTEGRATION | integration | INTEGRATION |
|
| ||
| 20 | MODELING | modeling/etsicatalog | Etsicatalog Project |
|
| ||
| 21 | MODELING | modeling/modelspec | Model Specifications |
|
| ||
| 22 | MSB | msb/apigateway | MSB(Microservices Bus) |
|
| ||
| 23 | MSB | msb/discovery | MSB(Microservices Bus) |
|
| ||
| 24 | MSB | msb/java-sdk | MSB(Microservices Bus) |
|
| ||
| 25 | MSB | msb/swagger-sdk | Swagger SDK |
|
| ||
| 26 | MULTICLOUD | multicloud/framework | MultiCloud Architecture |
|
| ||
| 27 | MULTICLOUD | multicloud/k8s | MultiCloud Kubernetes Plugin |
|
| ||
| 28 | OOM | oom | OOM Documentation Repository | no PTL since 2022-04-01 |
|
| |
| 29 | OOM | oom/offline-installer | OOM offline-installer | no PTL since 2022-04-01 |
|
| |
| 30 | OOM | oom/platform/cert-service | OOM Certification Service | no PTL since 2022-04-01 |
|
| |
| 31 | OOF | optf/has | Optimization Framework: Homing and Allocation |
|
| ||
| 32 | OOF | optf/osdf | Optimization Framework: Optimization Service Design Framework (OSDF) |
|
| ||
| 33 | SECCom | osa | ONAP Security |
|
| ||
| 34 | POLICY | policy/parent | Policy Framework Architecture |
|
| ||
| 35 | SDC | sdc | SDC Documentation |
|
| ||
| 36 | SDNC | sdnc/oam | Network Controller (SDNC) |
|
| ||
| 37 | SO | so | ONAP SO | Architecture Updates |
|
| |
| 38 | UUI | usecase-ui | Usecase-UI(Use Case User Interface) |
|
| ||
| 39 | VFC | vfc/nfvo/lcm | VF-C(Virtual Function Controller) |
|
| ||
| 40 | VNFSDK | vnfsdk/model | VNFSDK Documentation |
|
|
Non-Relevant Repositories Table
| # | Project Name (common abbreviation of the project or subcommittee) Responsibility: | Repository Name (contains documentation to be published with the upcoming release) Responsibility: | ReadTheDocs Link (link pointing to RTD 'latest' main index.rst; main title used in index.rst) Responsibility: | Repository Status (new | changed | remove ; status of documentation; needed to e.g. identify changes in the intersphinx linking) Responsibility: | Documentation Owner(s) (responsible for documentation in this repo; please use @ notation for the name) Responsibility: | Documentation available: (relevant for new repos which are participating the first time)
Responsibility: | Documentation available:
Responsibility: |
|---|---|---|---|---|---|---|---|
| M2 | M2 | M2 | M2 | M2 | M4 | RC0 | |
| 01 | |||||||
| 02 | |||||||
| 03 |
Reason for the Documentation Tracking Page
We as the doc team are responsible for providing the right set of documentation specific for every ONAP release. This release-specific set of documentation always consists of a large number of text files, formatted in the restructuredText markup language and spread over a large number of repositories. The documentation files are interlinked by the doc team using intersphinx linking functionality and config files residing in the branched doc repo. The documentation is build automatically and can be found in ReadTheDocs by choosing the respective release name. Some numbers for the Guilin release may show the scale:
- 987 text files (out of 1296 in master)
- spread over 58 repositories (out of 97 in master)
- grouped in 26 projects (out of 37 in master)
Please note that we are counting only repos and projects which contain docs in the Guilin release! And also note, that the numbers do not include text files, repositories and projects for components that are added to the release by the OOM team (see below). Those must be added to the above listed numbers!
To create a release-specific set of documentation it is essential for the doc team to know, which components are part of the upcoming ONAP release. To be more concrete: We need to know which components are deployed when ONAP is installed via OOM. And we need to know this on repository level - not on project or container level because documentation files are found in the repositories for the deployed ONAP components.
As of now (November 2021) an ONAP release deployed via OOM consists of components whose underlying repositories include documentation and where the repositories ...
- are actively maintained by the project, have branched for the upcoming release and are part of it
- or actively maintained by the project, have never branched but are also part of the upcoming ONAP release
- or no longer maintained by anyone (unmaintained state), have not branched for the upcoming but for an earlier release and are part of the upcoming ONAP release for a good reason
- or no longer maintained by anyone (unmaintained state), have never branched but are part of the upcoming ONAP release for a good reason
In addition (and unfortunately) components exist where the repositories ...
- are actively maintained by the project, have branched for the upcoming release but they are not part of the upcoming release.
This makes it very difficult to identify ...
- the required components, the documentation files and their correct version for the upcoming release and
- the appropriate steps which have to be taken by the doc team to prepare the release-specific set of documentation (e.g. intersphinx linking).
But with the tables on this page and a little help from the projects and release management it will be possible to identify all relevant files and related actions. Only the first table must (partly) be maintained by the projects!
To reduce complexity and to avoid confusion and misunderstanding for the reader we decided to remove documentation for unmaintained projects/repositories.
Our target on mid- / longterm is to ged rid of manually filling out this table. Any good idea and your feedback is welcome here! Do not hesitate to contact the documentation team.
Notes for "Maintained Repositories"
In the table "Maintained Repositories" please check/update:
Project Name: Use the common abbreviation of the project or subcommittee.
Repository Name: Containing documentation to be published with the release (one per line)
ReadTheDocs Link: Link pointing to RTD 'latest' main index.rst. Main title used in index.rst.
Repository Status: Please note if the repository is new, has changed or must be removed. For new documents, at a minimum create a placeholder document (e.g., document with the correct file name and a title, or an outline), and commit to the repo. This is important for the doc team to check whether i.e. the linking works or not.
Documentation Owner(s): Please name responsible persons for documentation in this repo. Please use @ notation (e.g. David McBride for the name)