Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

ONAP Current Architecture Documentation

Description

2019-011-05

Andrea provided feedback on how we have documented the ONAP architecture in read-the-docs. https://wiki.onap.org/download/attachments/8225716/ONAP_architecture_document_suggestions_Andrea_Visnyei.pptx?api=v2

  • important information is hidden inside the more marketing text

  • Restructure is required.

  • could also reflect that security and deployment could be considered.

  • At the moment its part of the developer guide, should it be located in another place.  The users and the developers mayhave different needs when it comes to documentation.

  • Avoid release dependant text - put that in the release notes.

  • agree to copy to the wiki, andrea can provide initial comments; then we seek volunteers.

 

 

2019-02-05 - notes from ONAP Arch weekly meeting (CJ)

  • Few comments received. Updated documents provided by Ting for further offline comments in the wiki

  • The discussion veered towards what the target ONAP architecture should be vs what ii is today

  • The AT&T team wants to make sure that the ONAP documentation take into account the ONAP architecture principles

  • Documentation of architecture principles

    • Is it likely in an open source community to expect alignment with all requirements – e.g. how to measure microservices compliance?

    • Purpose of documentation is to enable ease of onboarding of new users / developers

  • “Black-box” picture (Ciaran's picture):

    • Considered “old-school” integration architecture picture – needs to be described in terms of capabilities not implementations

    • Are we documenting the current “tight coupling” or the wanted loose coupling and service based, or both? How do we provide a “wanted approach” for new projects?

  • Comments to be provided on updated slidepack uploaded to the wiki

01-05-2019 update - CAH

 

2019-01-29 Arc Dublin F2F

Will follow-up on the next Seccom next week to allow time for people to provide considered input.

 

 

2018-10-31 Arc Dublin F2F:

(From https://wiki.onap.org/download/attachments/50202249/Documenting%20the%20ONAP%20Architecture.pptx?api=v2)

we need better documentation for architecture.
2 way split  inward doco that we produce for ourselves and outward facing for everyone else
Document the real Architecture
Multiple Views ( one diagram cannot cover it!)
Functional Architecture = Business Capabilities
Platform Architecture = Outer and Inner Architectures = High Level MSA
Inner :  ONAP Services -  The Microservices that Deliver ONAP Functionality
Outer : ONAP Microservices Platform  - The Platform that Supports the ONAP Services

 Need to come back with the archecture blueprint and way to document it before running off.

Activity

Show:

Former user February 8, 2019 at 11:08 AM

Hi,

Sorry, I haven't been able to join the meetings so I hope it's OK if I add my suggestions here; they're mostly about the document structure. I made some assumptions where my technical understanding failed, so I might have got some things wrong. So, my suggestions are the following:

 

  • First of all, I think we should take more of a functional description approach, so follow the logic of actual use cases/functionalities, and not just list components. Actually, something like the 3 bulletpoints in the intro part could work, so: design framework, orchestration and control framework, analytic framework

  • Closed loop automation should be higher, since I think that's the main selling point (? I might be wrong here) & all supporting functions/components after that, maybe referring back to the main chapter where it's relevant

  • 'design principles' part/list should have its own subchapter

  •  changes between releases also should have their own subchapter (or better yet, move them to the release notes)

  • Structure:

    • Introduction

    • Closed control loop automation

      • Design framework (ONAP Modeling chapter/description should be moved here)

      • Runtime framework

    • Architecture (with streamlined content; also, maybe microservices support+portal+Common services chapter content can be moved here and somehow worked into one coherent chapter?)

    • Blueprints can be streamlined, also; maybe keep one but describe it in a bit more detail?

  • Conclusion chapter should be removed

  • Resources chapter should either be removed or extended with actual useful links

  • There's a References chapter in the TOC tree that's not in the main doc->maybe a link to it could be added?

  • inline links to component documentation when the components are mentioned would be nice; same with models&blueprints

  • Finally, the whole Architecture doc should be moved higher in the structure, to the same level as the Developer Guide

 

That's all I've got so far; I think the content within the chapters should be rewritten also, because it's kind of a mess, but for that, we have to first identify the scope and also some kind of 'narrative logic', as it were, which can be followed in the whole document, to make it more coherent and user friendly. 

Also, I'd be happy to do all of the above updates if you agree with them, of course.

Regards,

Andi

Unresolved

Details

Assignee

Reporter

Labels

Priority

Created October 26, 2018 at 6:38 PM
Updated March 9, 2020 at 12:33 PM
Resolved October 26, 2018 at 6:38 PM