@@ -171,7 +171,12 @@ OSOM checks the presence of attribute _CR_SPEC at the RFS to make a request for
> LCM rules can be used to change attributes of this yaml/json file, before sending this for orchestration
However, the following issue needs to be solved: ** How to map the CR lifecycle that is defined in the CRD with the TMF resource Lifecycle? **
- For this We introduced the following characteristics: _CR_CHECK_FIELD, _CR_CHECKVAL_STANDBY, _CR_CHECKVAL_ALARM, _CR_CHECKVAL_AVAILABLE, _CR_CHECKVAL_RESERVED, _CR_CHECKVAL_UNKNOWN, _CR_CHECKVAL_SUSPENDED
- For this we introduced `_CR_CHECK_FIELD` (the CR field to observe) plus a set of `_CR_CHECKVAL_*` characteristics that name the observed value signalling each ITU-T X.731 state / health verdict:
-`_CR_CHECKVAL_HEALTH_{UP,PENDING,DOWN,HELD,GONE}` — the [`ResourceHealth`](https://labs.etsi.org/rep/osl/code/org.etsi.osl.model.k8s) verdict; CRIDGE folds it into `operationalState`/`administrativeState`
- The older `_CR_CHECKVAL_{STANDBY,ALARM,AVAILABLE,RESERVED,UNKNOWN,SUSPENDED}` characteristics (which mapped to `resourceStatus`) are **no longer consumed by CRIDGE** — `resourceStatus` is allocation/pool bookkeeping owned by whoever claimed the resource, never written by CRIDGE.
OSOM sends to CRIDGE a message with the following information:
@@ -182,13 +187,14 @@ OSOM sends to CRIDGE a message with the following information:
- org.etsi.osl.prefixName: we need to add a short prefix (default is cr) to various places. For example in K8s cannot start with a number
- org.etsi.osl.serviceOrderId: the related service order id of this deployment request
- org.etsi.osl.namespace: requested namespace name
- org.etsi.osl.statusCheckFieldName: The name of the field that is needed to be monitored in order to monitor the status of the service and translate it to TMF resource statys (RESERVED AVAILABLE, etc)
- org.etsi.osl.statusCheckValueStandby: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state STANDBY (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- org.etsi.osl.statusCheckValueAlarm: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state ALARMS (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- org.etsi.osl.statusCheckValueAvailable: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state AVAILABLE (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- org.etsi.osl.statusCheckValueReserved: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state RESERVED (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- org.etsi.osl.statusCheckValueUnknown: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state UNKNOWN (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- org.etsi.osl.statusCheckValueSuspended: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state SUSPENDED (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- org.etsi.osl.statusCheckFieldName: The name of the CR field that is observed to determine the resource's state
- org.etsi.osl.healthCheckValue{Up,Pending,Down,Held,Gone}: The CR specific value (of the CheckFieldName) that CRIDGE maps to the ITU-T X.731 `ResourceHealth` verdict (see org.etsi.osl.tmf.ri639.model.ResourceHealth)
- org.etsi.osl.operStateCheckValue{Enable,Disable}: The CR specific value that CRIDGE maps to `operationalState` (see org.etsi.osl.tmf.ri639.model.ResourceOperationalStateType)
- org.etsi.osl.adminStateCheckValue{Locked,Unlocked,Shutdown}: The CR specific value that CRIDGE maps to `administrativeState` (see org.etsi.osl.tmf.ri639.model.ResourceAdministrativeStateType)
- org.etsi.osl.usageStateCheckValue{Idle,Active,Busy}: The CR specific value that CRIDGE maps to `usageState` (see org.etsi.osl.tmf.ri639.model.ResourceUsageStateType)
**Note on what these map to.** When the observed field carries a matching value, CRIDGE records it on `KubernetesCRV1.{healthValue,operationalStateValue,administrativeStateValue,usageStateValue}` and `KubernetesCRV1.applyState()` folds it into the ITU-T X.731 pair `operationalState`/`administrativeState` (a `healthValue` verdict is authoritative; otherwise the individual attributes are used). That pair is what CRIDGE publishes and what `Resource.deriveHealth()` / `Service.findNextStateBasedOnResourceList` fold into the supported service's state. CRIDGE never writes `resourceStatus` — that is allocation/pool bookkeeping owned by whoever claimed the resource, and `CatalogClient.withoutResourceStatus()` strips it from every catalog write. The legacy `org.etsi.osl.statusCheckValue*` headers (mapping to `resourceStatus`) are still sent by OSOM for compatibility but are ignored by CRIDGE.
- Parameters:
- aService reference to the service that the resource and the CR belongs to
**These characteristics instrument OpenSlice services to manage and reflect the lifecycle of a kubernetes resource to OpenSlice's (TMF based) lifecycle**
- _CR_CHECK_FIELD: The name of the field that is needed to be monitored in order to monitor the status of the service and translate it to TMF resource statys (RESERVED AVAILABLE, etc)
- _CR_CHECKVAL_STANDBY: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state STANDBY (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- _CR_CHECKVAL_ALARM: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state ALARMS (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- _CR_CHECKVAL_AVAILABLE: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state AVAILABLE (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- _CR_CHECKVAL_RESERVED: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state RESERVED (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- _CR_CHECKVAL_UNKNOWN: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state UNKNOWN (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- _CR_CHECKVAL_SUSPENDED: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state SUSPENDED (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- _CR_CHECK_FIELD: The name of the CR field that is observed to determine the resource's state
- _CR_CHECKVAL_HEALTH_{UP,PENDING,DOWN,HELD,GONE}: The CR specific value (of the CheckField) that CRIDGE maps to the ITU-T X.731 `ResourceHealth` verdict (see org.etsi.osl.tmf.ri639.model.ResourceHealth). A verdict is authoritative and CRIDGE folds it into `operationalState`/`administrativeState`.
- _CR_CHECKVAL_OPERSTATE_{ENABLE,DISABLE}: The CR specific value that CRIDGE maps to `operationalState` (see org.etsi.osl.tmf.ri639.model.ResourceOperationalStateType)
- _CR_CHECKVAL_ADMINSTATE_{LOCKED,UNLOCKED,SHUTDOWN}: The CR specific value that CRIDGE maps to `administrativeState` (see org.etsi.osl.tmf.ri639.model.ResourceAdministrativeStateType)
- _CR_CHECKVAL_USAGESTATE_{IDLE,ACTIVE,BUSY}: The CR specific value that CRIDGE maps to `usageState` (see org.etsi.osl.tmf.ri639.model.ResourceUsageStateType)
**Note on what these map to.** When the observed field carries a matching value, `KubernetesCRV1.applyState()` folds it into the ITU-T X.731 pair `operationalState`/`administrativeState` (a health verdict is authoritative; otherwise the individual attributes are used). That pair is what CRIDGE publishes and what `Resource.deriveHealth()` / `Service.findNextStateBasedOnResourceList` fold into the supported service's state. CRIDGE never writes `resourceStatus` — that is allocation/pool bookkeeping owned by whoever claimed the resource, and `CatalogClient.withoutResourceStatus()` strips it from every catalog write. The legacy `_CR_CHECKVAL_{STANDBY,ALARM,AVAILABLE,RESERVED,UNKNOWN,SUSPENDED}` characteristics (mapping to `resourceStatus`) are still emitted for compatibility but ignored by CRIDGE.