Use Case Sequence Diagram

@startuml
Title Application LCM Step 2 - Package Validation
skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 5
skinparam BoxPadding 10
skinparam ArrowColor #blue
autonumber

Box Personnel #lightblue
   Actor sOP as "SMO Operator" <<INT OTF>>
End box

Box "SMO" #gold
   Participant sPMGR as "Package Manager" <<RICAPP>>
   Boundary MC as "Model Catalog" <<SMO MVC State Manager>>
end box

== Validate ==

sOP -> sPMGR : ValidateStructure (packageFilename)
sPMGR -> sPMGR :
Note Left: Validate Package contents and structure

alt if Structure is Valid then
   sOP -> sPMGR : ValidateVersion (packageFilename, modelCatalogEndPoint)
   sPMGR -> sPMGR :
   Note Left: Extract Application Version from package

   sPMGR -> MC : GET ../applications/<ApplicationversionId>
   alt if version not found (rc = 404) then
      sPMGR -> MC : PUT ../applications/<ApplicationversionId> {State=VALIDATED}
   else
      note over sPMGR : Change to established version not allowed, version in package should be updated
   end if
else
   note over sPMGR : Package structure is not valid unable to create a record in Model Catalog
end if

@enduml
  • No labels

11 Comments

  1. Martin Skorupski

    Validation

    The different steps of the validation needs to be specified.

    In order to validate the package file structure it is necessary to define the "schema".

    ONAP for example uses CSAR. 

    Step5 and the next if-clause, can be avoided, if the package file integrity was proven. Meaning the file checksum matches the expectation. Please see: https://wiki.onap.org/display/DW/SDC%3A+Sign+a+package.

    The Step6 may overwrite and existing app but only with expected content. Assumption: the "ApplicationVersionId" is an uuid (https://tools.ietf.org/html/rfc4122).

    Note: uuids are for machine to machine interface, if you "human readable uuid" is required, then it should be called ApplicationVersionName or ApplicationVersionLabel and must not be used for any identification by software. 

    The package validation should check if the app image is available. 

    1. David Kinsey

      Correct with one exception. ONAP onboarding is a zip file. It then creates the TOSCA and on distribution sends the CSAR to the runtime. It cannot onboard a CSAR. File Checksum matching is what I thought for signing, however, I have been informed that is a very basic method. I myself don't know what all "signing" would entail. I could envision encryption of the package with a private key and verification by decryption with a public key. I am looking forward to learn from others what security mechanisms can be used.

      In regards to UUID or Human readable tags. The ApplicationVersionID is the human readable. I would be OK with renaming it to something like ApplicationVersionLabel or ApplicationVersionTag, as long as people understand it is the key and must be globally unique.

      1. Pawel Slowikowski

        There are different ways how packages are validated in ONAP: SDC, OPNVF Dovetail, VVP. Is the package validation going to be another validation mechanism?

        1. David Kinsey

          I think it premature to know. We don't fully understand the requirements, so I don't know if an existing implementation can be leveraged or extended. First we need to understand the O-RAN requirements. Then we can look at how ONAP would support it.

          1. Pawel Slowikowski

            I see that the diagram just shows a logical requirement to support package validation rather than detail steps how to achieve it.

            1. Pawel Slowikowski

              I mean that if you plan to ship a reference implementation of LCM in Cherry and propose the approach to be a part of specification then you will have an issue with adjustment of that solution to SMO (e.g. ONAP).

              1. David Kinsey

                I think if it not as a reference implementation, but a demonstration of requirement/capability. In that it is possible that issues will arise with existing solutions expected to become an SMO such as ONAP. However, that is always the risk when new requirements not yet anticipated are introduced to an existing solution. It should be expected that the demonstrated capability is something that would evolve as well, as the SMO has other considerations, not anticipated or accounted for in the demonstration.

  2. Martin Skorupski

    Model Catalog

    From a more technical view the Model Catalog is a combination of a database service and an interface. It looks like the sequence diagram assumes an RESTful interface. 

    If so, a non-sql database could be used, but of cause SQL DBs are also possible. 

    Please see: https://wiki.onap.org/display/DW/SDC+Cassandra+Data+Migration

    1. David Kinsey

      Correct, the MVC abstracts storage from access and storage format. In this case the internal storage could be changed depending on what is easiest, smallest, or other criteria. This should not affect the RESTful Control, or JSON View of the Model. In fact for this implementation as a Demo, it could be kept in memory.

  3. Martin Skorupski

    API

    It should be discussed and decided what kind of API is useful

    • Rest/OpenAPI
    • RestConf/Yang
    • gNMI/YANG
    • CLI
    • others....

    1. David Kinsey

      For simplicity I think RESTful is the quickest. We can evolve that view over time.