...
For the ASD and Package examples, see the ASD & packaging examples.
A "Sample" Application Model in TOSCA (note: this is a work in progress (by Ericsson); to be refined further)
...
- Package Delivery: A vendor delivers an SOL004-based ASD package
- Pre-Onboarding for validation: TBD (out of PoC scope)
- Onboarding: SDC brings in and stores resources such as xNF, xApp and rApp into ONAP for later use in services.
Onboarding SDC Design Consideration (in progress)
- SDC supports multiple models, e.g., SDC model, ETSI model, vendor/operator specific models
- SDC supports onboarding, design and packaging of services/resources that adhere to any of the supported models instead of just the SDC model
- SDC can extend its multiple models to handle ASD model
- SDC supports translation between models where appropriate/wanted, e.g., translation of ASD model to SDC model
- A type is added to the DB schema to define models (e.g., SDC model would be one instance, ETSI SO001 would be another, ASD would be another)
- When adding node types, data types, etc. in SDC, they can be associated with one or more models
- Id of the types must be set to ensure types with the same name can exist in different models
- On creating a new service:
- Select the model applicable to the service
- Only resources from that model, or based on that model, can be used in designing the service
- Ensures, for example, that only ETSI types can be used when designing a ETSI NS
- Where non SDC model is selected, the topology template is constructed without any ONAP specific structuring
- Option to generate a service that is a mapping of the created (e.g. ETSI NS) service in the ONAP SDC model and using ONAP structure
- This will be a separate service, but with the option to auto update as required
- Automated generation for convenience, but creating as a separate service allows the user the opportunity to fine tune to address any gaps or short comings in the translation logic
- Distribution: It will be possible to distinguish ONAP from non-ONAP services in the distribution notification
- Onboarding a VSP:
- Select the model applicable to the VSP
- Validator used in onboarding is selected based on the specified model
- VF generated using the types from the specified model
- Where new types are defined in the csar, a new model is created which is specific to the csar
- Where ONAP model is selected, VF is import as today
- Where another model is selected, the VF is created using the types defined for that model, and using standard TOSCA structure (e.g. the substitutable as node type is preserved in the generated VF)
- Option to generate a VF that is a mapping of the created VF in the ONAP SDC model and structure (similar to what is proposed for services)
Onboarding Information Flow
SDC needs to support the following onboarding process.
...
For the ASD and Package examples, see the ASD & packaging examples.
A "Sample" Application Model in TOSCA (note: this is a work in progress (by Ericsson); to be refined further)
...