add md doc

doc/index.md

+<img src="images/openslice_logo.png" alt="drawing" width="200"/>
+
+version: 2023-Q3 1.2.0-SNAPSHOT
+
+Openslice is a prototype open source, operations support system. It supports VNF/NSD onboarding to OpenSourceMANO (OSM) and NSD deployment management. It also supports TMFORUM OpenAPIs regarding Service Catalog Management, Ordering, Resource, etc.
+
+
+## Usage
+
+Openslice allows Vertical Customers to browse the available offered service specifications and also allows NFV developers to onboard and manage VNF and Network Service artifacts. 
+The following figure displays the usage of Openslice.
+
+[![Openslice  usage](./images/index_intro_architecture.png)](./images/index_intro_architecture.png)
+
+
+There are two portals offering UI friendly access to users:
+
+* The Services portal allows users to access services and service providers to design services. 
+* The NFV portal allows users to self-manage NFV artifacts and onboard them to a target MANO/NFV Orchestrator.
+
+3rd party applications can use Openslice through TMForum Open APIs.
+
+Service Specifications reside into Service Catalogs, grouped in Categories. Openslice offers a Service Orchestrator called [OSOM](./architecture/osom.md). OSOM instantiates Service Specifications by requesting Network Services from target MANOs/NFVOs. NFV artifacts reside into a VNF/NSD catalog and are onboarded to a target MANO/NFV Orchestrator. Service Specifications reference NSD from the VNF/NSD catalog. 
+
+Customers make Service Orders and Openslice instantiates the requested Service Specifications of the 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. (See also [Service Inventory](./service_inventory.md) )
+
+[![Openslice  Service Specification instantiation](./images/service_specification_instantiation.png)](./images/service_specification_instantiation.png)
+
+## Service Lifecycle Rules
+
+Openslice constains support for defining rules of services, affecting their behavior. See [LCm Rules](./lcm.md)
+
+## Multidomain scenarios and federation
+
+Openslice can be used to exchange service specifications/catalogs and make service orders between Organizations as the following figure displays.
+
+[![Openslice  Service Specification instantiation](./images/multi-domain-organizations.png)](./images/multi-domain-organizations.png)
+
+An Identity federation is also possible since our authentication service is based on Keycloak (see [OAuth](./architecture/oauth.md) )
+
+See more on [Consuming Services From External Partner Organizations](./architecture/consumingServicesFromExternalPartners.md)
+
+
+## Live Demo
+
+* Openslice demo: <http://portal.openslice.io/>
+* Openslice Service Catalogs and ordering: <http://portal.openslice.io/services/>
+* Openslice NFV Services onboarding: <http://portal.openslice.io/nfvportal>
+> username=admin, password=openslice <br> or <br>username=admin, password=changeme
+
+
+## Video demo
+
+* <https://youtu.be/KU8JPDFFl9A>
+
+---
+
+## Installing
+
+See [Deployment/Installation](./deployment.md)
+
+---
+
+## Hardware requirements
+
+The complete environment consists of  microservices deployed as docker containers. Portainer is also installed to monitor them at port 9000
+
+If you would like to operate all APIs, OSOM, the Mysql Server, nginx, etc then you need at least:
+
+- 4 cores
+- 8GB RAM
+- 20GB HD space
+
+(NOTE: Bugzilla or ELK are not included and we assume they run elsewhere)
+
+However you can try with a minimum installation on a VM on a laptop with:
+
+- 2 cores
+- 4GB of RAM  
+
+ 
+
+## Supported APIs
+
+For a quick access check our swagger links:
+
+* TMF APIs: <http://portal.openslice.io/tmf-api/swagger-ui/>
+* API for VNF/NSD management: <http://portal.openslice.io/osapi/swagger-ui/l>
+
+## Source code
+
+Get source code here: <https://github.com/openslice>
+
+## Contributing
+
+[Contributing](./contributing/developing.md)
+
+## Social Media
+
+* Twitter: <https://twitter.com/OpensliceOSS>
+* Slack: https://openslice.slack.com
+
+## History
+
+* The NFV portal part of Openslice was initially developed in H2020 European project 5GinFIRE (https://5ginfire.eu)  by University of Patras, Greece
+* Openslice services, APIs and current version are actively maintained by University of Patras, Greece in H2020 European project 5G-VINNI (https://5g-vinni.eu/)
+
+
+[![Part of OSM Ecosystem](./images/osm_ecosystem_ossbss.png)](https://osm.etsi.org/wikipub/index.php/OSS_BSS)
+
+
+## Citation
+
+Please cite our [![paper]](https://arxiv.org/abs/2102.03290) if you use Openslice
+
+```
+
+@misc{tranoris2021openslice,
+      title={Openslice: An opensource OSS for Delivering Network Slice as a Service}, 
+      author={Christos Tranoris},
+      year={2021},
+      eprint={2102.03290},
+      archivePrefix={arXiv},
+      primaryClass={cs.NI}
+}
+
+```
\ No newline at end of file

doc/lcm.md

+# 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.
+
+[![Rules in NSI](../images/lcm/lcmfig1.png)](../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:
+
+
+[![Rules](../images/lcm/lcmfig1_osom.png)](../images/lcm/lcmfig1_osom.png)
+
+
+
+## Define rules
+
+Rules are defined when designing a Service Spec. Here is an example of a list of rules:
+
+
+[![lcmrules](../images/lcm/lcmfig2.png)](../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:
+
+[![lcmrules](../images/lcm/lcmfig3.png)](../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
+
+[![lcmrules](../images/lcm/lcmfig4.png)](../images/lcm/lcmfig4.png)
+[![lcmrules](../images/lcm/lcmfig5.png)](../images/lcm/lcmfig5.png)
+[![lcmrules](../images/lcm/lcmfig6.png)](../images/lcm/lcmfig6.png)
+[![lcmrules](../images/lcm/lcmfig7.png)](../images/lcm/lcmfig7.png)
+[![lcmrules](../images/lcm/lcmfig8.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.
+
+
+[![lcmrules](../images/lcm/lcmfig9.png)](../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
+
+
+[![lcmrules](../images/lcm/lcmfig10.png)](../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.
+
+[![lcmrules](../images/lcm/lcmfig11.png)](../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)
+
+
+[![lcmrules](../images/lcm/lcmfig12.png)](../images/lcm/lcmfig12.png)
+
+[![lcmrules](../images/lcm/lcmfig13.png)](../images/lcm/lcmfig13.png)
+
+### Create New Service Orders
+
+The following example calls to Order a New Service Specification with specific Parameter Values
+
+[![lcmrules](../images/lcm/lcmfig14.png)](../images/lcm/lcmfig14.png)
+
+
+
+
+

doc/lcmrules_main.pu

+@startuml 
+
+note
+    Notes
+    ----
+    Each LCM rule might be executed during the following phases:
+    "Pre-provision phase"
+    "Activation phase"
+    "Supervision phase", 
+    "De-activation phase"
+    
+    A rule may:
+    1) Modify some parameters of the requested service according to user request. 
+    These parameters might be part of other services (or related resources?) already included in Service order
+    2) Modify the service order by including other services
+    3) Initiate new Service Orders for Other Services (including their parameters) 
+    4) May call external services (e.g. via REST)
+end note
+
+start
+stop
+
+
+@enduml
\ No newline at end of file