Versions Compared

Old Version 33

changes.mady.by.user Benjamin Cheung

Saved on

compared with

New Version 34

changes.mady.by.user Benjamin Cheung

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • MO

    • ARCHITECTURE SUB-COMMITTEE

      - The following are M0 activities with the Architecture Sub-committee. Release content defined.
      • #1 FUNCTIONAL ARCHITECTURE (Proposals) - The functional reference architecture is the high-level architecture overview diagram for all of ONAP. Enhancements to the functional architecture may be driven by new project proposals, updates to the diagram, and architectural changes that may be planned for the release. At M0 impacts to the functional architecture are proposed.
      • #2 COMPONENT ARCHITECTURE (Proposals) - The component architecture impacts originate from the ONAP platform components. Examples of platform components are Policy, CLAMP, SO, A&AI, CCSDK, SDN-C. Each release there may be architecture impacts from the platform components. At M0, component architecture impact proposals are submitted. Architecture reviews are setup & scheduled for component architecture impacts/proposals. Component architecture diagrams would be updated.
      • #3 REQUIREMENTS ARCHITECTURE (Proposals) - These are architecture impacts coming from the requirements and use case work in a release that may impact the functional architecture, platform architecture, or may need architectural guidance. At M0, the requirements and use cases are being proposed for the release. And an early assessment of which ones that might impact the architecture should be considered, and they made translate into requirements architecture proposals. Architecture reviews are setup & scheduled for requirements architecture impacts/proposals. The requirements Sub-Committee can evaluate and identify cross-interactions between proposals. The requirements S/C can make prioritization recommendations to the TSC. The TSC (with EUAG input) can then make a decision to adopt or alter the prioritization recommendations.
      • #4 ARCHITECTURE ENHANCEMENTS (Proposals) - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include documentation enhancements, landing page enhancements, architecture component description work, flow descriptions and process work. At M0, initial proposals are submitted to the architecture sub-committee.
      • ARCHITECTURAL "THEME" - A focus topic for the release, an architectural "theme" can also be communicated and socialized to the architecture sub-committee. For example in R7, there was a focus to shore up the API documentations.

    • WIKI LINKS References for the Use Case Teams at M0

      WIKI LINKS REFERENCE AT M0
      M0DescriptionWiki Link
      1Functional Reference ArchitectureArchitecture
      2Architecture Portal Page
      		https://safratech.net/onapdocs/
      3Release Architecture Page

      All of the architecture reviews that were conducted:


      4Requirements Proposals

      Requirements subcommittee (is merged into ARCCOM)

      Guilin release - functional requirements proposed list

      ModModeling Release Planning PageONAP R7 Modeling High Level Requirements
      U/CArchitecture Review ProcessProject Architectural Review Requirements and Process (Draft)
      U/CArchitecture Review TemplateR7 Guilin Architecture Review (template) - functional requirements
      ArchArchitecture Component DescriptionsONAP Architecture Component Description - Guilin-R7
      DocsRead the Docshttps://docs.onap.org/en/latest/


    • Modeling team - At MO the Modeling S/C does MODEL PLANNING. The planning develops into “High Level Info-model Requirements”. These High level info-model requirements fall into 3 categories:
      • #1: NEW USE CASES - items from the expected Use Cases in the release (Scope of modeling, continuing, introducing, standards updates). The Use Case Teams should engage the modeling team to propose new requirements into their release planning page.
      • #2: REFINING EXISTING MODEL - Refining Existing info-model that has not made it to the information model. Previously designs that need to be added into information model.
      • #3: FORWARD LOOKING WORK (FLW) - Modeling future forward looking requirements.
    • USE CASE TEAMS At M0, the Use Case teams are working on the following things:
      • #1: BUSINESS DRIVER TEMPLATE - The Use Case Teams are specifying their business drivers via the template: Business Driver Template for Use Cases
      • #2: REQUIREMENTS SUB-COMMITTEE - Develop their proposals for the release to the Requirements Sub-committee: Requirements subcommittee (is merged into ARCCOM) .
      • #3: REQUIREMENTS RELEASE TRACKING - Requirements put release requirements page. Example wiki: Guilin release - functional requirements proposed list
      • #4: USE CASE DEFINITIONS - Use Case team fill out the Template detailing their Use Case: Use Case Tracking Template
      • #5: INTENTION TO PARTICIPATE - Teams can indicate their corporate intention to participate
      • #6: RELEASE TRACKING - Each release has a release tracking page. The page can be found here: Release Planning
      • #7: PROJECT SUBMISSION, PROPOSAL, PLANNING - The TSC coordinates the project submission, proposal and planning. The TSC reviews and gives disposition on submitted proposals. These are tracked at the Release Planning page.
      • #8: ARCHITECTURE REVIEW - The use cases & requirements undergo Architecture Review


        REVIEW STEPDESCRIPTION
        MODELING INPUT

        The Use case teams should engage the modeling sub-committee and schedule their use case into the model planning page before architecture review. They should identify information is consumed, produced, and utilized by their use case. This should also be scheduled in the Model Planning page: ONAP R7 Modeling High Level Requirements

        CROSS DEPENDENCIES

        Use Case teams should identify cross-dependencies upon other requirement/use cases and/or ONAP components cross-dependencies impacts. For example BBS dependent on PNF registration, it is nice to know about that dependency so that the two teams know to work together. This should be identified before the architecture review if possible.

        CONTROL LOOPSIdentify potential Policies and Control Loops that might be altered or new with your requirements/use case.
        API IMPACTS

        Use Case teams should identify API impacts. The team should highlight the differences between what exists today (the old API) and the new API that they expect to update it to. This should be put in the presentation made to the architecture review.

        INTERFACE IMPACTS

        Interface (northbound and southbound) impacts should be identified

        REQ JIRAS

        The release tracking Jiras should be created. See the ONAP Use Case / Requirements Teams Process Way of Working (WoW)

        ARCH JIRA

        The Architecture Tracking Jira is created. The Architecture Chair will create the ONAPARC Jira tickets before the review. The reviews are scheduled week by week. Navigate to the Architecture Meeting Notes (weekly) ONAP Archecture Architecture Meeting Notes (New)

        ARCH REVIEWWhen the template and checklist has been completed, create a presentation to walk through at the Architecture sub-committee and schedule a review.
        REQ to ONAPARC JIRA LINKING
        1. LINK - Before a requirement may be reviewed by the arch subcommittee, the requirement must be documented in JIRA (REQ), and the REQ reference must be submitted when requesting an arch review.
        2. STEPS - After the arch review subcommittee has completed its review and made a determination, please add an issue link to the REQ issue for your review.
          1. Navigate to your requirement issue in JIRA (REQ)
          2. Select edit
          3. Scroll down until you find the "Linked Issues" field (see attachment)
          4. Make sure that the link type is "Is blocked by" (see attachment)
          5. Add the JIRA reference for your arch review (ONAPARC) to the "issue" field. (see attachment)
          6. Click the "Update" button.
          7. image2020-6-11_11-45-39.png


    • PLATFORM / PTL- High level release scope from PTLs (understand from PTL which ONAP components are expected to have updates). If a component is resolving technical debt or software development that is entirely self-contained.
    • PTL - The Use Case teams should attend the PTL planning meetings if there are expected to be requirements impacts for your use case. It is also where the Release Planning page is developed by the PTL team.

...

  • Components (PTL) Engagement - ONAP Platform Teams (A&AI, SO, SDC etc) review clean Information Model impacts for the release.
    • FEEDBACK - Component platform work can feedback to the Modeling S/C for updates to the information model during the refining the info model phase and should also provide input during the review. Modeling S/C should take into account component platform updates vis-a-vis the Use Case and modeling requirements for the release.
    • SOCIALIZATION - The socialization of the clean release information model should include updates for the PTLs. The platform PTLs must become aware that the clean release information model has gone to approval. The PTLs also attend the TSC. An email to the PTLs. Possibly a joint call with the PTLs in attendance might help to socialize the information model. Because this is a major milestone of the modeling S/C. Perhaps a modeling notification email distribution list could be made that would send major updates from the modeling S/C and that would not flood notifications from the modeling team. An email announcement of polls, in this case the baseline of a clean release information model.
    • #3 COMPONENT REVIEWS - The component reviews are trying to baseline the understand of the component in the release. Each of the project or project teams should give a presentation at the architecture sub-committee. 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. For example, the R7 Component Wiki Page is at: ONAP Architecture Component Description - Guilin-R7

    • Use this checklist to prepare for your Platform Component review:

      Checklist ItemDescription

      Check Update Attachments Info

      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.

      All the associated files for the page are stored in the attachment folder. Click on the "..." in the upper right of the page

      The on the page change the component name. Hit the "EDIT" and change the component name to the "Component name - R#", where R# is the release number.

      Cross check the name with the tag.

      Use Draw.io

      draw.io is the tool currently used to draw all the diagrams

      When you edit the diagram it will open the Draw.io interface which looks like this:

      Check Attachments Folder and Drawio Diagrams

      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. Remove unneeded png files (you can click on the png file and see if it is still relevant for the release, if it is not delete it otherwise we will be carrying this diagram as unnecessary overhead). If the "DELETE" option does not show up contact, the Architecture PTL/Chair to get assistance as they may own the older files.
      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. You may add, modify or delete any API as needed but please maintain the same look and feel and the diagram file naming convention.

      7. COLOR CODE CONVENTION. Use a Blue Lollipop to represent a Consumed API, a Beige Lollipop to represent an offered API and add a Legend to your Draw.io diagram showing these.

        COLORMEANING
        Status
        colourYellow
        titleRED
        		Offered API
        Status
        colourBlue
        titleBLUE
        		Consumed API
        Legend


      API Documentation

      The page should document the consumed or offered API, and to provide as much detail and clarity on the what and the how of each API. With that in mind iI'd like to propose the following as a starting point for preparing for these reviews:

      PTLs /Representatives will be responsible for making all the changes to their respective component diagrams

      PTLs would certify and approve all the changes to their respective component diagram

      Each API listed on the component diagram (lollipop and Label) should:

      be fully documented in the corresponding table, included in component wiki page above,

      1. each API label should have a link to their respective swagger.xxx, REST, YANG, wiki page, etc...
      Component Description Updates

      Each of the PTLs for a component need to update the general descriptions of their component on their respective component page.

      Generally this will not change much with each release, but updates reflecting the changes in that release should be described.


  • The M-drop Summary

    Drop

    Functional

    Architecture

    Component

    Architecture

    Requirements

    Architecture

    Architecture

    Enhancements

    Info

    Model

    Test

    Cases

    M0

    FA - Proposal

    Architecture Team

    CA - Proposal

    from PTLs

    FcA - Proposal

    Dev U/C teams

    AE - Proposals

    Architecture Team



    M1FA - ReviewCA - RequirementsFcA - RequirementsAE - Requirements

    M2
    		CA - ReviewFcA - ReviewAE - Review

    M3FA - BaselineCA - BaselineFcA - BaselineAE - Baseline

    Sync


    M4




    		Sync


  • M3 API Freeze

    • ARCHITECTURE SUBCOMMITTEE M3 -
      • #1 FUNCTIONAL ARCHITECTURE (Architecture Base-lined) - The functional reference architecture is the high-level architecture overview diagram for all of ONAP. This should be base-lined by M3. Enhancements to the functional architecture may be driven by new project proposals, updates to the diagram, and architectural changes that may be planned for the release. At M0 impacts to the functional architecture are proposed.
      • #2 COMPONENT ARCHITECTURE (Architecture Base-lined) - The component architecture impacts originate from the ONAP platform components. Examples of platform components are SO, A&AI, CCSDK, SDN-C. This should be base-lined by M3. All of the details of your APIs, JSON objects should be defined and base-lined and ready. Each release there may be architecture impacts from the platform components. Once the API/code freeze at M3 the PTLs should know if there have been recent changes that need to be reflected in the Architecture documentation. The Architecture chair could sync and confirm if that they reviewed in the Architecture S/C for M2 is still valid at M3.
      • #3 REQUIREMENTS ARCHITECTURE FROM USE CASES (Architecture Base-lined) - These are architecture impacts coming from the requirements and use case work in a release that may impact the functional architecture, platform architecture, or may need architectural guidance. At M3, these requirements coming from use cases should be base-lined. My M3, the architecture should be documented, and finalized. If the Arch S/C has all the resources available, another quick review should be held to assess if anything new has changed since the review. A quick sync or update should be given to the Architecture Sub-committee.
      • #4 ARCHITECTURE ENHANCEMENTS (Architecture Base-lined) - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include documentation enhancements, the architecture portal landing page enhancements, architecture component description work, flow descriptions and process work. At M3, these may continue to be worked by the architecture sub-committee and continue to be discussed.
    • Use Case Engagement -
      • API Freeze - The Use Case Teams at this point have base-lined their APIs and their Data Models. Component data model schemas. Who maintains them should be identified, and these should be presented at the Architecture sub-committee.
    • M3 MODELING SUBCOMMITTEE ACTIVITIES-
      • REFINEMENTS TO THE RELEASE INFO MODEL - The Release Information Model is clean at M3. It is considered "base-lined" and "final", hence it is marked clean. Though, updates can still happen to the release information model and the model contributions therein.
      • INFO MODEL OBJECTIVES - What do they mean to intend and convey by the information model and the changes for the release what are the key objectives. And how does the information model relate to the data model.
      • SYNC - Work underway still by the modeling sub-committee, such as refinements to the release information model, items still in progress, future work, and work documented after implement should be communicated to the architecture sub-committee in a sync-up before M3. The modeling sub-committee lead should reach out to the Architecture PTL either for a quick sync, a separate 1-off presentations, or reserved slots on either of the two regular weekly team calls.
    • Components (PTL) Engagement -
      • PTL READOUT - The PTL should reaffirm for their component, their architecture proposals that were made at M2, to make sure there have not been significant deviations from their original proposal. And if there have been updates to report back to the Architecture Sub-committee on the deltas.

...

  • M4 Code Freeze

    • ARCHITECTURE SUBCOMMITTEE M4 -
      • #A TEST CASES (Architecture) - At M4, unit testing is done where APIs and interfaces are tested. A checkpoint what was discussed at M2 and M3. The APIs could be tests based on the designs that were tested. For example, the NBAPI may implement some actions. These actions might be CRUD operations. The team could report that some part of it was tested and some needs to be pushed to the next release.
      • #B PTL UPDATES (Architecture) - PTLs are managing S/W deliveries at Code Freeze, and testing is occurring. Feedback from the integration team. Unit testing needs to happen within the component. The pair-wise testing exposes tests the interfaces between components, reviewed at the component reviews.
      • #C COMPONENT DIAGRAM UPDATES (Architecture) - If swagger JSON files needed to be made, the links to the swagger files should be updated from their component reviews.
      • #D NEXT RELEASE ARCHITECTURE FOCUS - Discussions are happening around what the focus of the Architecture efforts for the next release are happening. For example at the end of R7 the Architecture sub-committee was discussing aligning the Platform component wiki pages, and also the next steps for the Architecture flow diagrams that were started in R4.
      • #E DOCUMENTING THE ARCHITECTURE - Documenting the architecture is an ongoing effort. Each release will open discussions about how to best document the Architecture. It helps to have a focus on a particular topic per release to make the work more manageable. Read the Docs should be updated and reviewed. Architecture Read the Docs, and APIs should be up to date by end of M4. And the ONAP Architecture overview in the read the docs should be updated.
      • #4 ARCHITECTURE ENHANCEMENTS (Architecture Base-lined) - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include architecture portal landing page enhancements, architecture component description work, and process work. Because the teams are fully engaged trying to meeting delivery deadlines, the Architecture enhancements are fully self-contained activities within the Architecture sub-committee they can continue to evolve during M3, M4 and RCx. For example, suggestions for common templates can be discussed in this time frame. This also sets the stage for making the focus of the next release more coherent.
    • Use Case Engagement -
      • API - Use case teams that are impacting the APIs and thus the component swagger should also report on changes to the component pages.
    • Components (PTL) Engagement -
      • API & Component Descriptions - Updates to swagger/JSON files should be reflected in the component pages.

...