This is a working wiki to capture the ONAP architecture component descriptions

1 - ONAP Components Architecture Reviews Guidelines (work in progress - (last updated 24-Aug-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 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 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 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 components APIs,  whether consumed or offered, and to provide as much detail and clarity on the what and the how of each API. 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 link to their respective swagger.xxx, REST, YANG, wiki page, etc...

   3. the Initial status for each component with be set to " Conditional Approval" as a default status. The Status will be change after the architecture review session has been completed based on the ArchCom final decision

2- ONAP component descriptions for the Honolulu-R8 Release