Versions Compared

Old Version 25

changes.mady.by.user Benjamin Cheung

Saved on

compared with

New Version 26

changes.mady.by.user Benjamin Cheung

Saved on

Key

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

...

  • 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

      Image Modified

      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.

      Image Modified

      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:

      Image Modified

      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
        Image Modified


      Image Modified

      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 i'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...

M2 CHECKPOINTS & COLLABORATION




  • 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

    • 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

    M3

  • Use Case Engagement -
    • API Freeze - M3 is characterized by the API freeze. The main thing that happens at M3, the API is frozen by the Use Case Teams.
    • Data Model Freeze - Developers identify a problem in the data model which affects the information model.
      • SYNC UP - since the Modeling S/C is familiar with the info-model; the Use Case Teams should present at the Modeling S/C their proposed data model that might be frozen so that the modeling S/C can assess it to see if might have impact to the Info-model. There should be some collaboration or check-point at M3 to discuss and potential ripple affects back to the information model.
      • DATA MODEL IMPACTING INFO MODEL - If changes in the Data Model impact the information model, those changes need to be worked by the model S/C. The Modeling S/C would evaluate the change to the Information model and possibly make updates.
      • USE CASE TEAMS INDICATE CHANGE - The Use Case teams may have enough knowledge of the info-model that they identify a data model change that may impact the information model. This presumes that the use case teams know that their changes in a data model may have impact to the information model.B
      • CONSIDER DATA MODEL - START: Input Data Model > verb Consider > END: Data Model in Discussion State
        • The data model is a model that is used in a Use Case and is based on the Information Model. It is generally a self-contained model which depicts a particular capability or function of the system. The data model starts as a "input data model" and undergoes consideration by the Use Case teams. Consideration means that the Use Case teams is entertains & assesses if the input data model. If the Use Case teams think that the contribution is not ready for the current release that contribution it might postponed. It would be noted in the Release Management Project page as such.
      • REVIEW & REFINE CONTRIBUTION - START: Data Model in Discussion State > verb Reviewing & Refine > END: Data Model in Discussion state
        • The data model undergoes reviewing & refining during the discussion state. Reviewing & refining means that the Use Case Teams are discussing the data model and updating their data model based on feedback and comments from the Use Case team and modeling team. Each data model can be reviewed and refined independently and concurrently with other use case projects. Things in the discussion state are classes, attributes and relationships are tagged as IISOMI experimental.
      • MODELING S/C ENGAGEMENT - The Use Case teams may wish to solicit the opinion of the modeling S/C and present their data model for discussion and socialization.
      • FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Data Model in Discussion State > verb Approving/Poll > END: Data Model in Discussion state
        • (a) FINAL PRESENTATION - When the data model has gotten to a point where the use case team feels that it can start to undergo the approval process, the data model is brought one final time the use case team.
        • (b) FINAL CALL FOR COMMENTS - After that, a final call for comments is issued by a use case lead to the modeling team whereby final thoughts & input can be given. This final call for comments signals that the discussion is wrapping up for this contribution and will soon go to a poll.
        • (c) INITIATING POLL - After final call and no further outstanding comments exist, the contribution is brought to a poll by a use case lead. A poll is created whereby use case team members can give the contribution a vote of "yes" or "no". 
      • APPROVING CONTRIBUTION - START: Data model is in Discussion State Post-Poll > verb Approving > Data model in Clean State
        • After the poll has concluded, the data model has finished the approval process. The data model is now considered to be in the clean state. The items that are in the IISOMI experimental state get promoted to a preliminary state. A gendoc is generated and put on the wiki page. The gendoc would be translated and published on the readthedocs site.  #@# do data models also use ISOMII states?
    • Component Data Model Final - x.
    • RECONCILE - Reconciling the info-model with the data-model. M3 checklist. (API Freeze)
    • M3 CHECKLIST - The M3 check list is used. This is a vehicle to engage the Use Case (project teams) and reconcile the Use Case Teams with the modeling S/C team's work. The Check list can be found here: Proposed M3 Checklist modeling updates discussion
    • 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. This means that certain elements within the model(s) could go to back to an experimental state. Note that only certain elements (e.g. attributes, ranges) are likely to go to the experimental state NOT the entire contribution. More often though, new additions could be added to a contribution model. In general, there would likely be just minor tweaks on the model. So when a contribution is clean it has to be at least preliminary. A contribution cannot be clean and experimental. Clean has a relationship to the IISOMI states. For an entity to be clean it must be either preliminary or mature (see the IISOMI state diagram link).
    • IISOMI STATES - A link to the IISOMI state diagram can be found here: Stereotypes 
    • NEW ADDITIONS - A contribution model could be clean, but things added afterwards and those elements would come in as experimental. 
  • STILL IN PROGRESS ITEMS IN RELEASE INFO MODEL - It is possible that as the modeling team enters the M3 milestone that there are still some things in progress, that are expected to be in the current release. They might still be marked experimental even though the release information model is clean. Thus, to open item are continue to be work; and it is expected it would not affect software if code were already associated to it.
    • ITEMS IN DISCUSSION - e.g. when root contribution was done, with root party is an example as it was not agreed to, we made the decision to leave that experimental until a future date. There were aspects agreed, and other things left experimental to pursue in the future. The main contribution was split. These parts everyone agreed with and these part left experimental which would be taken up in a future contribution and re-discussed. This would likely occur at M2, and they might be discussed at M3. There was a conscious decision and agreement by the modeling team that the parts of the model still open would be pushed to the next release. So only theoretical discussion would happen at this point of how to proceed in the future release.
    • FUTURE WORK - Things originally planned to be in a release could potentially transform into future work items. Some modeling work could be pushed to the next release if need be, if it is decided that it could not be completed in the current release.
    • FUTURE WORK- Future work is typically identified as such at the start of a release at M0 in the release modeling planning page. Future Work can still proceed. For example, in R6 the geo-location modeling work is not tied to any active development yet. The location work is a good example of work that was worked in ADVANCE of when it is expected to be used (Future Work). It is also possible that some of the future work is building upon a foundation of work that had already been started (or was looked at) or implemented in a prior release.
    • DEFER WORK - It might be decided the the future work could be deferred to the next release. On the current modeling high level requirements page to indicate that a particular future work has been deferred to a future release. In order not to lose the activity, it would be expected that it would be rolled into the next release's Modeling High-Level Requirements.
    • CONTINUE WORK - Future Model work may continue to proceed in the current release..
    DOCUMENTATION AFTER IMPLEMENTATION IN PRIOR RELEASE WORK- This type of work is the model is catching up to already implemented software. It has already been identified as something that would be worked on for that release at M0. It is expected that it wouldn't immediately impact the current software. However, it may be extended eventually to incorporate new work. The way to proceed with this category of work is handled the same way as the future work (i.e. Defer or to Continue the work) given modeling improvement recommendations on how better to model a given concept.
  • M3 CHECKLIST - The M3 check list modeling updates discussion is used by the modeling sub-committee. It is used as a vehicle to engage the Use Case (project teams) and reconcile the Use Case Teams with the modeling S/C team's work. See also the Use Case Team Engagement (section below). The Check list can be found here: Proposed M3 Checklist modeling updates discussion
  • Architecture Engagement -
    • S-P - B-
  • Components (PTL) Engagement -

    • M4

  • Code Freeze

    • Kickoff Information Model Requirements for Next Release

    • READ THE DOCS - (M3 or M4?) The model editor provides a final gendoc word document which serves as the basis for what will be incorporated into the readthedocs. The read the docs can be found here: https://onap.readthedocs.io/en/latest/index.html . The word document is fed into some tools which generates the readthedocs output. The gerrit master model is periodically updated, and a snapshot of the eclipse/papryus model is taken and that is called the release model.
    • DOCUMENT GENERATION - The RST documentation that only contains things in the current release or everything that is approved.
    • PAPYRUS GENERATION - The Papyrus snapshot is generated. The RST document is created. The readthedocs documentation is generated.
    • Note that the papyrus model includes what was/had accepted into the previous release and also anything that is still a work in progress.
    • Architecture Engagement -
      • S-P - B-
    • Use Case Engagement -
      • D-T - D-p.
    • Components (PTL) Engagement -

  • RCx

    • Runtime Compliance

  • Observations

    • Establishes and Evolves a Common Model

    • Project (Component) Team Involvement in Modeling Solution

    • Governance of Common Model and Corresponding Component Models

    • Update possible in M3 and M4 (bug fixes) per exception process

...