diff --git a/doc/architecture/CRIDGE/CRIDGEforDevelopers.md b/doc/architecture/CRIDGE/CRIDGEforDevelopers.md
index 03eaa432546d3e75ef1abe608862a3612294ee49..10cd9ac45c80ad5606af1fa18d611b753ad261fd 100644
--- a/doc/architecture/CRIDGE/CRIDGEforDevelopers.md
+++ b/doc/architecture/CRIDGE/CRIDGEforDevelopers.md
@@ -214,10 +214,10 @@ OSOM sends to CRIDGE a message with the following information:
---
-## What's next?
+## Probe further
- See examples of exposing operators via OpenSlice:
- - [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](ExposingCRDs_aaS_Example_Calculator.md)
+ - [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](../../service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md)
diff --git a/doc/architecture/nfvweb.md b/doc/architecture/nfvweb.md
deleted file mode 100644
index b96dee34a9662e14f4c5eb3f41f507817686b094..0000000000000000000000000000000000000000
--- a/doc/architecture/nfvweb.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Openslice NFV Web Portal
-
-The [NFV Web Portal](http://portal.openslice.io/nfvportal) offers a domain-specific UI to manage NFV Services.
-
-Indicatively, the portal can be used to:
-- Register new a new MANO provider (e.g. OSM)
-- Synchronize the onboarded VNF/NS packages, and the VIMs of the registered MANO provider
-- Onboard/Delete VNF/NS packages on specific MANO provider
-- Deploy a NS to a target MANO provider
-
-More information can be found at [NFV Services](../nfvcatalogs.md).
\ No newline at end of file
diff --git a/doc/config_intro.md b/doc/config_intro.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..c3549c1554349b33b949f361341d15cbb7bbd500 100644
--- a/doc/config_intro.md
+++ b/doc/config_intro.md
@@ -0,0 +1,9 @@
+# Configuring and managing OpenSlice
+
+## Intended Audience: OpenSlice administrators
+
+This section provides information on how to configure and manage different aspect of OpenSlice while in operation. For example:
+
+* Manage user roles and access in Keycloak
+* Configure/Manage NFVOs
+* Advanced configuration scenarios
\ No newline at end of file
diff --git a/doc/index.md b/doc/index.md
index bc28cea1217f2415a49cee368bb96708ab111885..eb0d7755c75f184683cf94700b3f1d02f6453c3e 100644
--- a/doc/index.md
+++ b/doc/index.md
@@ -46,9 +46,9 @@ OpenSlice is used by Service Providers to design Network Services, expose them i
There are various portals offering UI friendly access to users acting as Service Providers:
* The Services portal allows Service Providers to design and expose services.
-* The Resoruce portal allows users to access resource specifications and running resources in resource inventory.
+* The Resource portal allows users to access resource specifications and running resources in resource inventory.
* The NFV portal allows users to manage NFV artifacts and onboard them to a target MANO/NFV Orchestrator.
-* The teting portal allows Service Providers to manage test artifacts
+* The Testing portal allows Service Providers to manage test artifacts
* The Products portal allows Service Providers to expose services as products
### OpenSlice for Service Consumers
@@ -57,9 +57,9 @@ OpenSlice allows Service Consumers to browse the available offered service speci
There are various portals offering UI friendly access to users acting as Service Consumers:
* The Services portal allows Service Consumers to select and order predefined services.
-* The Resoruce portal allows users to access running resources in resource inventory.
+* The Resource portal allows users to access running resources in resource inventory.
* The NFV portal allows users to self-manage NFV artifacts and onboard them to a target MANO/NFV Orchestrator.
-* The testing portal allows Service Consumers to manage test artifacts
+* The Testing portal allows Service Consumers to manage test artifacts
* The Products portal allows Service Consumers to expose services as products
3rd party applications can use OpenSlice through TMForum Open APIs.
@@ -78,12 +78,9 @@ Check a live demo of OpenSlice in the following pages:
>
>
-# What's next
+# Probe further
-Installing OpenSlice. See the [Deployment](deployment.md) of OpenSlice
-
-Lear more on [how OpenSlice supports Network as a Service(NaaS)](./naas/introduction.md)
-
-Who is implementing OpenSlice? See [OSL ETSI SDG](https://osl.etsi.org/)
-
-How OpenSlice works? See the [Architecture](./architecture/architecture.md) of OpenSlice
+* Installing OpenSlice. See the [Deployment](deployment.md) of OpenSlice
+* Learn more on [how OpenSlice supports Network as a Service(NaaS)](./naas/introduction
+* Who is implementing OpenSlice? See [OSL ETSI SDG](https://osl.etsi.org/)
+* How OpenSlice works? See the [Architecture](./architecture/architecture.md) of OpenSlice
diff --git a/doc/lcm.md b/doc/lcm.md
deleted file mode 100644
index b668b908c58da2c6972e11a0b6ca50450fd02176..0000000000000000000000000000000000000000
--- a/doc/lcm.md
+++ /dev/null
@@ -1,158 +0,0 @@
-# Lifecycle Management (LCM) Rules
-
-* NOTE: This is a prototype/experimental feature. So issues might raise during operation
-
-LCM Rules are used for defining complex conditions and actions during the lifecycle of a service. In Openslice there are four types of rules defined:
-
-* PRE_PROVISION
-* CREATION
-* AFTER_ACTIVATION
-* SUPERVISION
-* AFTER_DEACTIVATION
-
-
-The following figure displays the different phases that the rules are performed, during the lifecycle of a Network Slice Instance.
-
-[](../images/lcm/lcmfig1.png)
-
-* PRE_PROVISION rules: Run only once just before creating a service with a given priority.
-* CREATION rules: Run while the referenced service dependencies of a service are created
-* AFTER_ACTIVATION rules: Run only once just after a service get the ACTIVE state
-* SUPERVISION rules: Run when a characteristic of a service is changed and the service is in the ACTIVE state
-* AFTER_DEACTIVATION rules: Run only once just after a service get the INACTIVE/TERMINATED state
-
-In general the rules allow to perform many actions during service LCM. Thes are some examples:
-
-* Modify service specification parameters before the instantiation of a service (or during operation) based on other dependencies. These parameters might be part of other services already included in Service order
-* Translate GST/NEST parameter values to other values passed later to NFVO for instantiation or control
-* Define complex OSM Configs based on other dependencies and passing variables
-* Define any dependencies when creating the referenced services
-* Dynamically include new service dependencies
-* Create new service orders so include dynamically other services
-* Call external (RESTful) services (via http(s), define payload, examine response)
-
-
-
-
-## Examine if the rules are executed successfully
-
-Rules are transformed automatically to executable code (currently is Java). If a rule is performed successfully or has any issues (e.g. unexpected syntax errors or exceptions) appear in OSOM logfiles and also tey are attached as Notes to the running Service.
-
-## LCM Rules and OSOM Service Orchestration
-
-OSOM is the responsible service for executing the rules on a specific phase. The following image explains the design in the BPMN phases:
-
-
-[](../images/lcm/lcmfig1_osom.png)
-
-
-
-## Define rules
-
-Rules are defined when designing a Service Spec. Here is an example of a list of rules:
-
-
-[](../images/lcm/lcmfig2.png)
-
-Execution order of rules on a specific phase is random
-
-* NOTE: There is a priority field. The lower the number the highest the priority of rule execution. For example Rule with priority 0 will run before rule with priority 1.
-
-
-### Definition language
-
-* The visual language that Openslice used is based on Google's Blockly (see https://developers.google.com/blockly)
-* The blockly graph is automatically translated to Java internally and then dynamically executed during orchestration phases.
-
-The following figure is an example of such a rule design. The rule for example will run in PRE_PROVISION phase:
-
-[](../images/lcm/lcmfig3.png)
-
-* The goal of the above rule is to properly define a variable AreaCodes given the chosen AreaOfService from a Service Order.
-* On the right side the user can define some rule properties or observe the underlying generated java code.
-
-
-## The blocks library
-
-The following images describe some blocks found in the library.
-
-Blockly has syntax rules. It helps with colours to define them.
-
-So for example a parameter that is a Number cannot be "glued" with a String. Will need some conversion first
-
-[](../images/lcm/lcmfig4.png)
-[](../images/lcm/lcmfig5.png)
-[](../images/lcm/lcmfig6.png)
-[](../images/lcm/lcmfig7.png)
-[](../images/lcm/lcmfig8.png)
-
-## Examples of Rules
-
-
-The following images provide some examples of rules.
-
-### define variables according to cases
-
-In the following example we :
-
-* define a String variable.
-* Then according to the Area of Service selected from the Service Order of the Service Specification we need to define it properly.
-* We output the value to the OSOM Log
-* Define dynamically the value of another parameter (This is fictional) and then do some other condition check
-
-The strAreaCodes could be passed then e.g. to NFVO for instantiation of services to these cells.
-
-
-[](../images/lcm/lcmfig9.png)
-
-
-
-### Define complex OSM configs for DAY 0
-
-The following displays some complex examples for defining the parameters to pass to the NFV. In this case is OSM.
-
-* NOTE: The OSM_CONFIG characteristic of a service is the one that it is used in orchestration to instantiate NS from OSM
-
-* check the variable strTargetsParam. It is passed to the variable strOsmConfig3 which is executed if the Number of Cameras is more than 100.
-* if the Video quality requested is 3, then the Maximum Namber of camers will be 8. Check the OSM detailed configuration block and its syntax.
-* if the Video quality requested is 2, we use a simpler OSM Config block to configure the parameter OSM_CONFIG. We just injected a json text ( watch the Escape of the string for the Quotes!)
-* if the Video quality requested is 1, again we use a simpler OSM Config block to configure the parameter OSM_CONFIG. We use as injected json text a variable constructed later
-
-
-[](../images/lcm/lcmfig10.png)
-
-
-### Define and instantiate different services according to Service Order request
-
-In the following example we would like to offer a service either as Platinum, Gold or Silver. Depending on the selection we need to instantiate different services.
-
-There are different ways to accomplish this:
-
-* create dynamically New Service Orders of RFSs with equivalent quality of Services
-* change for example the VIMs that you deploy the NS
-* change the NSD (that is use different VNFs)
-
-The following image displays for example the latter case.
-
-[](../images/lcm/lcmfig11.png)
-
-
-### Call an external RESTful service
-
-This is useful in cases for example of alarms , external logging, calling other services e.g. email or even a complex algorithm written in other language e.g. call an external service and get a result. (service e.g. a Python service)
-
-
-[](../images/lcm/lcmfig12.png)
-
-[](../images/lcm/lcmfig13.png)
-
-### Create New Service Orders
-
-The following example calls to Order a New Service Specification with specific Parameter Values
-
-[](../images/lcm/lcmfig14.png)
-
-
-
-
-
diff --git a/doc/naas/exposed_apis.md b/doc/naas/exposed_apis.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..b6efad8f34d635c9e258a8a2aeded50fb74ab227 100644
--- a/doc/naas/exposed_apis.md
+++ b/doc/naas/exposed_apis.md
@@ -0,0 +1,23 @@
+|Endpoint |Title |Description |Version
+|:------:|:------:|:------:|:------:|
+|/tmf-api/serviceCatalogManagement/v4 |633 Service Catalog Management |Provides a catalog of services. |4.0.0
+|/tmf-api/productCatalogManagement/v4/ |620 Product Catalog Management |Provides a catalog of products. |4.0.0
+|/tmf-api/productOrderingManagement/v4/ v622 Product Ordering |Provides a standardized mechanism for placing a product order. |4.0.0
+|/tmf-api/resourceCatalogManagement/v4 |634 Resource Catalog Management |This is Swagger UI environment generated for the TMF Resource Catalog Management specification. |4.0.0
+|/tmf-api/serviceInventory/v4 |638 Service Inventory Management |Provides a consistent/standardized mechanism to query and manipulate the Service inventory. |4.0.0
+|/tmf-api/serviceOrdering/v4 |641 API ServiceOrdering |Provides a standardized mechanism for managing Service Order. |4.0.0
+|/tmf-api/serviceQualityManagement/v2 |657 Service Quality Management |This is Swagger UI environment generated for the TMF Service Quality Management specification. |2.0.0
+|/tmf-api/partyRoleManagement/v4/ |669 Party Role Management |This is Swagger UI environment generated for the TMF Party Role Management specification. |4.0.0
+|/tmf-api/party/v4/organization |632 API Party |Provides standardized mechanism for party management such as creation, update, retrieval, deletion and notification of events. |4.0.0
+|/tmf-api/agreementManagement/v2/ |651 Agreement Management T|his is Swagger UI environment generated for the TMF Agreement Management specification. |2.0.0
+|/tmf-api/resourceOrderingManagement/v4 |652 Resource Order Management-v4.0.0 |This is Swagger UI environment generated for the TMF 652-Resource Order Management-v4.0.0 specification. |4.0.0
+|/tmf-api/accountManagement/v4 |666 Account Management |This is Swagger UI environment generated for the TMF Account Management specification.| 4.0.0
+|/tmf-api/customerManagement/v4 |629 Customer Management |TMF Customer Management |4.0.0
+|/tmf-api/userinfo |691 Federated ID |TMF Federated ID |1.0.0
+|/tmf-api/ServiceActivationAndConfiguration/v3/ |640 API Service Activation and Configuration| Provides the ability to activate and configure Services. |3.0.0
+|/tmf-api/alarmManagement/v4/ |642 API Alarm| |4.0.0
+|/tmf-api/serviceTestManagement/v4 |653 Service Test Management |Provides the ability to manage tests of provisioned Services. |4.0.0
+|/tmf-api/resourceInventoryManagement/v4 |639 API Resource Inventory Management |Provides the ability to manage Resources. |4.0.0
+|/tmf-api/lcmrulesmanagement/v1/ |LCM Rules Custom API environment for LCM Rules| |1.0.0
+|/tmf-api/resourcePoolManagement/v1 |685 Resource Pool Management |Resources that can be reserved are only in one pool. |1.0.0
+|/tmf-api/geographicSiteManagement/v5 |674 Geographic Site Management |Covers the operations to manage sites that can be associated with entities |5.0.0
\ No newline at end of file
diff --git a/doc/naas/gst_to_gsma/img01.png b/doc/naas/gst_to_gsma/img01.png
new file mode 100644
index 0000000000000000000000000000000000000000..f72c1855e08903dfcca60a213b88a106775b8130
Binary files /dev/null and b/doc/naas/gst_to_gsma/img01.png differ
diff --git a/doc/naas/gst_to_tmf.md b/doc/naas/gst_to_tmf.md
new file mode 100644
index 0000000000000000000000000000000000000000..8de472024ac206982ef938b28e86ffdf51584fe2
--- /dev/null
+++ b/doc/naas/gst_to_tmf.md
@@ -0,0 +1,31 @@
+# Generic Slice Template as a Service Specification
+
+## Intended Audience: Service Designers
+
+GSMA Generic Slice Template (GST) Defines customer-oriented service requirements, E.g. Availability, Area of service, delay tolerance, etc. and attempts to narrow down the gap between (network) service customers and vendors
+
+Moreove it Proposes standardized Network Slice Templates (NESTs) to target specific use cases
+
+
+In OpenSlice we made an effort and translated the GST to a Service Specification model. So Service Designers can use it as a template to design a new Service.
+
+The image illustrates the relationship between the GSMA Generic Slice Template (GST), TM Forum Service Specification, and how they are utilized within OpenSlice to offer network services.
+
+[](./gst_to_gsma/img01.png)
+
+The GST to TM Forum via OpenSlice:
+
+ * GST Attributes List: A comprehensive list of service attributes, such as availability, delay tolerance, downlink throughput, energy efficiency, isolation level, mission-critical support, and many others.
+ * TMF Service Specification: Demonstrates the transformation of GST attributes into a TM Forum service specification, showing JSON code snippets that define service parameters.
+ * Offered Service based on GST: Represents the final offered service, an example of a GST-based service shown as an entry in a catalog, ready to be consumed by customers.
+
+What was our flow:
+
+ * Started with defining service requirements and attributes using GST.
+ * Translated these GST attributes into a formal TM Forum service specification.
+ * Service Offering in OpenSlice: The service specification is then used to create and offer a specific network service within OpenSlice, available for customer selection and deployment.
+
+
+## Probe further
+
+See v9 of the GST model in GSMA [here](https://www.gsma.com/newsroom/wp-content/uploads//NG.116-v9.0-1.pdf)
\ No newline at end of file
diff --git a/doc/naas/introduction.md b/doc/naas/introduction.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..a478341213daff048a021fe52ca5e37d941ba628 100644
--- a/doc/naas/introduction.md
+++ b/doc/naas/introduction.md
@@ -0,0 +1,26 @@
+# Network as a Service (NaaS)
+
+This section describes some core concepts for Delivering Network as a Service in OpenSlice. There are many articles and reports on the subject like:
+
+
+* TMF909 API Suite Specification for NaaS
+* TMF926A Connectivity as a Service
+* TMF931-Open Gateway Onboarding and Ordering Component Suite
+* GSMA Open Gatewy initiative
+
+In general Network as a Service (NaaS) is a service model that allows users to consume network infrastructure and services , similar to how they would consume other cloud services like Software as a Service (SaaS) or Infrastructure as a Service (IaaS). NaaS abstracts the complexity of managing physical network infrastructure, providing users with virtualized network resources that can be dynamically allocated and managed through software.
+
+
+# OpenSlice and NaaS
+
+OpenSlice makes extensive use of TMFORUM's models and APIs. Therefore if one is familiar with TMF APIs the terminology and ideas are the same.
+
+To deliver NaaS we need to incorporate various APIs (see TMF909 API Suite Specification for NaaS). OpenSlice implements various TMF APIs to deliver NaaS and support the lifecycle functions required to manage the network capabilities exposed as Network as a Service and managed by operational domains.
+
+
+
+## Probe further
+
+* Check the [TMFORUM - API assets - Onboarding and Ordering Component Suite (TMF931)](https://www.tmforum.org/oda/open-apis/partners/camara)
+* For a complete list of supported APIs, see [Supported APIs](exposed_apis.md)
+* Check the defined user roles of OpenSlice in our [Terminology](../terminology.md)
\ No newline at end of file
diff --git a/doc/naas/lcm/img01.png b/doc/naas/lcm/img01.png
new file mode 100644
index 0000000000000000000000000000000000000000..145c8976ccf2b3f60304a74d59138f00eb88b3ce
Binary files /dev/null and b/doc/naas/lcm/img01.png differ
diff --git a/doc/naas/lcm/img02.png b/doc/naas/lcm/img02.png
new file mode 100644
index 0000000000000000000000000000000000000000..a98bcfb28dc42a3182730671fc6ec095c4c66a6d
Binary files /dev/null and b/doc/naas/lcm/img02.png differ
diff --git a/doc/naas/lcm/img03.png b/doc/naas/lcm/img03.png
new file mode 100644
index 0000000000000000000000000000000000000000..bd0afe6e125b54d1956c84075d5a9f54312537aa
Binary files /dev/null and b/doc/naas/lcm/img03.png differ
diff --git a/doc/naas/lcm_intro.md b/doc/naas/lcm_intro.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..5670c58f2197bba6e08f015996b137f3f307842e 100644
--- a/doc/naas/lcm_intro.md
+++ b/doc/naas/lcm_intro.md
@@ -0,0 +1,108 @@
+# Lifecycle Management - LCM
+
+
+Lifecycle Management: The orchestration framework handles the activation, termination and any necessary modifications throughout the service lifecycle.
+
+
+## Intended Audience: Service Designers
+
+
+In OpenSlice the Lifecycle of a service follows in general the concept of Network Slice lifecycle as defined by 3GPP.
+
+
+[](./lcm/img01.png)
+
+## Introduction in OpenSlice LCM
+
+OpenSlice adopted the LCM model by 3GPP and mapped to the TMF model service state. Next we discuss briefly the process and the relationships.
+
+The lifecycle of a service, particularly in the context of Network Service lifecycle encompasses several stages that ensure the service is effectively planned, deployed, managed, and eventually decommissioned.
+
+Here is an overview of these stages and relationships with OpenSlice:
+
+### 0. Preparation Phase
+
+This phase is performed by Service Designers
+
+#### Service Design:
+- **Requirements Gathering:** Collect service requirements from stakeholders, including performance metrics, quality of service (QoS), security needs, and geographical coverage.
+- **Service Specification:** Define the service in terms of functionalities, attributes, and dependencies. This can be formalized using standardized templates such as the GSMA Generic Slice Template (GST).
+- **Resource Planning:** Identify and plan the required resources, including network functions, computing power, storage, and connectivity, inclluding network function configurations.
+- **Expose to Service Catalog**: Expose to service catalog for user ordering.
+
+
+
+**Next phases are handled by the Service Orchestrator after a service is scheduled for instantiation**
+
+**If it is a bundle of services, each services follows its own Lifecycle!**
+
+
+### 1. Instantiation Phase
+
+#### Service Instantiation:
+
+- **Configuration:** Configure the network service according to the specifications including the user requirements from the service order, ensuring that all components are correctly set up to provide the desired service.
+- **Resource Allocation - Feasibility check:** Allocate the necessary physical and virtual resources based on the service specification. This includes any containerized resources, virtual network functions (VNFs) and software-defined networking (SDN) components. (This step is not performed in OpenSlice)
+- OpenSlice Service Orchestrator creates the services at "RESERVED" state
+- **User Notification:** There could be an email notification from the system (if Bugzilla is configured)
+
+#### Service Deployment:
+
+- **Activation:** OpenSlice Service Orchestrator activates the network service and makes the service available to the end-users. This may involve:
+ - Create any related services that the service depends on
+ - Contacting all related controllers during provisioning, e.g. Kubernetes controllers, Kubernetes operators, MANO Orchestrators, RAN controllers, SDN Controlles, or other external services (e.g. via REST calls)
+ - Scheduling instantiation, Resolving dependencies and passing paramemters between controllers,
+ - setting up user accounts, provisioning access credentials -this is performed either offline or via other services.
+- OpenSlice Service Orchestrator if everything is succesful puts the service at "ACTIVE" state
+- **User Notification:** There could be an email notification from the system (if Bugzilla is configured)
+
+### 2. Operation Phase
+
+#### Service Operation:
+
+- **Lifecycle Management:** Manage the network slice throughout its lifecycle, including scaling, reconfiguration, and adaptation to changing requirements.
+- In OpenSlice this is performed with Lifecycle management Rules (see next)
+
+In this phase the Service Designer can define several aspects. **Be aware that these are NOT performed automatically by OpenSlice - further examples and future enhancements will address these**. This could include:
+
+- **Monitoring:** Continuously monitor the service for performance, availability, and compliance with SLAs. Utilize tools for real-time tracking and alerts for any anomalies or performance degradation.
+- **Maintenance:** Conduct regular maintenance activities, including software updates, patching, and optimization to ensure the service runs smoothly.
+- **Scaling:** Dynamically scale the resources up or down based on the demand and performance requirements.
+- **Fault Management:** Detect and resolve faults in the network slice to minimize downtime and maintain service quality.
+
+### 3. Decommissioning Phase
+
+- **Service Termination:** Service Orchestrator terminates the network service. This may involve:
+ - Terminate any related services that the service depends on
+ - Contacting all related controllers during termination to release resources, e.g. Kubernetes controllers, Kubernetes operators, MANO Orchestrators, RAN controllers, SDN Controlles, or other external services (e.g. via REST calls)
+ - Scheduling termination, Resolving dependencies and passing paramemters between controllers
+- OpenSlice Service Orchestrator, if everything is succesful, puts the service at "TERMINATED" state
+- **User Notification:** There could be an email notification from the system (if Bugzilla is configured)
+
+### High level example: Enhanced Mobile Broadband (eMBB) Service Lifecycle
+
+1. **Preparation:**
+
+ - Define eMBB service requirements for high bandwidth and low latency.
+ - Create an eMBB service specification template specifying related services and resources to Kubernetes Operators, VNFs for content delivery and traffic management.
+ - Expose to catalog
+
+2. **Instantiation:**
+
+ - Instantiate other services and allocate resources such as edge computing nodes and high-capacity links.
+ - Configure the service to prioritize video streaming traffic.
+
+3. **Operation:**
+
+ - Monitor the service to ensure it meets high-bandwidth requirements.
+ - Scale up resources during peak usage periods, such as live sports events.
+
+4. **Decommissioning:**
+
+ - Notify users about service termination.
+ - Decommission the network service, reclaiming resources for other services.
+
+
+## Probe further
+
+* See 3GPP [Lifecycle](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3091)
\ No newline at end of file
diff --git a/doc/naas/lcm_rules_intro.md b/doc/naas/lcm_rules_intro.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..f7d70588e8a9b783d071a147571db4d57183fe95 100644
--- a/doc/naas/lcm_rules_intro.md
+++ b/doc/naas/lcm_rules_intro.md
@@ -0,0 +1,60 @@
+# Lifecycle Management Rules - LCM Rules
+
+
+Lifecycle Management Rules: Defining complex conditions and actions during the lifecycle of a service and any necessary modifications throughout the service lifecycle.
+
+
+## Intended Audience: Service Designers
+
+ OpenSlice end-to-end (E2E) service orchestrator follows some predefined workflows to manage a service lifecycle (They are described in BPMN language and included in our orchestration engine)
+
+ So in the system there are already predefined recipes, which in each process-step of the workflow some piece of code is executed.
+
+ How is it possible to intervene in the workflow process and inject some user defined actions? The next image illustrates the idea
+
+[](./lcm/img02.png)
+
+## How is it possible to intervene in the workflow process and affect it?
+
+LCM Rules are used for defining complex conditions and actions during the lifecycle of a service. In Openslice there are the following types of rules defined:
+
+* PRE_PROVISION
+* CREATION
+* AFTER_ACTIVATION
+* SUPERVISION
+* AFTER_DEACTIVATION
+
+The following figure displays the different phases that the rules are performed, during the lifecycle of a Network Service Instance.
+
+
+[](./lcm/img03.png)
+
+
+* PRE_PROVISION rules: Run only once just before creating a service with a given priority.
+* CREATION rules: Run while the referenced service dependencies of a service are created
+* AFTER_ACTIVATION rules: Run only once just after a service get the ACTIVE state
+* SUPERVISION rules: Run when a characteristic of a service is changed and the service is in the ACTIVE state
+* AFTER_DEACTIVATION rules: Run only once just after a service get the INACTIVE/TERMINATED state
+
+In general the rules allow to perform many actions during service LCM. These are some examples:
+
+* Modify service specification parameters before the instantiation of a service (or during operation) based on other dependencies. These parameters might be part of other services already included in Service order
+* Translate GST/NEST parameter values to other values passed later to NFVO for instantiation or control
+* Define complex OSM Configs based on other dependencies and passing variables
+* Define any dependencies when creating the referenced services
+* Dynamically include new service dependencies
+* Create new service orders so include dynamically other services
+* Call external (RESTful) services (via http(s), define payload, examine response)
+
+
+
+
+## Examine if the rules are executed successfully
+
+Rules are transformed automatically to executable code (currently is Java). If a rule is performed successfully or has any issues (e.g. unexpected syntax errors or exceptions) appear in OSOM logfiles and also tey are attached as Notes to the running Service.
+
+
+## Probe further
+
+* In the [Service Design](../service_design/intro.md) section we present in details the Lifecycle rules and how one can design them
+* Many of them are used in our provided Service Design [examples](../service_design/examples/intro.md)
\ No newline at end of file
diff --git a/doc/nfvcatalogs.md b/doc/naas/nfv/nfvservices.md
similarity index 100%
rename from doc/nfvcatalogs.md
rename to doc/naas/nfv/nfvservices.md
diff --git a/doc/naas/resource_catalog.md b/doc/naas/resource_catalog.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..c7ac604d058a19efd723e8b71357f19ab99dda09 100644
--- a/doc/naas/resource_catalog.md
+++ b/doc/naas/resource_catalog.md
@@ -0,0 +1,6 @@
+
+
+#OpenSlice Resource Catalog:
+
+ * Resource Specifications: Defines the underlying resources required to deliver services, such as network components, servers, and software.
+ * Resource Availability: Tracks the availability and status of resources to ensure efficient service delivery.
\ No newline at end of file
diff --git a/doc/naas/service_catalog.md b/doc/naas/service_catalog.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..a11afbbd2e925e09815aa3e21b932a2ce01e51d3 100644
--- a/doc/naas/service_catalog.md
+++ b/doc/naas/service_catalog.md
@@ -0,0 +1,51 @@
+# OpenSlice Service Catalogs
+
+OpenSlice offers complete management of Service Catalogs.
+
+## Intended Audience: Service Designers, OpenSlice administrators, Users
+
+
+OpenSlice offers complete management of Service Catalogs which offer to end users:
+
+* Service categories: Lists the available services, including their specifications and performance metrics.
+* Service Bundles: Combines multiple services into a single offering to provide added value to customers.
+
+Service Catalogs contain Service Specifications (organized in Service Categories) exposed to users for Service Orders.
+
+
+## UI management
+
+In the UI this looks like the following. Service catalogs and categories exposed in Service marketplace.
+
+In the menu the administrator can manage the Service Catalogs and Categories.
+
+[](./service_catalog/img01.png)
+
+
+## API exposed
+
+When installing OpenSlice the API endpoints can be browsed at:
+```
+[YOURDOMAIN]/tmf-api/swagger-ui/index.html?urls.primaryName=tmf-api-633-ServiceCatalogManagement-v4.0.0
+
+endpoint examples:
+
+/serviceCatalogManagement/v4/serviceCatalog List or find ServiceCatalog objects
+/serviceCatalogManagement/v4/serviceCategory List or find ServiceCategory objects
+
+```
+
+## Example Use Case
+
+Scenario: A service provider wants to offer a new managed XXXX service to enterprise customers.
+
+ * Service Definition: Service Template thus create a template for the XXXX service, including specifications for bandwidth, network features, and performance metrics.
+ * Service Catalog Integration: Add to Service Catalog the XXXX service with all relevant details.
+ * Service Delivery/Order: Provision Service by Using the orchestration system to provision and configure the XXXX service based on customer orders.
+
+
+## Probe further
+
+* Read the model of Service Catalogs in TMF [TMF633 Service Catalog API User Guide v4.0.0](https://www.tmforum.org/resources/specification/tmf633-service-catalog-api-user-guide-v4-0-0/)
+* Check a demo of the API [here](http://portal.openslice.io/tmf-api/swagger-ui/index.html?urls.primaryName=tmf-api-633-ServiceCatalogManagement-v4.0.0)
+* Check a demo of the Catalog and Categories [here](http://portal.openslice.io)
\ No newline at end of file
diff --git a/doc/naas/service_catalog/img01.png b/doc/naas/service_catalog/img01.png
new file mode 100644
index 0000000000000000000000000000000000000000..84e3830dd98c49ff6177f914e84ea82b027e5410
Binary files /dev/null and b/doc/naas/service_catalog/img01.png differ
diff --git a/doc/naas/service_inventory.md b/doc/naas/service_inventory.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..49c1fdca60183fc1e2c4f3d8e21b3fd385746930 100644
--- a/doc/naas/service_inventory.md
+++ b/doc/naas/service_inventory.md
@@ -0,0 +1,35 @@
+# Service Inventory
+
+Service Inventory contains refences to running services that realize a Service Order
+
+## Intended Audience: Service Designers, OpenSlice administrators, Users
+
+
+The Service Inventory is a repository that maintains detailed records of all active services and the underlying resources that support them. It acts as a central repository, tracking the lifecycle of each service from provisioning to decommissioning, and includes references to the specific virtual and physical resources that realize the service, such as servers, network components, storage, and software instances.
+
+This inventory enables real-time visibility into the status, configuration, and dependencies of each service, facilitating effective management, troubleshooting, and optimization.
+
+By providing a view of the active services, the Service Inventory includes services/resource allocation, and ensures that services are delivered in alignment with the inital requst.
+
+
+## UI management
+
+Through the menu and dedicated forms the administrator can manage the Service Inventory and any active Services (reconfigure or terminate).Various examples in this document will guide you to the usage and the management of the Services in Service Inventory.
+
+## API exposed
+
+When installing OpenSlice the API endpoints can be browsed at:
+```
+[YOURDOMAIN]/tmf-api/swagger-ui/index.html?urls.primaryName=tmf-api-638-ServiceInventoryManagement-v4.0.0
+```
+
+endpoint examples:
+
+/serviceInventory/v4/service List or find Service objects
+
+
+## Probe further
+
+* See [Ordering Services from catalogs](../service_ordering/ordering_services.md)
+* See [Service Design](../service_design/intro.md)
+
diff --git a/doc/naas/service_ordering.md b/doc/naas/service_ordering.md
new file mode 100644
index 0000000000000000000000000000000000000000..347091d334b0930e2ba0df2458e826c96167f366
--- /dev/null
+++ b/doc/naas/service_ordering.md
@@ -0,0 +1,43 @@
+# Service Ordering
+
+Customer Facing Service Specifications - or also CFSSpec (organized in Service Categories) are exposed to users for Service Orders.
+
+## Intended Audience: Service Designers, OpenSlice administrators
+
+
+The Service Order process is a structured sequence of steps initiated by a customer's Service Order request for a specific service, aimed at delivering and activating the desired service or services (if it is a service bunlde), as well as its related services. It begins with the customer submitting a service request through OpenSlice Services portal or the Service Order API, specifying the necessary details such as service specification, configurations, and any specific requirements.
+
+The request is then validated and verified for completeness and eligibility by an administrator which marks the Service Order as ACKNOWLEDGED otherwise it rejects it.
+
+Once ACKNOWLEDGED, the service order is processed by OpenSlice orchestration system (OSOM), which schedules/automates the provisioning of the required resources and configurations, coordinating across various components such as MANO controlers for virtual network functions (VNFs), or Containerized controllers or any 3rd party controllers or services or even physical infrastructure. The OpenSlice orchestration system ensures that all dependencies are managed and that the service is correctly configured.
+
+After provisioning, the service is activated and handed over to the customer, . This end-to-end process ensures a seamless, efficient, and automated delivery of services, enhancing customer satisfaction and operational efficiency.
+
+Ongoing monitoring and other actions can be performed by the Life Cycle management rules
+
+
+<i>***Future developments***:
+In future releases it might be possible the ongoing monitoring and support provided to ensure continuous performance and reliability. The service could undergoe a series of tests to ensure it meets the specified performance metrics and SLAs before delivering</i>
+
+## UI management
+
+Through the menu and dedicated forms the administrator can manage the Service Orders. Various examples in this document will guide you to the usage and the management of the Service Orders.
+
+## API exposed
+
+When installing OpenSlice the API endpoints can be browsed at:
+```
+[YOURDOMAIN]/tmf-api/swagger-ui/index.html?urls.primaryName=tmf-api-641-ServiceOrdering-v4.0.0
+```
+
+endpoint examples:
+
+/serviceOrdering/v4/serviceOrder List or find ServiceOrder objects
+
+
+
+
+## Probe further
+
+* See [Ordering Services from catalogs](../service_ordering/ordering_services.md)
+* See [Service Design](../service_design/intro.md)
\ No newline at end of file
diff --git a/doc/naas/service_spec.md b/doc/naas/service_spec.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..5a3289f205299a3f21197ac7e44e16254ab01099 100644
--- a/doc/naas/service_spec.md
+++ b/doc/naas/service_spec.md
@@ -0,0 +1,71 @@
+# OpenSlice Service Specification
+
+OpenSlice offers complete management of Service Specifications.
+
+## Intended Audience: Service Designers
+
+Service Specification is an entity that describes a service offering. There are two types of Service Specifications:
+
+* Resource Facing Service Specification
+* Customer Facing Service Specification
+
+## Resource Facing Service Specification
+
+Is a Service that It exposes a resource Specification as a Service. (For example expose a Network Service Descriptor as a Service)
+
+## Customer Facing Service Specification
+
+Customer Facing Service Specifications - or also CFSSpec (organized in Service Categories) are exposed to users for Service Orders. Usually it exposes other CFSSpec(as a Service Bundle) or other RFSSpecs
+
+## Definition
+
+Usually a Service Specification has the following aspects:
+
+* Name, Description, Version
+* Marked as a Service Bundle: Combines multiple services into a single offering to provide added value to customers.
+* if is is a Bundle then you must add Related Service Specifications
+* If it is a Resource Facing Service Specification has multiple related Resource Facing Service Specifications
+* Characteristics: a list of service characteristics and their type (TEXT, INTEGER, etc)
+ * Also they can be exposed as "Configurable" so to allow to end-users during the Service Order to select or type values
+* A logo, displayed if needed in the Service Marketplace
+* Any attachments that further help the user
+* Life Cycle Rules that determine the behavior of the Service and instrument the Service Orchestrator. More on Life Cycle Rules [here](./lcm_rules_intro.md)
+
+Service Designers can create a Service Specification from scratch or use some templates:
+
+ * Create a Service based from a Network Service Descriptor (NSD)
+ * Create a Service based on a Kubernetes Operator
+ * Create a Service based on the GSMA GST - Generic Slice Template
+
+## UI management
+
+In the UI this looks like the following.
+
+Through the menu and dedicated forms the administrator can manage the Service Specifications. Various examples in this document will guide you to the usage and the design of the services.
+
+## API exposed
+
+When installing OpenSlice the API endpoints can be browsed at:
+```
+[YOURDOMAIN]/tmf-api/swagger-ui/index.html?urls.primaryName=tmf-api-633-ServiceCatalogManagement-v4.0.0
+```
+
+endpoint examples:
+
+/serviceCatalogManagement/v4/serviceSpecification List or find ServiceSpecification objects
+
+
+
+## Example Use Case
+
+Scenario: A service provider wants to offer a new managed XXXX service to enterprise customers.
+
+ * Service Definition: Create a service specification template for the XXXX service, including specifications for bandwidth, network features, and performance metrics.
+
+
+## Probe further
+
+* Read the model of Service Catalogs in TMF [TMF633 Service Catalog API User Guide v4.0.0](https://www.tmforum.org/resources/specification/tmf633-service-catalog-api-user-guide-v4-0-0/)
+* Check a demo of the API [here](http://portal.openslice.io/tmf-api/swagger-ui/index.html?urls.primaryName=tmf-api-633-ServiceCatalogManagement-v4.0.0)
+* Check a demo of the Service Specifications in Catalog and Categories [here](http://portal.openslice.io) (You need to login - see main guide page)
+* Check the GSMA GST
\ No newline at end of file
diff --git a/doc/naas/so/img01.png b/doc/naas/so/img01.png
new file mode 100644
index 0000000000000000000000000000000000000000..a43930df2be8db5257b4d8e43ff419c9b9837314
Binary files /dev/null and b/doc/naas/so/img01.png differ
diff --git a/doc/naas/so/service_specification_instantiation.png b/doc/naas/so/service_specification_instantiation.png
new file mode 100644
index 0000000000000000000000000000000000000000..4bdaea9b5ac8702a2dfd801d7c85669c8cba8a97
Binary files /dev/null and b/doc/naas/so/service_specification_instantiation.png differ
diff --git a/doc/so_ServiceCreationProcess.pu b/doc/naas/so/so_ServiceCreationProcess.pu
similarity index 100%
rename from doc/so_ServiceCreationProcess.pu
rename to doc/naas/so/so_ServiceCreationProcess.pu
diff --git a/doc/so_activity_main.pu b/doc/naas/so/so_activity_main.pu
similarity index 100%
rename from doc/so_activity_main.pu
rename to doc/naas/so/so_activity_main.pu
diff --git a/doc/naas/so_intro.md b/doc/naas/so_intro.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..1feb632824f72a919b396713f00bf69f51786393 100644
--- a/doc/naas/so_intro.md
+++ b/doc/naas/so_intro.md
@@ -0,0 +1,18 @@
+# Service Orchestration
+
+- Service Orchestration: The orchestration engine evaluates the request, determines the necessary resources, and initiates the automated workflows.It interacts with underlying controller components (e.g. 5G Core, Radios, Containerized controllers, NFV, SDN controllers ) to provision and configure the required network functions and connectivity.
+
+## Intended Audience: Service Designers
+
+OpenSlice end-to-end (E2E) service orchestration framework is designed to manage and automate the entire lifecycle of services across multiple domains and technologies. For delivering, Network as a Service (NaaS) OpenSlice automates and manages the entire lifecycle of network services, from provisioning to monitoring and decommissioning, while ensuring seamless integration, operation, and delivery of services from the initial request to the final delivery, spanning all involved components and layers.
+
+As next image depicts, service orchestrators follow some predefined workflows. OpenSlice end-to-end (E2E) service orchestrator follows some predefined workflows to manage a service lifecycle (They are described in BPMN language and included in our orchestration engine)
+
+[](./so/img01.png)
+
+This section provides a high level overview of the Service Orchestration process.
+
+
+
+
+
diff --git a/doc/naas/so_servicespec_to_services_nfv.md b/doc/naas/so_servicespec_to_services_nfv.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..7ca3911dae86d5bf9b704184d11415fda1dac81f 100644
--- a/doc/naas/so_servicespec_to_services_nfv.md
+++ b/doc/naas/so_servicespec_to_services_nfv.md
@@ -0,0 +1,39 @@
+# From Service Specification to NFV based services
+
+After a Service Order completion, active services with their additional characteristics are found:
+
+* From the Order Items of a selected Service order
+* from the menu of Service inventory and then selecting details of each service
+* through the Service Inventory API (TMF 638 - Service Inventory Management )
+
+
+Openslice creates a Service for the requested CFS. Customers make Service Orders and Openslice instantiates the requested Service Specifications for each Service Order Item of a Service Order. Running Services instantiated by Openslice, reside in Openslice Service Inventory. The following picture displays how Service Specifications are related to Running Services and how Running Services relate with instantiated running Network Services.
+
+
+[](./so/service_specification_instantiation.png)
+
+
+There is a hierarchy of services. Usually an Instantiated CFS has Supporting Services some Instantiated RFSs. Then an Instantiated RFS is related to some running NS managed by NFVO
+
+
+## Interacting with an Active Service (Day 2 config)
+
+In some cases, if the underlying service is configured with actions (for example in OSM Day 2 primitive actions), there are characteristics that can be modified. Usually they are named like : <servicename>::Primitive::<action>
+
+The user can edit the characteristic with a new value. The value is propagated through the OSOM and NFVO down to the related VNF.
+
+## Terminating/Inactivating a service
+
+You can terminate the service with one of the following processes:
+
+* Select the related Service Order and terminate the Order Item. This will delete all the underlying related active services. The Order goes to ACKNOWLEDGED->INPROGRESS->COMPLETE
+* To terminate or inactivate a service, select the specific service from the inventory, press Edit and set the State either to Inactive or Terminated
+
+<b>Warning: if you terminate or inactivate a service the action cannot be undone.</b>
+
+
+## uml: sequence diagram
+Here I will embed PlantUML markup to generate a sequence diagram.
+
+I can include as many plantuml segments as I want in my Markdown, and the diagrams can be of any type supported by PlantUML.
+
diff --git a/doc/architecture/tmfweb.md b/doc/portals_intro.md
similarity index 69%
rename from doc/architecture/tmfweb.md
rename to doc/portals_intro.md
index 729eed65fa1833982885623ca9108e67b44ab20c..30255764d83aaa85c4acd86da79a3cf1691b640c 100644
--- a/doc/architecture/tmfweb.md
+++ b/doc/portals_intro.md
@@ -1,13 +1,13 @@
-# Openslice TMF Web Portal
+# OpenSlice Portals
-Openslice comprises of a [web landing page](http://portal.openslice.io/) that navigates to the respective TMF Portal.
+Openslice comprises of a web landing page [See Demo](http://portal.openslice.io/) that navigates to the respective Portal:
-- [Services Portal](http://portal.openslice.io/services)
-- [Products Portal](http://portal.openslice.io/products)
-- [Testing Portal](http://portal.openslice.io/testing)
-- [Resources Portal](http://portal.openslice.io/resources)
+- Services Portal [See Demo](http://portal.openslice.io/services)
+- NFV Portal [See Demo](http://portal.openslice.io/nfvportal)
+- Products Portal [See Demo](http://portal.openslice.io/products)
+- Testing Portal [See Demo](http://portal.openslice.io/testing)
+- Resources Portal [See Demo](http://portal.openslice.io/resources)
-The landing page and the TMF portals (Services, Products, Testing, Resources) are written in Angular and are maintained under the same Angular project.
Following you may find the scope each portal focuses on and the main TMF APIs it supports.
@@ -15,6 +15,18 @@ Following you may find the scope each portal focuses on and the main TMF APIs it
- Service Designer - To design Customer Facing Services as bundles of Resource Facing Services that map to specific Resourses (e.g. NFV, Testing, General Resources). Then, it is charged with the designed Services' exposure to public Service Catalogs.
- Service Customer - To browse the public Service Catalogs and order the offered Services. The fulfilment process of the Service Order is also captured and the final deployed Services are exposed to the Customer.
+**NFV Portal** is a designated portal for the:
+Indicatively, the portal can be used to:
+- Register new a new MANO provider (e.g. OSM)
+- Synchronize the onboarded VNF/NS packages, and the VIMs of the registered MANO provider
+- Onboard/Delete VNF/NS packages on specific MANO provider
+- Deploy a NS to a target MANO provider
+
+More information can be found at [NFV Services](./naas/nfv/nfvservices.md).
+
+**Resources Portal** is a designated portal for the:
+- Resource Administrator - To view the available Resources that are being synchronized from the underlying infrastructure.
+-
**Products Portal** is a designated portal for the:
- Product Designer - To design Products as bundles of available Services. Then, it is charged with the designed Products' exposure to public Product Catalogs.
- Product Customer - To browse the public Product Catalogs and navigate to the respective offered Services.
@@ -22,9 +34,6 @@ Following you may find the scope each portal focuses on and the main TMF APIs it
**Testing Portal** is a designated portal for the:
- Testing Designer - To design Tests and provide the testing scripts as attachments to the latter. The Tests can be imported as Services at the Services Portal, and can be included in a Service Bundle.
-**Resources Portal** is a designated portal for the:
-- Resource Administrator - To view the available Resources that are being synchronized from the underlying infrastructure.
-
@@ -35,5 +44,4 @@ Following you may find the scope each portal focuses on and the main TMF APIs it
|**Testing Portal** | |x | | | | | | | |x | |
|**Resources Portal** | |x | |x | |x | | | | |x |
-
-From the landing page, the user can also navigate towards the NFV portal. See [NFV WEB](./nfvweb.md).
\ No newline at end of file
+The NFV Portal uses a proprietary API
\ No newline at end of file
diff --git a/doc/role_keycloak_management.md b/doc/role_keycloak_management.md
new file mode 100644
index 0000000000000000000000000000000000000000..153d5c312b3b30b8020097d6dd2a0346446c3e3c
--- /dev/null
+++ b/doc/role_keycloak_management.md
@@ -0,0 +1,11 @@
+# Role management in Keycloak
+
+Some initial configuration of Keycloak happens at Installation/Deployment time. Here are some notes regarding user management
+
+## Intended Audience: OpenSlice administrators
+
+There are cases that OpenSlice administrators need to configure Keycloak:
+
+* Change user roles, e.g. make a Simple user a Service Designer
+* Domain management
+* User Password reset
\ No newline at end of file
diff --git a/doc/catalogs.md b/doc/service_design/catalogs.md
similarity index 69%
rename from doc/catalogs.md
rename to doc/service_design/catalogs.md
index 3b3538d0b5dcaedf1690154bea22e70caf85551b..ebaf24fc0d524ce6729038ae6dadfca2d02752c0 100644
--- a/doc/catalogs.md
+++ b/doc/service_design/catalogs.md
@@ -96,35 +96,6 @@ Openslice offers the GST in a format that is machine readable and aligned with t
Providers can clone a GST as e NEST directly in Openslice Web portal and the adjust the default attributes to their Service Specification
-### 5G-VINNI Service Blueprint
-(Offered only as a design for now. THere is no direct implementation to NFV)
-5G-VINNI Service Blueprint is a special Service Specification defined by teh 5G-VINNI project. Many details can be found in document <https://zenodo.org/record/3345612>
-
-5G-VINNI Service Blueprint is a reusable self-contained specification of required network slice service (instances). As described in GST mapping VINNI-SB is also machine readable.
-
-Here is a tentative approach in JSON : <https://github.com/openslice/org.etsi.osl.tmf.api/tree/master/src/main/resources/vinnisb>
-
-5G-VINNI SB has many commonalities with GST as well as it offers Testing as a Service attributes.
-
- Next figure presents the high-level object model of a 5G-VINNI service blueprint.
-
-The 5G-VINNI SB as a first prototype approach is conceived as a CFS of a ‘bundle’ of services. It has some characteristics, like name, description, service type (eMBB, etc) and others. The constituent services are:
-
-- A “Service Topology†Service Specification which is related to a Network Service Resource topology (a Logical Resource Spec). It is considered at this stage as an RFS but is subject to change in future
-- A “VINNI SB Service Requirements†Service Specification which is related to Service requirements. This is very similar to GST. It is considered at this stage a CFS.
-- A “VINNI SB Service Exposure Level 1†Service Specification which contains characteristics for service exposure on level 1 ( see D3.1 for details). It is considered at this stage a CFS.
-- A “VINNI SB Service Exposure Level 2†Service Specification which contains characteristics for service exposure on level 2. It is considered at this stage a CFS.
-- A “VINNI SB Service Exposure Level 3†Service Specification which contains characteristics for service exposure on level 3. It is considered at this stage a CFS.
-- A “VINNI SB Service Exposure Level 4†Service Specification which contains characteristics for service exposure on level 4. It is considered at this stage a CFS.
-- A “VINNI SB Service 3rd part VNF†Service Specification which contains characteristics for support 3rd party VNFs to be included in the service. It is considered at this stage as an RFS but is subject to change in future
-- A “VINNI SB Service 3rd part NSD†Service Specification which contains characteristics for support 3rd party NSDs to be included in the service. It is considered at this stage as an RFS but is subject to change in future
-- A “VINNI SB Service Monitoring†Service Specification which contains characteristics for offering Monitoring capabilities on the requested Service. It is considered at this stage a CFS.
-- A “VINNI SB Service Testing†Service Specification which contains characteristics for offering Testing capabilities on the requested Service. It is considered at this stage a CFS.
-
-
-[](../images/vinni_sb_model_diagram.png)
-
-
## Manage a Service Specification
You can manage them though the Web UI
@@ -142,6 +113,6 @@ Delete it from the category
## Consume and expose Service Specifications from other Service Catalogues
-See more on [Consuming Services From External Partner Organizations](./architecture/consumingServicesFromExternalPartners.md)
+See more on [Consuming Services From External Partner Organizations]( ../architecture/consumingServicesFromExternalPartners.md )
diff --git a/doc/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md b/doc/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
index f7751d886d941cb7211e78de211d1ca768efc1a9..6d9dd1525590a20b982dee72b212e0d230d5fff5 100644
--- a/doc/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
+++ b/doc/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
@@ -113,11 +113,13 @@ As soon as the CRD is deployed in the cluster (e.g. by your admin via kubctl or
- Having this OpenSlice can manage resources in multiple clusters
-<img src="img07.png" >
+
+
> See also the detailed characteristics. See how OpenSlice makes all characteristics automatically flat and expanded with key-value style
-<img src="img08.png" width=1024px>
+
+
---
# Expose to Users
@@ -127,10 +129,9 @@ As soon as the CRD is deployed in the cluster (e.g. by your admin via kubctl or
From the UI menu create a new Service Specification
+
-<img src="img09.png" width=1024px>
-<img src="img10.png" width=1024px>
-
+
@@ -158,7 +159,8 @@ spec:
```
-<img src="img11.png" width=1024px>
+
+
> However the values are fixed. How do we allow a user to pass parameters through OpenSlice
@@ -174,10 +176,7 @@ Create a new CustomerFacingServiceSpecification
- Add the following characteristics as the image shows:
-<img src="cfs_img12.png" width=1024px>
-
-
-
+
### Allow users to pass new values through OpenSlice
@@ -191,10 +190,14 @@ We need to Create LCM rules in CustomerFacingServiceSpecification:
- we will create one rule that will pass the parameters while the service is active (SUPERVISION phase)
- The rules will be the same
-<img src="img12.png" width=1024px>
+
+
+
If we see one rule it will look like the following:
-<img src="img13.png" width=1024px>
+
+
+
- We need to change the _CR_SPEC characteristic of the referenced ResourceFacingServiceSpecification
- First bring a block from Service>Relationships>Service Refs and drop the "Service MyCalculatorRFS" block
@@ -220,22 +223,25 @@ If we see the SUPERVISION rule it will look like the following:
- Add as name the "status.result"
-<img src="img13_1.png" width=1024px>
+
+
+
+
-<img src="img14.png" width=1024px>
Expose it then to a catalogue for orders through the Service Categories and Service Catalogs
-<img src="img15.png">
+
+
### Order the Service
When a user orders the service, it will look like this:
-<img src="img16.png" width=1024px>
+
@@ -244,20 +250,22 @@ When a user orders the service, it will look like this:
- The Actual resources are running in the Kubernetes cluster managed by OpenSlice
- The result is in the characteristic status.result of the running service
-<img src="img17.png" width=800px>
-<img src="img18.png" width=1024px>
+
+
+
+
### Modify the running service
The user can modify the service
-<img src="img19.png" width=1024px>
+ 
+
+
- After a while the update is applied to the cluster, the controller will pick up the resource update and patch the resource
- OpenSlice (via CRIDGE service) updates the Resource in Resource Inventory and OSOM updates the Services in Service Inventory
- The result will be available to the respective characteristic "Result" after a few seconds, as need to go through various steps (OpenSlice orchestrator, down to kubernetes, to Calculator controller and back)
-
-<img src="img20.png" width=1024px>
-
\ No newline at end of file
+ 
\ No newline at end of file
diff --git a/doc/service_design/kubernetes/design_helmaas.md b/doc/service_design/examples/intro.md
similarity index 100%
rename from doc/service_design/kubernetes/design_helmaas.md
rename to doc/service_design/examples/intro.md
diff --git a/doc/service_design/intro.md b/doc/service_design/intro.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..b52ebe9afea788435070bb07e7ec2c68173e9586 100644
--- a/doc/service_design/intro.md
+++ b/doc/service_design/intro.md
@@ -0,0 +1,18 @@
+# Service Design in OpenSlice
+
+This section offers details on how to design Service Specifications and expose them in Service Catalogs
+
+## Intended Audience: Service Designers
+
+Service Designers create detailed service specifications, which are then managed and exposed in service catalogs. These services are integrated into OpenSlice E2E service orchestration framework to automate and optimize the delivery of network services.
+
+
+OpenSlice can be used to design service specifications for various services, even not networking related services. Here we cover how service designers can expose services related to the NFV world and the containerized world.
+
+## Probe further
+
+* [Design and expose services based on containerized resources via the Kubernetes Operator pattern](ExposingKubernetesResources.md)
+* [Design and expose services based on NFV artifacts](./nfv/design_nfv_services.md)
+
+
+
diff --git a/doc/service_design/kubernetes/ExposingKubernetesResources.md b/doc/service_design/kubernetes/ExposingKubernetesResources.md
index 0a64cdd9d89ed6f246166081133c290a06780d30..ade87388eb2de2f30ab269624f72f2b264040071 100644
--- a/doc/service_design/kubernetes/ExposingKubernetesResources.md
+++ b/doc/service_design/kubernetes/ExposingKubernetesResources.md
@@ -34,7 +34,8 @@ OpenSlice is capable of exposing Kubernetes Resources and Definitions as Service
The following image illustrates the approach.
-<img src="img01.png" width=1024px>
+
+
1. A CRD in a cluster will be mapped in TMF model as a Resource specification and therefore can be exposed as a service specification in a catalog
2. Service Orders can be created for this service specification.
@@ -116,8 +117,7 @@ The following specific characteristics are **added**:
2.3. You Expose configurable values for users to configure during service order
-<img src="img06.png" width=1024px>
-
+
# Service Orchestration and CRDs/CRs
@@ -156,7 +156,7 @@ OpenSlice adds automatically as we see the following characteristics:
---
-## What's next?
+## Probe further
- See examples of exposing operators via OpenSlice:
diff --git a/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md b/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md
index ca1995192974c6b7bd2f14da7d954b6f9ab9de7d..2a865e1ec32b362e6c75b46a12c67729292732be 100644
--- a/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md
+++ b/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md
@@ -1,92 +1,38 @@
-# Expose HELM charts as Service Specifications
-Manage Helm charts installations via OpenSlice Service Specifications and Service Orders.
-## Intended Audience: Service Designers
-
-
-> Kubernetes is an orchestration system for automating software deployment, scaling, and management. One can interact though the Kubernetes API and it has a set of objects ready for use out of the box.
-
-> Helm is a tool that automates the creation, packaging, configuration, and deployment of Kubernetes applications by combining your configuration files into a single reusable package
-
-> At the heart of Helm is the packaging format called charts. Each chart comprises one or more Kubernetes manifests -- and a given chart can have child charts and dependent charts, as well. Using Helm charts:
-
-> - Reduces the complexity of deploying Microservices
-> - Enhances deployment speed
-> - Developers already know the technology
-
-> There are many Helm charts and Helm repositories there that are ready to be used
-
-> Enable loose coupling and more orchestration scenarios
-
-> Developers create and deploy applications in things they already know (e.g. Helm charts)
-
-> Use the TMF models as wrapper entities around Helm charts
-
-
-Use OpenSlice to expose them in service catalogs and deploy them in complex scenarios (service bundles) involving also other systems:
-
- - Include e.g. RAN controllers,
- - Pass values through life cycle rules from one service to another,
- - Manage multiple Helms in multiple clusters
-
-
-## The installation of HELM charts is based on OpenSlice CRD support
-
-Please read more [here](../ExposingKubernetesResources.md)
-
-
-For installing HELM charts we will use ArgoCD a well known Kubernetes-native continuous deployment (CD) tool
-
-> ArgoCD is a Kubernetes-native continuous deployment (CD) tool
-
-> While just deploying Heml charts is just a scenario for ArgoCD , in future one can exploit it for many things
-
-> Despite some other tools like FluxCD, it provides also a UI which is useful for management and troubleshooting
-
-
-We will mainly use the CRD of ```Kind: Application``` that ArgoCD can manage
-
-
-
-Before proceeding, install ArgoCD in your management cluster, by following ArgoCD instructions
-
-As soon as you install ArgoCD, OpenSlice is automatically aware for specific new Kinds. The one we will use is is the ```Kind: Application``` that ArgoCD can manage under the apiGroup argoproj.io
-
-Browse to Resource Specifications. You will see an entry like the following:
-
-```Application@argoproj.io/v1alpha1@kubernetes@https://10.10.10.144:6443/```
+# Example: Offer Jenkins as a Service via Openslice
-see image:
+## Design the Jenkins (Resource-Facing) Service
-<img src="img01.png" width=1024px>
-
-# Example: Offer Jenkins as a Service via Openslice
+Before reading this example please make sure that you went through the [Design Helm as a Service](../design_helmaas.md)
-We will use the ```Kind: Application``` of ArgoCD and create a ResourceFacingServiceSpecification for Jenkins
+In this example, we will use the ```Kind: Application``` of ArgoCD and create a ResourceFacingServiceSpecification (RFSS) for Jenkins. Eventually, we will offer Jenkins as a Service.
1. Go to Service Specifications
2. Create New Specification
- 3. Give a Name, eg. jenkinsrfs
+ 3. Provide a Name, eg. jenkinsrfs
4. Go to Resource Specification Relationships
- 5. Assign ```Application@argoproj.io/v1alpha1@kubernetes@https://10.10.10.144:6443/```
+ 5. Assign **Application@argoproj.io/v1alpha1@kubernetes@https://10.10.10.144:6443/** as a related Resource Specification
-<img src="img02.png" width=640px>
+> Please note that the *https://10.10.10.144:6443/* part of the Resource Specification's name will vary in different Kubernetes environments.
-Focus now on the characteristics configuration.
+
-First we need to map the lifecycle of ArgoCD Application to TMF Resource State
+Now, we shall focus on the Characteristics' configuration of the created Service Specification. This can be achieved from the the "Service Specification Characteristics" tab.
+Specifically, we need to map the lifecycle of ArgoCD Application (e.g. Progressing, Healthy, etc.) to TMF Resource State (e.g. reserved, active, etc.).
-<img src="img05.png" width=640px>
+In ArgoCD, the field **status.health.status** has the value that we need to check (Healty, Progressing, etc) for the lifecycle of the application. This is captured by the **_CR_CHECK_FIELD** characteristic.
-In ArgoCD the field **health.status** has the value that we need to check (Healty, Progressing, etc)
-
-
-The _CR_SPEC can be designed first in a YAML or json editor. Let's see a YAML definition:
+Also, the different ArgoCD lifycycle states must be captured by the respective **_CR_CHECKVAL_xxx** characteristics, as show in the figure below:
+
+
- ```
+After the state mapping, we must provide the template that ArgoCD will use to deploy the Jenkins HELM Chart as an ArgoCD application. For this, we must populate the **_CR_SPEC** characteristic. The _CR_SPEC can be designed first in a YAML or json editor for better parsing.
+Let's see a YAML definition:
+
+```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
@@ -101,13 +47,14 @@ spec:
name: in-cluster
source:
repoURL: https://charts.jenkins.io
- targetRevision: 4.6.1
+ targetRevision: 5.3.6
chart: jenkins
helm:
values: |
controller:
- service:
- type: ClusterIP
+ serviceType: ClusterIP
+ persistence:
+ enabled: false
syncPolicy:
automated:
prune: true
@@ -120,77 +67,104 @@ spec:
- PruneLast=true
- RespectIgnoreDifferences=true
```
-
-**NOTICE**
-
-On each installation OSOM will change the name of the resource in order to be unique (will have a UUID)
+> **NOTE 1**: The above template assumes that the Jenkins Server will acquire a **ClusterIP**. The user should handle the external exposure and access of the Jenkins Server, depending on its cluster configuration. Also, **persistency of the data is disabled** to facilitate the deployment without the need to define storage classes and volumes, as this serves as an example.
+
+```yaml
+helm:
+ values: |
+ controller:
+ serviceType: ClusterIP
+ persistence:
+ enabled: false
+```
- ```name: openslice-jenkins```
+> **NOTE 2**: On each installation, OSOM will change the name of the resource in order to be unique (will have a UUID), instead of "openslice-jenkins".
- destination namespace that ArgoCD will use is the name ```opencrdtest```
+```yaml
+name: openslice-jenkins
+```
- ```destination:
- namespace: opencrdtest
- ```
+> **NOTE 3**: The namespace that ArgoCD will use to deploy the Jenkins HELM Chart is the "opencrdtest".
-**This implies that ArgoCD installs the Jenkins always in the same namespace**
+```yaml
+destination:
+ namespace: opencrdtest
+```
-**To avoid this we will create a simple pre-provision rule to change the namespace properly**
+**The latter implies that ArgoCD will always install Jenkins in the same namespace.**
-See the following image:
-<img src="img06.png" >
-
-1. Drag-Drop the _CR_SPEC characteristic of jenkinsrfs from the Service>Text blocks
-2. Drag-Drop Text>Formatted text block
-3. Drag-Drop Text>Multi-line text input block
-4. Copy paste the YAML text
-5. Change the spec: destination:namespace to the value %s
-6. Drag-Drop Lists>Create list with block delete 2 items (click the gear icon). Connect it to formatted text block
-7. Drag-Drop Context>Current Service Order block and select the id. Connect it to the List
+**To avoid this we will create a simple LCM rule (pre-provision) to change the namespace accordingly with a unique ID, generated with every new Service Order.**
+
+The LCM rule can be created from the "Life Cycle Rules" tab, pressing the "Create new rule" button. The following image contains the LCM rule that needs to be created for this purpose:
+
+
+
+
+
+Let's create it step-by-step:
+
+1. Drag-Drop the _CR_SPEC block (Set characteristic value) of jenkinsrfs from the Service > Text blocks
+2. Drag-Drop the Text > Formatted text block and attach it after the block from the previous step
+3. Drag-Drop the Text > Multi-line text input block and attach it at the Input(String) connector of the block from the previous text
+4. Copy paste the previously provided YAML text
+5. Change the spec:destination:namespace property to the value %s
+6. Drag-Drop the Lists > Create list block, delete the 2 extra items (click the gear icon). Attach it at the Variables(Array) connector of the formatted text block from the previous step.
+7. Drag-Drop the Service > Context > Current Service Order block and select the ID from the drop-down menu. Attach it to the List block of the previous step.
8. Save the PRE_PROVISION Rule
-# Expose the service to your users
+## Expose the Jenkins (Customer-Facing) Service to the users
+
+To expose a service towards the users, the designer must create the respective CustomerFacingServiceSpecification, by using the previously designed RFSS as a related service.
-Expose then as CustomerFacingServiceSpecification by using the previous RFSS as Service Specification Relationship
-1. Create a Jenkins service and mark as Bundle and save it
-2. Go to Service Specification Relationships and assign Jenkinsrfs
-3. Add also a Logo if you wish
+1. Go to Service Specifications
+2. Create New Specification
+3. Create a Jenkins service, mark as Bundle (to enable Service Specification Relationships) and save it
+4. Go to the "Service Specification Relationships" tab and assign Jenkinsrfs
+5. (Optionally) Add a logo, from the respective "Logo" tab, if you wish
+
+
+
+
-<img src="img03.png" width=640px>
-<img src="img04.png" width=640px>
-Expose it now to a Category and a Catalog to be available for ordering.
+Next, the designer must expose it through an already created Service Catalog and Service Category so as to make it visible to the users, thus available for ordering.
-<img src="img061.png" >
+
+
+
+
+
+## Order the Jenkins Service
-# Order the service
+Order the service from the previously assigned Service Catalog > Service Category.
-Order the service from the catalog.
+As soon as the Service Order is in **ACKNOWLEDGED** state (may require user intervention as the initial Service Order state is "INITIAL"), it will be processed and eventually completed rendering the services active, as seen in the figure below:
-Soon the order will be completed and the Services will be active
+
+## Access the Jenkins installation
-<img src="img07.png" width=640px>
+Starting from the Service Order overview and specifically the Order Item #1 tab > Supporting Services, select the ResourceFacingService (jenkinsrfs).
-# How to access the Jenkins installation:
+Accordingly, the ResourceFacingService has supporting resources from the resource inventory. The latter are available through the "Supporting Resources" tab.
-From the Supporting services of the Service Order, select the ResourceFacingService (jenkinsrfs)
-The ResourceFacingService has also supporting resources in resource inventory.
+
-<img src="img08.png" width=640px>
+The supporting resources of the Jenkins service are:
-One is the resource reference to the application (e.g. _cr_tmpname_...), the other is a secret (e.g. cr87893...).
+- A resource reference to the application (e.g. _cr_tmpname_...)
+- A secret resource (e.g. cr87893...).
-Click to go to the secret resource (This is in the Resource inventory of OpenSlice)
+Select the secret resource, which will navigate you to the Resource Inventory page of OpenSlice. There, you may find the login credentials encoded as Base64.
-<img src="img09.png" width=640px>
+
-Use them to login in your Jenkins.
+Use a Base64 decoder to parse the credentials and use them to login in your Jenkins installation, through the exposed Jenkis Server UI.
-> Exposing Jenkins to you external is a matter of cluster configuration and request (nodeport, load balancing, etc)! This is not a topic for this example
+> Exposing Jenkins externally is a matter of cluster configuration and request (nodeport, load balancing, etc), thus is not a topic for this example
diff --git a/doc/service_design/kubernetes/helm/design_helmaas.md b/doc/service_design/kubernetes/helm/design_helmaas.md
new file mode 100644
index 0000000000000000000000000000000000000000..411910eacb6a72b489a9cad5a0a9e7e40248a9de
--- /dev/null
+++ b/doc/service_design/kubernetes/helm/design_helmaas.md
@@ -0,0 +1,67 @@
+# Expose HELM charts as Service Specifications
+Manage Helm charts installations via OpenSlice Service Specifications and Service Orders.
+## Intended Audience: Service Designers
+
+
+> Kubernetes is an orchestration system for automating software deployment, scaling, and management. One can interact though the Kubernetes API and it has a set of objects ready for use out of the box.
+
+> Helm is a tool that automates the creation, packaging, configuration, and deployment of Kubernetes applications by combining your configuration files into a single reusable package
+
+> At the heart of Helm is the packaging format called charts. Each chart comprises one or more Kubernetes manifests -- and a given chart can have child charts and dependent charts, as well. Using Helm charts:
+
+> - Reduces the complexity of deploying Microservices
+> - Enhances deployment speed
+> - Developers already know the technology
+
+> There are many Helm charts and Helm repositories there that are ready to be used
+
+> Enable loose coupling and more orchestration scenarios
+
+> Developers create and deploy applications in things they already know (e.g. Helm charts)
+
+> Use the TMF models as wrapper entities around Helm charts
+
+
+Use OpenSlice to expose them in service catalogs and deploy them in complex scenarios (service bundles) involving also other systems:
+
+ - Include e.g. RAN controllers,
+ - Pass values through life cycle rules from one service to another,
+ - Manage multiple Helms in multiple clusters
+
+
+## The installation of HELM charts is based on OpenSlice CRD support
+
+Please read more [here](../ExposingKubernetesResources.md)
+
+
+For installing HELM charts we will use ArgoCD a well known Kubernetes-native continuous deployment (CD) tool
+
+> ArgoCD is a Kubernetes-native continuous deployment (CD) tool
+
+> While just deploying Heml charts is just a scenario for ArgoCD , in future one can exploit it for many things
+
+> Despite some other tools like FluxCD, it provides also a UI which is useful for management and troubleshooting
+
+
+We will mainly use the CRD of ```Kind: Application``` that ArgoCD can manage
+
+
+
+Before proceeding, install ArgoCD in your management cluster, by following ArgoCD instructions
+
+As soon as you install ArgoCD, OpenSlice is automatically aware for specific new Kinds. The one we will use is is the ```Kind: Application``` that ArgoCD can manage under the apiGroup argoproj.io
+
+Browse to Resource Specifications. You will see an entry like the following:
+
+```Application@argoproj.io/v1alpha1@kubernetes@https://10.10.10.144:6443/```
+
+see image:
+
+
+
+
+
+## What's next
+
+
+See the [Example: Offer Jenkins as a Service via Openslice](HELM_Installation_aaS_Jenkins_Example.md)
diff --git a/doc/service_design/kubernetes/intro.md b/doc/service_design/kubernetes/intro.md
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..8fad353e29bd24d4024b51c016caadb056f12b86 100644
--- a/doc/service_design/kubernetes/intro.md
+++ b/doc/service_design/kubernetes/intro.md
@@ -0,0 +1,3 @@
+# OpenSlice and support for kubernetes
+
+This section contains information on how Service Designers can expose Kubernetes resources as services
\ No newline at end of file
diff --git a/doc/service_design/lcmrules/examples.md b/doc/service_design/lcmrules/examples.md
new file mode 100644
index 0000000000000000000000000000000000000000..52065b0742c5cd841f154b145ce2582baa3fd897
--- /dev/null
+++ b/doc/service_design/lcmrules/examples.md
@@ -0,0 +1,79 @@
+# Examples of Rules
+
+
+The following images provide some examples of rules.
+
+### Define variables according to cases
+
+In the following example we :
+
+* define a String variable.
+* Then according to the Area of Service selected from the Service Order of the Service Specification we need to define it properly.
+* We output the value to the OSOM Log
+* Define dynamically the value of another parameter (This is fictional) and then do some other condition check
+
+The strAreaCodes could be passed then e.g. to NFVO for instantiation of services to these cells.
+
+
+[](./images/lcm/lcmfig9.png)
+
+
+
+
+### Define Rules to create a resource for a Kubernetes Operator
+
+* Modify the _CR_SPEC characteristic
+* Add an "Input with variables block"
+* Add a multiline Text block
+* Mark with %s, %d, etc the parameters to modify with some action
+* Add a list with the variables and their values
+
+in the example we modify a YAML spec with parama, paramb, action values from the characteristics spec.parama, spec.paramb, spec.action
+
+[](./images/lcm/lcmfig15.png)
+
+
+### Define complex OSM configs for DAY 0
+
+The following displays some complex examples for defining the parameters to pass to the NFV. In this case is OSM.
+
+* NOTE: The OSM_CONFIG characteristic of a service is the one that it is used in orchestration to instantiate NS from OSM
+
+* check the variable strTargetsParam. It is passed to the variable strOsmConfig3 which is executed if the Number of Cameras is more than 100.
+* if the Video quality requested is 3, then the Maximum Namber of camers will be 8. Check the OSM detailed configuration block and its syntax.
+* if the Video quality requested is 2, we use a simpler OSM Config block to configure the parameter OSM_CONFIG. We just injected a json text ( watch the Escape of the string for the Quotes!)
+* if the Video quality requested is 1, again we use a simpler OSM Config block to configure the parameter OSM_CONFIG. We use as injected json text a variable constructed later
+
+
+[](./images/lcm/lcmfig10.png)
+
+
+### Define and instantiate different services according to Service Order request
+
+In the following example we would like to offer a service either as Platinum, Gold or Silver. Depending on the selection we need to instantiate different services.
+
+There are different ways to accomplish this:
+
+* create dynamically New Service Orders of RFSs with equivalent quality of Services
+* change for example the VIMs that you deploy the NS
+* change the NSD (that is use different VNFs)
+
+The following image displays for example the latter case.
+
+[](./images/lcm/lcmfig11.png)
+
+
+### Call an external RESTful service
+
+This is useful in cases for example of alarms , external logging, calling other services e.g. email or even a complex algorithm written in other language e.g. call an external service and get a result. (service e.g. a Python service)
+
+
+[](./images/lcm/lcmfig12.png)
+
+[](./images/lcm/lcmfig13.png)
+
+### Create New Service Orders
+
+The following example calls to Order a New Service Specification with specific Parameter Values
+
+[](./images/lcm/lcmfig14.png)
\ No newline at end of file
diff --git a/doc/images/lcm/lcmfig1.png b/doc/service_design/lcmrules/images/lcm/lcmfig1.png
similarity index 100%
rename from doc/images/lcm/lcmfig1.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig1.png
diff --git a/doc/images/lcm/lcmfig10.png b/doc/service_design/lcmrules/images/lcm/lcmfig10.png
similarity index 100%
rename from doc/images/lcm/lcmfig10.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig10.png
diff --git a/doc/images/lcm/lcmfig11.png b/doc/service_design/lcmrules/images/lcm/lcmfig11.png
similarity index 100%
rename from doc/images/lcm/lcmfig11.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig11.png
diff --git a/doc/images/lcm/lcmfig12.png b/doc/service_design/lcmrules/images/lcm/lcmfig12.png
similarity index 100%
rename from doc/images/lcm/lcmfig12.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig12.png
diff --git a/doc/images/lcm/lcmfig13.png b/doc/service_design/lcmrules/images/lcm/lcmfig13.png
similarity index 100%
rename from doc/images/lcm/lcmfig13.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig13.png
diff --git a/doc/images/lcm/lcmfig14.png b/doc/service_design/lcmrules/images/lcm/lcmfig14.png
similarity index 100%
rename from doc/images/lcm/lcmfig14.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig14.png
diff --git a/doc/service_design/lcmrules/images/lcm/lcmfig15.png b/doc/service_design/lcmrules/images/lcm/lcmfig15.png
new file mode 100644
index 0000000000000000000000000000000000000000..0005c110adce2a14ba143ee54b46e948d4f81c19
Binary files /dev/null and b/doc/service_design/lcmrules/images/lcm/lcmfig15.png differ
diff --git a/doc/images/lcm/lcmfig1_osom.png b/doc/service_design/lcmrules/images/lcm/lcmfig1_osom.png
similarity index 100%
rename from doc/images/lcm/lcmfig1_osom.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig1_osom.png
diff --git a/doc/images/lcm/lcmfig2.png b/doc/service_design/lcmrules/images/lcm/lcmfig2.png
similarity index 100%
rename from doc/images/lcm/lcmfig2.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig2.png
diff --git a/doc/images/lcm/lcmfig3.png b/doc/service_design/lcmrules/images/lcm/lcmfig3.png
similarity index 100%
rename from doc/images/lcm/lcmfig3.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig3.png
diff --git a/doc/images/lcm/lcmfig4.png b/doc/service_design/lcmrules/images/lcm/lcmfig4.png
similarity index 100%
rename from doc/images/lcm/lcmfig4.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig4.png
diff --git a/doc/images/lcm/lcmfig5.png b/doc/service_design/lcmrules/images/lcm/lcmfig5.png
similarity index 100%
rename from doc/images/lcm/lcmfig5.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig5.png
diff --git a/doc/images/lcm/lcmfig6.png b/doc/service_design/lcmrules/images/lcm/lcmfig6.png
similarity index 100%
rename from doc/images/lcm/lcmfig6.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig6.png
diff --git a/doc/images/lcm/lcmfig7.png b/doc/service_design/lcmrules/images/lcm/lcmfig7.png
similarity index 100%
rename from doc/images/lcm/lcmfig7.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig7.png
diff --git a/doc/images/lcm/lcmfig8.png b/doc/service_design/lcmrules/images/lcm/lcmfig8.png
similarity index 100%
rename from doc/images/lcm/lcmfig8.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig8.png
diff --git a/doc/images/lcm/lcmfig9.png b/doc/service_design/lcmrules/images/lcm/lcmfig9.png
similarity index 100%
rename from doc/images/lcm/lcmfig9.png
rename to doc/service_design/lcmrules/images/lcm/lcmfig9.png
diff --git a/doc/service_design/lcmrules/intro.md b/doc/service_design/lcmrules/intro.md
new file mode 100644
index 0000000000000000000000000000000000000000..651f83c8b5526a6775c09e1d1d4ca2f4a5727c17
--- /dev/null
+++ b/doc/service_design/lcmrules/intro.md
@@ -0,0 +1,99 @@
+# LCM Rules introduction
+
+
+Lifecycle Management Rules: Defining complex conditions and actions during the lifecycle of a service and any necessary modifications throughout the service lifecycle.
+
+
+## Intended Audience: Service Designers
+
+In [Naas LCM Introduction](../../naas/lcm_intro.md) it was presented briefly the LCM Rules concept.
+
+This section goes deeply on how Service Designers can use them.
+
+
+
+LCM Rules are used for defining complex conditions and actions during the lifecycle of a service. In Openslice there are four types of rules defined:
+
+* PRE_PROVISION
+* CREATION
+* AFTER_ACTIVATION
+* SUPERVISION
+* AFTER_DEACTIVATION
+
+
+The following figure displays the different phases that the rules are performed, during the lifecycle of a Network Slice Instance.
+
+[](./images/lcm/lcmfig1.png)
+
+* PRE_PROVISION rules: Run only once just before creating a service with a given priority.
+* CREATION rules: Run while the referenced service dependencies of a service are created
+* AFTER_ACTIVATION rules: Run only once just after a service get the ACTIVE state
+* SUPERVISION rules: Run when a characteristic of a service is changed and the service is in the ACTIVE state
+* AFTER_DEACTIVATION rules: Run only once just after a service get the INACTIVE/TERMINATED state
+
+In general the rules allow to perform many actions during service LCM. Thes are some examples:
+
+* Modify service specification parameters before the instantiation of a service (or during operation) based on other dependencies. These parameters might be part of other services already included in Service order
+* Translate GST/NEST parameter values to other values passed later to NFVO for instantiation or control
+* Define complex OSM Configs based on other dependencies and passing variables
+* Define any dependencies when creating the referenced services
+* Dynamically include new service dependencies
+* Create new service orders so include dynamically other services
+* Call external (RESTful) services (via http(s), define payload, examine response)
+
+
+
+
+## Examine if the rules are executed successfully
+
+Rules are transformed automatically to executable code (currently is Java). If a rule is performed successfully or has any issues (e.g. unexpected syntax errors or exceptions) appear in OSOM logfiles and also tey are attached as Notes to the running Service.
+
+## LCM Rules and OSOM Service Orchestration
+
+OSOM is the responsible service for executing the rules on a specific phase. The following image explains the design in the BPMN phases:
+
+
+[](./images/lcm/lcmfig1_osom.png)
+
+
+
+## Define rules
+
+Rules are defined when designing a Service Spec. Here is an example of a list of rules:
+
+
+[](./images/lcm/lcmfig2.png)
+
+Execution order of rules on a specific phase is random
+
+* NOTE: There is a priority field. The lower the number the highest the priority of rule execution. For example Rule with priority 0 will run before rule with priority 1.
+
+
+### Definition language
+
+* The visual language that Openslice used is based on Google's Blockly (see https://developers.google.com/blockly)
+* The blockly graph is automatically translated to Java internally and then dynamically executed during orchestration phases.
+
+The following figure is an example of such a rule design. The rule for example will run in PRE_PROVISION phase:
+
+[](./images/lcm/lcmfig3.png)
+
+* The goal of the above rule is to properly define a variable AreaCodes given the chosen AreaOfService from a Service Order.
+* On the right side the user can define some rule properties or observe the underlying generated java code.
+
+
+## The blocks library
+
+See our [LCM Blocks specification](./specification.md)
+
+
+
+
+## Probe further
+
+* Check our [examples](../examples/intro.md) for more usages
+* See next the complete [specification](./specification.md)
+
+
+
+
diff --git a/doc/lcmrules_main.pu b/doc/service_design/lcmrules/lcmrules_main.pu
similarity index 100%
rename from doc/lcmrules_main.pu
rename to doc/service_design/lcmrules/lcmrules_main.pu
diff --git a/doc/service_design/lcmrules/specification.md b/doc/service_design/lcmrules/specification.md
new file mode 100644
index 0000000000000000000000000000000000000000..b89323f14dbf1551c403df86a7b38efb0e0cbb3c
--- /dev/null
+++ b/doc/service_design/lcmrules/specification.md
@@ -0,0 +1,17 @@
+
+# LCM Blocks specification
+
+
+## Intended Audience: Service Designers
+
+The following images describe some blocks found in the library.
+
+Blockly has syntax rules. It helps with colours to define them.
+
+So for example a parameter that is a Number cannot be "glued" with a String. Will need some conversion first
+
+[](./images/lcm/lcmfig4.png)
+[](./images/lcm/lcmfig5.png)
+[](./images/lcm/lcmfig6.png)
+[](./images/lcm/lcmfig7.png)
+[](./images/lcm/lcmfig8.png)
diff --git a/doc/service_design_intro.md b/doc/service_design/nfv/design_nfv_services.md
similarity index 100%
rename from doc/service_design_intro.md
rename to doc/service_design/nfv/design_nfv_services.md
diff --git a/doc/service_inventory.md b/doc/service_inventory.md
deleted file mode 100644
index 480b92f111424c67ab3b4efbba089f4339ddb732..0000000000000000000000000000000000000000
--- a/doc/service_inventory.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Service Inventory
-
-After a Service Order completion, active services with their additional characteristics are found:
-
-* From the Order Items of a selected Service order
-* from the menu of Service inventory and then selecting details of each service
-* through the Service Inventory API (TMF 638 - Service Inventory Management )
-
-
-Openslice creates a Service for the requested CFS. Customers make Service Orders and Openslice instantiates the requested Service Specifications for each Service Order Item of a Service Order. Running Services instantiated by Openslice, reside in Openslice Service Inventory. The following picture displays how Service Specifications are related to Running Services and how Running Services relate with instantiated running Network Services.
-
-
-[](./images/service_specification_instantiation.png)
-
-
-There is a hierarchy of services. Usually an Instantiated CFS has Supporting Services some Instantiated RFSs. Then an Instantiated RFS is related to some running NS managed by NFVO
-
-
-## Interacting with an Active Service (Day 2 config)
-
-In some cases, if the underlying service is configured with actions (for example in OSM Day 2 primitive actions), there are characteristics that can be modified. Usually they are named like : <servicename>::Primitive::<action>
-
-The user can edit the characteristic with a new value. The value is propagated through the OSOM and NFVO down to the related VNF.
-
-## Terminating/Inactivating a service
-
-You can terminate the service with one of the following processes:
-
-* Select the related Service Order and terminate the Order Item. This will delete all the underlying related active services. The Order goes to ACKNOWLEDGED->INPROGRESS->COMPLETE
-* To terminate or inactivate a service, select the specific service from the inventory, press Edit and set the State either to Inactive or Terminated
-
-<b>Warning: if you terminate or inactivate a service the action cannot be undone.</b>
-
-
-## uml: sequence diagram
-Here I will embed PlantUML markup to generate a sequence diagram.
-
-I can include as many plantuml segments as I want in my Markdown, and the diagrams can be of any type supported by PlantUML.
-
diff --git a/doc/service_ordering/ordering_services.md b/doc/service_ordering/ordering_services.md
new file mode 100644
index 0000000000000000000000000000000000000000..2a09db075750dad7578c54b52261c32085cc50b4
--- /dev/null
+++ b/doc/service_ordering/ordering_services.md
@@ -0,0 +1,3 @@
+# Service Ordering
+
+## Intended Audience: Users
\ No newline at end of file
diff --git a/doc/terminology.md b/doc/terminology.md
index 5e1e9de1ca90d87023907dabc4650f4ec00a056f..c021048c7d57bf77db58d6dee32b0a4f348f44f9 100644
--- a/doc/terminology.md
+++ b/doc/terminology.md
@@ -1,3 +1,17 @@
-OpenSlice management cluster
-OpenSlice administrator
-Service Designer
\ No newline at end of file
+# User Roles
+
+* User
+* Service Designer
+* OpenSlice administrator
+
+
+# Terms
+
+* Resource Facing Service Specification (RFSSpec): A Service that exposes a resource Specification as a Service.
+* Customer Facing Service Specification (CFSSpec): Service exposed to users for Service Orders. Usually it exposes other CFSSpec(Service Bundle) or other RFSSpecs
+* OpenSlice management cluster
+* Service Specification: Detailed descriptions of services, including attributes, configurations, performance metrics, and SLAs.
+* Service Catalog
+* Service Categories
+* Service Inventory
+
diff --git a/mkdocs.yml b/mkdocs.yml
index 276f80f99811ccc4334637fcb0e6b6aba49950c9..3774374e87e2f45fd30ca44aaf05c80beda97045 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -49,7 +49,7 @@ theme:
repo: fontawesome/brands/gitlab
# Copyright
-copyright: "Copyright © 2019-2024 Openslice Project"
+copyright: "Copyright © 2024 ETSI OSL"
# Options
extra:
@@ -79,6 +79,8 @@ nav:
- Introduction: deployment.md
- Docker Compose: deploymentCompose.md
- Kubernetes: deploymentK8s.md
+ - Portals:
+ - Introduction: portals_intro.md
- Configuration/Management:
- Introduction: config_intro.md
- Role/Keycloak management: role_keycloak_management.md
@@ -88,13 +90,14 @@ nav:
- NaaS:
- Introduction: ./naas/introduction.md
- Services:
- - Service Specification: ./naas/service_spec.md
- Service Catalogs: ./naas/service_catalog.md
+ - Service Specification: ./naas/service_spec.md
+ - Service Ordering: ./naas/service_ordering.md
- Service Inventory: ./naas/service_inventory.md
- GSMA GST to TMF Service: ./naas/gst_to_tmf.md
- Resources:
- - Resources Specification: ./naas/resource_spec.md
- Resources Catalogs: ./naas/resource_catalog.md
+ - Resources Specification: ./naas/resource_spec.md
- Resources Inventory: ./naas/resource_inventory.md
- Service orchestration:
- Introduction: ./naas/so_intro.md
@@ -106,13 +109,14 @@ nav:
- Supported TMFORUM exposed APIs: ./naas/exposed_apis.md
- NFV support:
- Introduction: ./naas/nfv/intro.md
- - NFV Catalogs: ./naas/nfv/nfvcatalogs.md
+ - NFV Services: ./naas/nfv/nfvservices.md
- Service design:
- Introduction: ./service_design/intro.md
+ - Catalogs: ./service_design/catalogs.md
- Support for Kubernetes:
- Introduction: ./service_design/kubernetes/intro.md
- Exposing Kubernetes Resources: ./service_design/kubernetes/ExposingKubernetesResources.md
- - Design Helm aaService: ./service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md
+ - Design Helm as a Service: ./service_design/kubernetes/helm/design_helmaas.md
- Support for NFV:
- Design NFV Services: ./service_design/nfv/design_nfv_services.md
- LCM Rules:
@@ -120,10 +124,11 @@ nav:
- Specification: ./service_design/lcmrules/specification.md
- Typical Examples: ./service_design/lcmrules/examples.md
- Service Specification Examples:
+ - Introduction: ./service_design/examples/intro.md
- Open5GS (NFV approach): ./service_design/examples/open5gs_nfv.md
- Open5GS (Kubernetes approach): ./service_design/examples/open5gs_kubernetes.md
- Exposing CRDs_aaS_Example_Calculator: ./service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
- - HELM Installation aaS Jenkins Example: ./service_design/examples/HELM_Installation_aaS_Jenkins_Example.md
+ - HELM Installation aaS Jenkins Example: ./service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md
- Service Ordering:
- Ordering Services from catalogs: ./service_ordering/ordering_services.md
- Testing services:
@@ -148,8 +153,6 @@ nav:
- APIs:
- TMF API: ./architecture/tmfapi.md
- NFV API: ./architecture/nfvapi.md
- - TMF WEB: ./architecture/tmfweb.md
- - NFV WEB: ./architecture/nfvweb.md
- Issue management: ./architecture/issuemgt.md
- Central logging: ./architecture/centrallog.md
- Contributing to OSL: