...

ONAP Components Architecture Reviews Guidelines (work in progress - draft jul-09-2020)

The focus of the component reviews is to ensure that the documentations provided in these wiki pages are consistent with what the state of each ONAP component for a specific release.

The component documentations/diagrams listed below have been scrubbed and cleaned up to the extent possible.. the following is a list of guidelines to help  you prepare for your component review:

1. The "Attachment" folder associated with each Component (... in upper right corner) has also been cleaned up and all draft copies of the diagrams have been deleted.
2. draw.io is the tool currently used to draw all the diagrams
3. Each component diagram file has the following properties:
   1. componentName_r7 (i.e. sdnc_r7 for the SDN Controller)
   2. The .png file associated with your component gets generated by draw.io
   3. there There may be other files/images left in the Attachment folder. feel free to modify/delete any file(s) to reflect the changes  associated with the release
   4. the The draw.io diagrams (i.e. lollipop diagram) is based on the C4 Model for visualizing Software Architecture?? - Please maintain the same format as you make any changes to your respective component
   5. each Each diagram has a release stamp (bottom right corner) that should not be modified
   6. Each API (consumed or offered) is depicted by a lollipop and a label;y you may add, modify or delete any API' as needed but please maintain the same look and feel and the diagram file naming convention

The emphasis for the upcoming reviews will  be on documenting the component components APIs,  whether consumed or offered, and to provide as much detail and clarity on the what and the how of each API. with With that in mind i'd like to propose the following as a starting point for preparing for these reviews:

1. PTLs /Representatives will be responsible for making all the changes to their respective component diagrams
2. PTLs would certify and approve all the changes to their respective component diagram
3. Each API listed on the component diagram (lollipop and Label) should:
   1. be fully documented in the corresponding table, included in component wiki page above,
   2. each API label should have a have a link to their respective swagger.xxx, REST, YANG, wiki page, etc...
   3. PTLs own the diagrams
   4. Please update the diagram draw.io file to reflect all the changes to your respective components for the Guilin releaseAll the API's should be labeled and also reference the corresponding swagger.jsonOnce all the updates are made please update date the timestamp and the owner.

ONAP component descriptions for the Guilin-R7 Release

...