...
M4 (Code Freeze)
- M4 MODELING SUBCOMMITTEE ACTIVITIES-
- PLATFORM INFORMATION UPDATES FROM SWAGGER UPDATES - The modeling subcommittee would update the platform information model possibly due to updates in the ONAP platform swagger files. It is anticipated that no new API changes would occur at M4, but rather description updates which would then subsequently affect the corresponding platform information model.
- DOCUMENT GENERATION- The model editor provides a final gendoc word document which serves as the basis for what will be incorporated into the readthedocsReadthedocs. The word document is fed into tools which generate the readthedocs output (RST file). The tool to generate the readthedocs Readthedocs is pandoc. This is done by the model area lead. The gerrit master model is periodically updated, and a snapshot of the eclipse/papryus Papryus model is taken and that is called the release model. A link to the read the docs can be found here: x. A tutorial for the process can be found here: RST Document Generation Tutorial After each approval, the model editor will update the latest gendoc. The Papyrus snapshot 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.
- NEXT RELEASE - The M0 for the next release is generally synchronized with the sign-off of the previous release. So, the modeling sub-committee is assessing new model requirements for new requirements or use cases in the next release during this time. See above for the M0 process related to model proposals process.
- Architecture Engagement -
- S-P - B-
- Use Case Engagement -
- Code Freeze - Possible updates to Swagger files, additional updates. For example descriptions, licensing information without impact to API.
- Platform Components (PTL) Engagement -
- Code Freeze - Possible updates to Swagger files, additional updates. For example descriptions, licensing information without impact to API.
- M4 MODELING SUBCOMMITTEE ACTIVITIES-
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
Artifacts
...
- Next Release Architecture Reviews - M0 activities; go through the modeling check points in the Architecture review of the Requirements & Use Case proposals to the Architecture Sub-committee. Identifying and looking and their M0 model and their high-level information flows that the API might be consuming or producing; and then mapping those to existing information models. If there is a gap new modeling requirements would need to be identified and also planned into the model release planning page.
- Requirements & Use Case Engagement -
- Next Release Requirements & Architecture Reviews - The teams working on requirements & Use Cases should include modeling check points in their presentations & proposals to the requirements sub-committee and architecture sub-committee. Identifying and looking and their M0 model and their high-level information flows that the API might be consuming or producing; and then mapping those to existing information models. If there is a gap new modeling requirements would need to be identified and also planned into the model release planning page.
- Platform Components (PTL) Engagement -
- Component API changes - If there are API changes originating from the platform development that would impact the release information model, the modeling sub-committee should sync with the PTLs.
RC0/RC1/RC2 (Run Time Compliance)
RC0/1/2 MODELING SUBCOMMITTEE ACTIVITIES-
- NEXT RELEASE - During RC0/RC1/RC2 for the next release is generally synchronized with the sign-off of the previous release. So, the modeling sub-committee is assessing new model requirements for new requirements or use cases in the next release during this time. See above for the M0 process related to model proposals process.
- Architecture Engagement -
- Next Release Architecture Reviews - see above the M0 step for details on syncing.
- Requirements & Use Case Engagement -
- Next Release Requirements & Architecture Reviews - see above the M0 step for details on syncing.
- Platform Components (PTL) Engagement -
- Next Release PTL engagement - see above the M0 step for details on syncing.
ARTIFACTS
The artifacts listed here, summarizes artifacts that are relevant to the modeling sub-committee
| TOPIC | DESCRIPTION | EXAMPLE WIKI |
|---|---|---|
| Information Model | See above the Mx descriptions for a more detailed discussion of the development and review of the information model. The information model that contains the following:
|
...
|
...
Feed to Data Dictionary
Tooling - The tooling for the Information model includes Papyrus in Gerrit/GitHub repository Note: There might be exception cases, where attributes that is not shared in an API or by the development team may not necessarily need to be modeled. |
...
| Component Data Model |
...
Component Data Model
See above the Mx descriptions for a more detailed discussion of the development and review of the component data model. For example, the data model could be expressed in Yang, Tosca, and Swagger. Usually, the data model would be expressed in the API. while they may, ONAP does not force that to happen. The component data model contains the following:
|
...
|
...
Feed to Data Dictionary?
Note: the mapping of the API/Data model to the information model may be Automatic or manual. It is expects that the development teams would provide translation/mapping to the modeling team. This would be used by the modeling sub-committee as a sanity check, but the information is "owned" by the development teams. |
API Artifacts
...
API Model
...
New Roles – Model Governance
...