update #9

The following image illustrates the approach.

<img src="img01.png" width=1024px>

[![img01.png](img01.png)]()

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. The OSL Orchestrator (OSOM) will manage the lifecycle of the Service Order.

	- Other related resources created by the CRD Controller within the namespace are automatically created in OSL Resource Inventory under the same Service Order

<img src="img02.png" width=800px>

[![img02.png](img02.png)]()

The provided image illustrates the architecture and workflow of the CRIDGE service, showing how it interacts with other components within a Kubernetes (K8s) cluster. Here is an explanation of the key components and flow in the diagram:

A CRIDGE service is usually responsible for managing one cluster. In the following diagram we show how it can be used for managing multiple clusters:

<img src="img03.png" width=1024px>

[![img03.png](img03.png)]()

We assume that there is an OSL Management cluster that OSL is installed. CRIDGE is also installed there if we would like to manage resources in the same management cluster. 

 - Each CRIDGE service has for example its own configuration to connect to target cluster

The sync process is found in the code and explained by the following picture:

<img src="img04.png" width=1024px>

[![img04.png](img04.png)]()

 WatcherService is executed when the cridge service application starts (see onApplicationEvent). First things:

# Deployment of a new CR based on a CRD

<img src="img05.png" width=1024px>

[![img05.png](img05.png)]()

- A message arrives to deploy a CR

	- The call examines if this CRIDGE service can handle the request (based on context and masterURL)