Development Lifecycle (Draft)

Application Package

Use Case Sequence Diagram

@startuml
Title OSC Cherry Application LCM Step 1 - Create Application Package
skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 5
skinparam BoxPadding 10
skinparam ArrowColor #blue
autonumber

Box Vendor #lightsteelblue
Participant PMGR as "Package Manager" <<RICAPP>>
End box

Box Personnel #lightblue
Actor xDEV as "Application Developer" <<INT OTF>>
End box

== Package ==

xDEV -> PMGR : CreatePackage {releaseDir}
loop foreach defined deployment configuration
PMGR -> PMGR :
Note Right: Add App Descriptor for deployment

PMGR -> PMGR :
Note Right: Add Policy Profiles for deployment

PMGR -> PMGR :
Note Right: Add Data Consumption Requirements

PMGR -> PMGR :
Note Right: Add Data Publication Capabilities

PMGR -> PMGR :
Note Right: Add Deployment Configuration Data Requirements

PMGR -> PMGR :
Note Right: Add Application Configuration Data Requirements

PMGR -> PMGR :
Note Right: Add Deployment Images

alt Optional Certifications
PMGR -> PMGR : Add Image Signatures/Certificates
end if
end

@enduml



  • No labels

6 Comments

  1. Application Package:

    The application package looks quite close the cNF package demonstrated at 2020 June Virtual LFN Developer & Testing Forum 
    Pawel Slowikowski : May I kindly ask you to add Konrad here - looks like LFN does not automatically add key ONAP contributors to O-RAN-SC - Thanks!!

    The Package Structure/model may need to be enhanced for the ML part.

    If we target in Cheery dockerized apps only as a starting point, the "Dummy heat" part could be ignored - as far as I know some activities in this direction are developed in ONAP Guilin. Open question: how to add the ML Training part?

      1. Ok, I couldn't originally reply for some reason, but maybe this linking to me by Paweł unlocked my account on o-ran-sc subdomain.
        Anyway, I'll make myself familiar with this content here and say a word (smile)

    1. Thanks for the demo link. I see not much has changed in the ONAP SD module for VSP onboarding. Hopefully the existing ONAP onboarding implementation will not require a radical divergence. However, we are not basing the expected X1 interface for O-RAN on how ONAP VSP onboarding was implemented, but rather define the O-RAN requirements and then see if ONAP meets them or a gap exists which could be closed in the future. In the interim such methods as "gaming" the interface with "dummy" artifacts since we know how the internal validation/certification procedures view those artifacts could be used. This contextual coupling though should be limited to interim solutions and not for target requirements or implementations. I suggested we don't try to place SD into our development path, and be limited by its current capabilities. Instead the Model Catalog here represents that onboarding to distribute part of the demo.

      1. The NonRT RIC components are moving to ONAP repositories and going to be integrated with ONAP services. I think it is not reasonable to design NonRT RIC in separation from what is already defacto a standard and design everything from scratch. Then it will be difficult and time-consuming to contribute anything to ONAP, as it is now with OSC A1Policy controller and  SDN-R.

  2. Sequence 

    The sequence diagram focus on the a app creation by a 3rd Party - meaning outside of the SMO dev, build, deploy process. It describes the normal procedures of modern (please object (wink) ) app development.

    Regrading step 8 and 9.

    If the target are for Cherry are dockerizied apps for Cheery, then I see the app image and the app certs out side of the loop "deployment configuration". Images and certs are per app and should not be per app deployment. 

    Based on yesterdays twitter-account-issue (2020-07-16) the security aspects of package and app creation, management and usage should be considered from the very beginning. The O-RAN WG1 Security Task group may help on this?!?!  Meaning: Step9 should not be optional.