TM Forum Community

 View Only
  • 1.  Deploying a system of ODA components

    TM Forum Member
    Posted 18 days ago

    I see that work is progressing on how an ODA component can be deployed. I see relatively little work on how to specify a system which comprises multiple interlinked ODA components. For example, a such a system is shown in https://projects.tmforum.org/wiki/display/TAC/Components+Interactions+in+Core+Commerce+Management

    One approach may be to use the work on intent based automation Another approach is to use TOSCA which I belive would be possible. I have published my work to date on this investigation at

    https://github.com/oasis-open/tosca-community-contributions/tree/master/examples/1.3/TMForum_oda


    #OpenDigitalArchitecture

    ------------------------------
    Paul Jordan
    Paul Jordan
    ------------------------------


  • 2.  RE: Deploying a system of ODA components

    TM Forum Member
    Posted 17 days ago
    Hi Paul Interesting and Timely observation.
    As you will be aware you did crate a document on this topic
    IG1176 TOSCA Guide for Model-Driven Automation v4.1.0 | TM Forum
    The Current focus in the Component team has been deploying individual Components using k8S Operator and a custom 'ODA Operator' Using Helm/CRD definitions. The later does 'wired up deployed components to other running components
    As Part of the Autonomous Network project engagement with other SDO (AN MSDO Initiative are running a series of presentation between SDO .
    As part of this series ONAP presented and demonstrated last Monday their work on Automation Compositions Management (ACM) which is Tosca based approach to deploy configurations of multiple (ODA) Components together with Policy rules. This shows practically how TOSCA can be used in conjunction with k8s and legacy implementations.
    The presentations and meeting recording are at:
    2023-01-09 AN-SDO ONAP TOSCA Demonstration - AN-SDO Collaboration - TM Forum Confluence 
    ( his is on a members page but i think you should have access)
    and the demo video is on ONAP at
       https://wiki.onap.org/display/DW/CLAMP+ACM+demo+for+Kohn+Release
    This stimulated quite  bit of discussion between the ONAP and AN teams and the AN team did discuss this work on its Technical Architecture team Tuesday 10th Jan as there is a requirement in AN Autonomous Domains  to be able to orchestrate current OSS BSS implementation behind an Intent handler. I do exect this to be discussed further in tat team

    @KevinMcDonnell  @Joerg Niemoller    ​

    ------------------------------
    Dave Milham
    TM Forum, Chief Architect
    ------------------------------



  • 3.  RE: Deploying a system of ODA components

    TM Forum Member
    Posted 16 days ago
    Hi Dave, Paul

    Interesting point raised, thanks.

    In terms of schema development the structures supported by Openapi do provide for multi schema references i.e. through the $ref keyword.  Does Tosca provide additional capability in describing topological structures in a noSql form , and in relation to supporting network  ( resource ) specific API's?  It would seem that definining a topological structure in JSON / YAML is adequate for purpose?  The cloud specific aspects can be handled in a similar way.  Its mainly a question of modelling, rather than language selection -  or.

    Best regards

    Peter Skoularikos



    ------------------------------
    [Peter] [Skoularikos]
    [Telekinetics]
    peters@telekinetics.eu
    ------------------------------



  • 4.  RE: Deploying a system of ODA components

    Posted 12 days ago
    As Paul's work tries to demonstrate, TOSCA offers a lot more than just another encoding for system and application models. TOSCA is not just a modeling language, but rather a language for model-driven lifecycle management. Of course TOSCA has a modeling component--since all orchestration actions are based on the models--but the key differentiator of TOSCA as compared to other technologies is that orchestration and lifecycle semantics are built into the TOSCA language as opposed to being embedded in the orchestrator logic.  This is what enables portability, re-use, and simple domain-independent orchestrators.

    Here are some of the key features of TOSCA that enable model-driven lifecycle management:
    • TOSCA models systems and applications as graphs where the dependencies between system components ("relationships") are first-class entities in the language. Encoding these dependencies enables rich automation features (e.g. automatic workflow generation)
    • Relationships are established between a requirement of one component and a capability of another component, rather than between components directly. This allows requirements to be "dangling" so they can be fulfilled at deployment time by an orchestrator. This enables modularity and deployment-specific system composition.
    • TOSCA has built-in support for decomposition (using the substitution mapping feature). This enables abstract system design where abstract components are decomposed into technology-specific subsystems, that in turn can be decomposed again (e.g. into vendor-specific implementations). This builds on John Strassner's "policy continuum" ideas.
    • The recursive decomposition of abstract models can be the basis for a real intent system where intent is expressed as policies at the business level associated with the abstract models. These  policies can then be mapped (recursively) into lower-level policies associated with the lower-level ("decomposed") models, until they ultimately "hit the metal" so the speak.
    Unfortunately, neither ONAP nor ETSI take full advantage of these TOSCA features. It is my opinion that if they did, their overall system architecture would be significantly less complex than it is currently.

    Chris Lauwers
    Co-Chair, OASIS TOSCA TC
    lauwers@ubicity.com

    ------------------------------
    Chris Lauwers
    Ubicity Corp.
    ------------------------------



  • 5.  RE: Deploying a system of ODA components

    TM Forum Member
    Posted 12 days ago
    Hi Chris,

    I atttach a sample schema snippet in YAML which shows composition , so this is handled Ok in JSON/YAML as are associations through  arrays ( The last two  keypoints  in  your note ) . The api calls , post, get etc ,may further restrict which objects are retrieved.

    WRT to  relationships.  are these different to those implemented as UML associations via array ref keywords ? I do see a difference in the richness  of  the TOSCA language  itself reading through the example  https://www.oasis-open.org/committees/download.php/68810/Substitution%20Mappings%202021-07-06.pdf , and in service mapping, but im not familiar with the format so would have to read up further on that.

    In particular there are two use cases of interest , namely  sub schema reference , and conditonality so that different paths may be "stitched" through  as described in the oasis doc above. We consider using the API calls to differentiate paths , via the relevant clauses on the one hand and in the schema itself on the other , which appears to be less supported at least in JSON 6 more so in JSON 7.

    ONF has started work in this area although incomplete, and the TMF API's support some of this functionality at least in sub schema handling if not conditionality.

    Certainly interesting and is a way forward in  distributed noSQL processing , as a potential application, see Couchbase etc.

    Best regards



    ------------------------------
    [Peter] [Skoularikos]
    [Telekinetics]
    peters@telekinetics.eu
    ------------------------------



  • 6.  RE: Deploying a system of ODA components

    TM Forum Member
    Posted 12 days ago
    And the snippet

    components:

     schemas:

        InventoryItem:

          type: object

          required:

            - id

            - name

            - releaseDate

          properties:

            id:

              type: string

              format: uuid

              example: d290f1ee-6c54-4b01-90e6-d701748f0851

            name:

              type: string

              example:

                        link:

               $ref: "#/components/schemas/YetAnotherObject"

                        releaseDate:

              type: string

              format: date-time

              example: '2016-08-29T09:12:33.001Z'

        Resource:    

            allOf: # Combines the main `Inventory ` schema with `Resource`specific properties

              - $ref: '#/components/schemas/InventoryItem'

              - type: object

            properties:

              name:

                type: string

                example: AMF

     

       Vendor:

            allOf: # Combines the Resource ` schema with `Vendor`specific properties

              - $ref: '#/components/schemas/Resource'

              - type: object

            properties:

              vendorName:

                type: string

                example: Nokia

     

     

        YetAnotherObject:

            properties:

               equipmentRef:

                type: string

                example:

              homePage:

                type: string

                format: url

                example: 'Yet Another object'



    ------------------------------
    [Peter] [Skoularikos]
    [Telekinetics]
    peters@telekinetics.eu
    ------------------------------