...
Key Contacts - Andy Mayer Eric Debeau
Also see: Developing ONAP API Documentation
Executive Summary - Improve ONAP API Documentation:
Developer Friendly
Non-Developer Friendly
Easy to Find & Easy to Navigate
Common and Uniform Documentation Structure and Approach
Provides Information on Using the API (e.g., quick start)
Try It For Yourself (TIFY) Examples
Proposed non-functional requirements for Guilin release:
All components should place externally facing (i.e. interfaces exposed by the ONAP component to either other ONAP components or components external to ONAP) API definitions (e.g. Swagger) in a common path within their Gerrit/Git
Suggested Path: <Component>/docs/api/swagger/
Apply ReDoc to Swagger and place HTML in Readthedocs for the release
Apply Minimum (Phase 1+) swagger guidelines
Use the common insert for the info section (e.g., license info, contact info, etc): Swagger Insert Sample for Info Section
Related JIRAs under the Documentation project for the API Documentation non-functional requirements:
...
Executive Summary - Integration testing shall continue to test for unsecure communication (HTTP) and vulnerable ports (e.g., JDWP). Integration shall add tests to ensure that project containers use the versions of Java, Python, Linux, Docker, database and utilities specified in Guilin versions.
Business Impact - Improves the security posture of ONAP by using current versions and simplifies the deployment.
...