Short Explanation
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).
Unmaintained Repositories
- Existing repositories containing documents,
- which are belonging to an active project, but not used in the ONAP documentation
- which are belonging to an unmaintained project, but used in the ONAP documentation
- Table handled mainly by DOC, but PROJECTS are asked to check if status of repository has changed.
- A request to the PROJECTS: Please check the table "Unmaintained Repositories" and move entry to the upper table, if the repository is once again maintained in the target release!
Maintained Repositories Table
Unmaintained Repositories Table
Project Name (common abbreviation of the project or subcommittee) DOC | Project Lifecycle State (Source?) DOC | Repository Name (may contain documentation to be published with the upcoming release) DOC | ReadTheDocs Link (pointing to RTD latest) DOC | Docs In This Repo Are Part Of The Upcoming Release DOC | Name of Branch Used In The Upcoming Release DOC | Name of Latest Available Branch DOC |
|---|---|---|---|---|---|---|
| AAF | Unmaintained | aaf/authz | AAF Architecture, APIs and Guides | yes | Master | Frankfurt |
| AAF | Unmaintained | aaf/certservice | no | Frankfurt | ||
| AAF | Unmaintained | aaf/sms | no | Frankfurt | ||
| AAI | Unmaintained | aai/esr-gui | External System Registry GUI Documentation | yes | Master | Frankfurt |
| AAI | Unmaintained | aai/esr-server | External System Registry Server Documentation | yes | Master | Frankfurt |
| AAI | Mature | aai/event-client | no | Honolulu | ||
| APPC | Unmaintained | appc | APPC Architecture, APIs and Guides | yes | Frankfurt | Frankfurt |
| APPC | Unmaintained | appc/deployment | APPC Deployment Documentation | yes | Frankfurt | Frankfurt |
| CCSDK | Mature | ccsdk/apps | no | Honolulu | ||
| CCSDK | Mature | ccsdk/dashboard | no | Honolulu | ||
| CCSDK | Mature | ccsdk/platform/blueprints | no | Master | ||
| CCSDK | Mature | ccsdk/platform/nbapi | no | Amsterdam | ||
| CCSDK | Mature | ccsdk/platform/plugins | no | Elalto | ||
| INTEGRATION | Incubation | integration/benchmark | no | Casablanca | ||
| INTEGRATION | Incubation | integration/devtool | no | Casablanca | ||
| INTEGRATION | Incubation | integration/simulators/pnf-simulator | no | Frankfurt | ||
| LOGGING | Unmaintained | logging-analytics | ONAP Centralized Logging Documentation | yes | Master | Elalto |
| LOGGING | Unmaintained | logging-analytics/pomba/pomba-audit-common | no | Elalto | ||
| MODELING | Mature | modeling/toscaparsers | no | Elalto | ||
| MSB | Incubation | msb/discovery | no | Honolulu | ||
| MSB | Incubation | msb/java-sdk | no | |||
| MSB | Incubation | msb/swagger-sdk | no | |||
| MULTICLOUD | Mature | multicloud/azure | no | |||
| MULTICLOUD | Mature | multicloud/k8s | no | |||
| MUSIC | Unmaintained | music | MUSIC Architecture and Guides | yes | Frankfurt | Frankfurt |
| MUSIC | Unmaintained | music/distributed-kv-store | MUSIC Distribute KV Store Documents | yes | Master | Beijing |
| oparent | ? | oparent/cia | no | |||
| POLICY | Mature | policy/engine | no | |||
| PORTAL | Unmaintained | portal | ONAP Portal Platform Documentation | yes | Guilin | Guilin |
| SDC | Mature | sdc/sdc-distribution-client | no | |||
| SDC | Mature | sdc/sdc-docker-base | no | |||
| SDC | Mature | sdc/sdc-tosca | no | |||
| SDC | Mature | sdc/sdc-workflow-designer | no | |||
| SO | Mature | so/ | SO Architecture documentation | no | ||
| INTEGRATION | Incubation | testsuite/pythonsdk-tests | no | |||
| VFC | Mature | vfc/nfvo/driver/vnfm/svnfm | no |
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 (April 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!
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: Pointing to RTD 'latest'!
Repository Status: Please note if the repository is new, was maintained 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)
A request to the PROJECTS: Please check the table "Unmaintained Repositories" and move entry to the upper table, if the repository is once again maintained in the target release!