TM Forum Community

 View Only

  • 1.  Deploying a system of ODA components

    TM Forum Member
    Posted Jan 10, 2023 08:35

    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 Jan 11, 2023 04:06
    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
    ------------------------------

    Original Message


  • 3.  RE: Deploying a system of ODA components

    TM Forum Member
    Posted Jan 12, 2023 08:19
    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
    ------------------------------

    Original Message


  • 4.  RE: Deploying a system of ODA components

    Posted Jan 16, 2023 04:52
    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.
    ------------------------------

    Original Message


  • 5.  RE: Deploying a system of ODA components

    TM Forum Member
    Posted Jan 16, 2023 06:04
    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
    ------------------------------

    Original Message


  • 6.  RE: Deploying a system of ODA components

    Posted Feb 02, 2023 13:09

    Hi Peter, apologies for the late response. I somehow lost track of your message.

     

    In my opinion, the question isn't whether relationships in TOSCA are similar to ref's in JSON/YAML. The issue is what the intended use is of the language:

     

    • JSON (and more specifically JSONShema) defines schemas for data to be exchanged between communicating parties. It ensures that both parties have the same understanding of what the data mean
    • TOSCA is a language that is used to "instruct" an Orchestrator/Lifecycle Manager on how to deploy a system as modeled using TOSCA and as directed using orchestration instructions in the TOSCA document.

     

    The main benefit of TOSCA, in my opinion, is the orchestration semantics defined *in the language*. Yes, one can associate orchestration semantics with data modeled using YANG or JSONSchema, but those semantics would have to be documented externally to the YANG/JSONSchema documents. They are not part of YANG or JSONSchema.

     

    Hopefully that clarifies some of my earlier statements.

     

    Thanks,

     

    Chris

     




    Original Message


  • 7.  RE: Deploying a system of ODA components

    TM Forum Member
    Posted Jan 16, 2023 06:07
    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
    ------------------------------

    Original Message