diff --git a/doc/alarms_actions.md b/doc/alarms_actions.md
deleted file mode 100644
index b7715494e2c504668c69d5a690197346fdb7be4b..0000000000000000000000000000000000000000
--- a/doc/alarms_actions.md
+++ /dev/null
@@ -1,113 +0,0 @@
-# Alarms
-
-In Openslice parts of TMF642 Alarm Management API are currently implemented. Alarms can be managed through the TMF API endpoint as well as the UI.
-
-
-
-## Alarms and Actions
-
-Note: Actions is an experimental feature. We expect to have a more mature solution in future. The component in the architecture is the Openslcie Assurance Services
-
-Alarms can be automatically resolved by specific actions. Today only the following actions are offered.
-
-* execDay2
-* scaleServiceEqually
-
-
-## execDay2
-
-Usually used to perform a Day2 configuration (towards OSM). To use it, Create a New Action Specification Name=execDay2 as following
-
-[](./images/alarms_actions/day2actionspec.png)
-
-
-Now make a Service Order for your service. In this example ςε used a cirros NSD
-
-Create a New Action Rule for the running services as the following example:
-
-
-[](./images/alarms_actions/action_rule_exampleday2.png)
-
-The scope is the running cirros service.
-
-Params should be paramname=value;paramname2=value2;paramname3=value3 (must exist in the VNF otherwise OSM will raise an error).
-
-In this case should be filename=test.txt
-
-Primitive=touch
-
-ServiceId = select the service which will accept the Day2. In this case is the same
-
-To test it:
-
-Go to the Service Inventory and select the active Service.
-
-Note the UUID of the service (e.g. c4e7990a-e174-4cd2-9133-b10e56721e08 copy from address bar), DeploymentRequestID and NSDID from characteristics
-
-You can either use the UUID of the service or the DeploymentRequestID and POST to the Alarms endpoint ( /tmf-api/alarmManagement/v4/alarm)
-
-
-If the DeploymentRequestID is used then POST:
-
-```
-
-{
- "alarmRaisedTime": "2021-06-29T12:30:24.675Z",
- "alarmReportingTime": "2021-06-29T12:30:54.675Z",
- "state": "raised",
- "alarmType": "qualityOfServiceAlarm",
- "probableCause": "thresholdCrossed",
- "ackState": "unacknowledged",
- "perceivedSeverity": "major",
- "sourceSystemId": "mano-client-service",
- "alarmDetails": "NSID=3;DeploymentRequestID=1",
- "specificProblem": "myalram raised"
-}
-
-```
-
-
-If the UUID is used then POST:
-
-```
-
-{
- "alarmRaisedTime": "2021-06-29T12:30:24.675Z",
- "alarmReportingTime": "2021-06-29T12:30:54.675Z",
- "state": "raised",
- "alarmType": "qualityOfServiceAlarm",
- "probableCause": "thresholdCrossed",
- "ackState": "unacknowledged",
- "perceivedSeverity": "major",
- "sourceSystemId": "mano-client-service",
- "alarmDetails": "analarm",
- "specificProblem": "myalram raised",
- "affectedService": [
- {
- "id": "c4e7990a-e174-4cd2-9133-b10e56721e08"
- }
- ]
-
-}
-
-```
-
-The Alarm to be created must have the affected Service ID equal to the running service from the scope (the cirros_ns)
-
-Go to service inventory you will see the notes and also the service characteristics for any EXEC_ACTION updates
-
-You can also adjust the alarm conditions. They must match true so the alarm to be acknowledged
-So if another external service raises an Alarm (with POST) for the running service, a Day2 will be performed on another Service
-
-
-## scaleServiceEqually
-
-
-This action is used from getting a scaling event from OSM. Please see the next demo for details on how it works
-
-
-### Prototype demo
-
-You can watch how we used the prototype on the following ETSI ZMS PoC #2
-
-* ETSI ZMS PoC #2: <https://www.etsi.org/events/1905-webinar-zsm-poc-2-showcase-automated-network-slice-scaling-in-multi-site-environments/>
diff --git a/doc/catalogs.md b/doc/catalogs.md
deleted file mode 100644
index 3b3538d0b5dcaedf1690154bea22e70caf85551b..0000000000000000000000000000000000000000
--- a/doc/catalogs.md
+++ /dev/null
@@ -1,147 +0,0 @@
-# Catalogs and Templates
-
-The Openslice Service Catalogue (accessible through the API or Services portal) contains the representation of Service Specifications, either created from the provider defining service attributes, or by supporting the GSMA Generic Slice Templates (GST) as well as the VINNI Service Blueprint. The following scenarios are supported by the Openslice Service Catalogue.
-
-
-## Create/Design a Service Specification
-
-### First Import some Resources as Resource Facing Services (RFSs)
-
-If you have any NSDs as NFV artifacts, import them through the UI menu (Import from NSD list). Then an NSD is imported as a resource and an RFS automatically is created. RFSs then later are used to design a Customer Facing Service Specification
-
-### Create/Design a Customer Facing Service Specification
-
-Customer Facing Service Specification are the services offered to customers.
-You can create a new Service Specification from the menu. The services created through the UI are Customer Facing Services (CFS). Usually you create a CFS as a bundle and then you include Service Specification Relationships with RFSs or/and CFSs.
-
-Any Service Specification Characteristics from the RFS are copied to the CFS specification. A CFS can include multiple RFS or/and CFSs.
-For example you can create a CFS spec called "A 5G Service" which is a bundle of two other services (include them in Service Specification Relationships) such as 5G eMBB Slice and a Customer VPN. So when the user orders "A 5G Service" services from 5G eMBB Slice and a Customer VPN will be created during the order.
-
-### Initial configuration for OSM deployment
-
-if you have an initial configuration that needs to be applied in the NSD deployment, then you go to the RFS (or CFS) and in Service Specification Characteristics go and edit the OSM_CONFIG characteristic.
-You can add in the Service Characteristic Value, in the Value field something like the following example which gives a floating IP to a VNF:
-
-```
-{ "nsdId": "e855be91-567b-45cf-9f86-18653e7ea", "vimAccountId": "4efd8bf4-5292-4634-87b7-7b3d49108" , "vnf": [ {"member-vnf-index": "1", "vdu": [ {"id": "MyCharmedVNF-VM", "interface": [{"name": "eth0", "floating-ip-required": true }]}]}]}
-
-```
-
-or a more complex example (beautify it first if you want to view it, but in the parameter OSM_CONFIG must be minified like the example):
-
-```
-{"nsdId":"e855be91-567b-45cf-9f86-18653e7","vimAccountId":"4efd8bf4-5292-4634-87b7-7b3d491","vnf":[{"member-vnf-index":"1","vdu":[{"id":"haproxy_vdu","interface":[{"name":"haproxy_vdu_eth1","floating-ip-required":true}]}]}],"vld":[{"name":"pub_net","vim-network-name":"OSMFIVE_selfservice01"},{"name":"management","vim-network-name":"OSMFIVE_selfservice01"},{"name":"lba_net","vim-network-name":"lba_net","vnfd-connection-point-ref":[{"member-vnf-index-ref":"1","vnfd-connection-point-ref":"haproxy_private","ip-address":"192.168.28.2"}]},{"name":"backend_net","vim-network-name":"backend_net","vnfd-connection-point-ref":[{"member-vnf-index-ref":"3","vnfd-connection-point-ref":"haproxy_public","ip-address":"192.168.20.2"}]},{"name":"lb_sb_net","vim-network-name":"lb_sb_net","vnfd-connection-point-ref":[{"member-vnf-index-ref":"3","vnfd-connection-point-ref":"haproxy_private","ip-address":"192.168.28.2"}]},{"name":"breaking_point_Spain","vim-network-name":"sb_repo_net"},{"name":"breaking_point_Greece","vim-network-name":"5TONICexternal"}],"additionalParamsForVnf":[{"member-vnf-index":"2","additionalParams":{"target_IP":"192.168.20.2"}},{"member-vnf-index":"4","additionalParams":{"target1_IP":"192.168.21.2","target2_IP":"10.154.252.10"}}]}
-```
-
-You can leave the Alias and Unit of Measure as is. Check also the is Default.
-
-
-
-### Day 2 Primitive Actions
-
-NFVOs like OSM allow to perform actions while a service is running, for example change attributes or make actions on a specific VNF. To design this do something similar to the following example:
-
-- Go to the RFS related to the NSD that contains VNFs with primitives
-- create a characteristic named Primitive::<primitive> , e.g. Primitive::touch
-- select Value Type: ARRAY
-- add Service Characteristic Value: i) alias=primitive, value=<primitivename> (e.g. touch), ii) alias=member_vnf_index, value=<vnf index> (e.g. 1), iii) add the params that the user will change in alias the name of param and in value an initial value (e.g. alias=filename, value=myfile.txt)
-
-In the above example, when the service is running and the user goes to service inventory to MODIFY it, changes the value of the alias=filename, value=myfile.txt, to value =secondfile.txt. Then inside the VNF a file will be created called secondfile.txt
-
-
-
-### Generic Slice Templates (GST)
-(Offered only as a design for now. THere is no direct implementation to NFV)
-On October 16th 2019 GSMA published NG.116 Version 2.0 which defines the Generic Network Slice Template (GST). GST is a set of attributes that can characterise a type of network slice/service. GST is generic and is not tied to any specific network deployment. Here is a list of the various attributes of the template:
-
-- Availability
-- Area of Service
-- Delay tolerance
-- Deterministic communication
-- Downlink throughput per network slice
-- Downlink throughput per UE
-- Energy efficiency
-- Group communication support
-- Isolation level
-- Location based message delivery
-- Maximum supported packet size
-- Mission critical support
-- MMTel support
-- NB-IoT support
-- Network Slice Customer network functions
-- Number of connections
-- Number of terminals
-- Performance monitoring
-- Performance prediction
-- Positioning support
-- Radio spectrum
-- Reliability
-- Root cause investigation
-- Session and Service Continuity support
-- Simultaneous use of the network slice
-- Slice quality of service parameters
-- Support for non-IP traffic
-- Supported access technologies
-- Supported device velocity
-- Synchronicity
-- Terminal density
-- Uplink throughput per network slice
-- Uplink throughput per UE
-- User management openness
-- User data access
-- V2X communication mode
-
-Openslice offers the GST in a format that is machine readable and aligned with the TMF SID model. Here is a tentative approach in JSON : <https://github.com/openslice/org.etsi.osl.tmf.api/blob/master/src/main/resources/gst.json>
-
-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
-
-
-## Assign a Service Specification to Service Categories and Publish
-
-Just create categories and from the menu select the category and add services
-
-
-## Retire/Remove a Service Specification
-
-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)
-
-
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/nfvcatalogs.md b/doc/nfvcatalogs.md
deleted file mode 100644
index ad055840d65abfe337af4a5b60a3e7e10097ec42..0000000000000000000000000000000000000000
--- a/doc/nfvcatalogs.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# NFV Services
-
-NFV Services are managed through a dedicate UI the NFV portal (eg http://portal.openslice.io/nfvportal)
-
-Users are able through this portal to manage their NFV artifacts towards the NFVO, ( for example onboard VNFs and NSDs to a target OSM)
-
-
-Openslice NFV Services target to accommodate the following envisaged user roles. All users are assumed to be Authenticated:
-
-* NFV developer: This role is responsible to upload VNF and NSD Descriptors in the Openslice services towards NFVO like OSM
-* Services administrator: This role represents the user that are responsible for maintenance of the Openslice services
-
-(obsolete: )
-
-* Testbed provider: This role represents users that are responsible for testbed administration, configuration, integration, adaptation, support, etc
-* Experimenter: This role represents the user that will utilize our services and tools to deploy an experiment. That is the experiment description in terms of e.g.: NSD (Network Service Descriptor) or TOSCA Specification (in future versions)
-
-
-Finally an anonymous user role exists who has some really simple usage scenarios (e.g. signup through the portal)
-
-
-During the onboarding process the following occurs:
-
-• A NFV developer submits a NFV archive (VNF or NSD) (he can later manage if needed some metadata)
-• The administrator can manage the NFV artifact (e.g. edit it)
-• The administrator On-Boards the NFV artifact to the target MANO
-• The administrator can optionally mark the NFV:
-o As public in order to be publicly visible by all portal users
-o As Certified which means this is certified by a certain entity
-
-
-## Request a new NSD deployment (this is different in comparison to Services)
-
-
-A developer requests a new network service deployment (which NSD, tentative dates, target infrastructure, etc.). The request is marked as UNDER_REVIEW
-
-* The administrator is notified about the new request and he has the following options:
-* Schedule the deployment for the requested dates or propose other dates. The request is marked as SCHEDULED
-* Reject the request for some reason. The Request is marked as REJECTED
-* Deploy the request to target VIM(s). The Request is marked as RUNNING
-* Finalize the deployment and release resources. The Request is marked as COMPLETED
-* every change of the request-lifecycle the experimenter is notified.
\ No newline at end of file
diff --git a/doc/nfvoconfig.md b/doc/nfvoconfig.md
deleted file mode 100644
index 91efd366f981905fa7cd16fdf3838b2c6954c4ed..0000000000000000000000000000000000000000
--- a/doc/nfvoconfig.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# NFV Orchestrator configuration
-
-NOTE: Currently we support Open Source MANO version SEVEN/EIGHT/TEN/ELEVEN. Later versions of OSM may also be supported by the existing configuration, as from OSM 9+ the project converged to the SOL005 interface, regarding the NBI, and SOL006 (YANG model), regarding the NFV/NSD packaging. Also an implementation of a generic SOL005 interface is supported, but not extensively tested.
-
-Configuration of your target(s) NFVOs/MANO services with Openslice is performed through the NFV portal.
-
-Login to http://yourdomain/nfvportal/
-
-Navigate to Admin->Manage MANO Platforms and pick one of the supported MANO platform(s), e.g. Name=OSMvTEN, Version=OSMvTEN and save
-
-Navigate to Admin->Manage MANO providers and enter a New MANO Provider:
-
-* Name whatever you wish
-* API URL Endpoint, eg: https://10.10.10.10:9999 (This is the SOL005 NBI endpoint)
-* Username, password and Project of your OSM tenant.
-
-Check EnabledForONBOARDING, so when users onboard VNFs/NSDs they will be automatically ONBOARDED to this MANO. If left unchecked, the onboarding must be performed manually after the VNF/NSD is uploaded to the portal.
-
-Check EnabledForSYNC, if you want to support MANO->Openslice auto synchronization. When enabled, the existing VNFs/NSDs and VIMs (and any updates on them) of the registered MANO are also reflected to the portal.
\ No newline at end of file
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/mkdocs.yml b/mkdocs.yml
index 3310c42167102faa2b637714c2405cfa75d69465..cd470959be43191545926a113dd9ac3e5b7632b6 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -73,23 +73,7 @@ nav:
- Introduction: index.md
- Getting Started:
- Deployment/Installation: deployment.md
- - NFV Orchestrator Configuration: nfvoconfig.md
- - Service Catalogs: catalogs.md
- - NFV Catalogs: nfvcatalogs.md
- - LCM Rules: lcm.md
- - Consuming Services From External OSS: ./architecture/consumingServicesFromExternalPartners.md
- - Service Inventory: service_inventory.md
- - Alarms and Actions: alarms_actions.md
- Design & Architecture:
- Architecture: ./architecture/architecture.md
- - Message bus: ./architecture/messagebus.md
- - OSOM: ./architecture/osom.md
- - Authentication: ./architecture/oauth.md
- - 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:
- Developing: ./contributing/developing.md