# Bug description org.etsi.osl.tmf.sim638.model.Service.findNextStateBasedOnResourceList(List (org.etsi.osl.model.tmf/.../sim638/model/Service.java:792-865) decides a Service's lifecycle state from the resourceStatus of its supporting resources. That field does not mean what the method assumes it means. **However the logic there is wrong.** ResourceStatusType is inventory/pool bookkeeping: AVAILABLE means "free in a pool, available for reservation", RESERVED means "held by someone" (in Chronos's case, actually booked). It says nothing about whether the thing is working. The X.731 states on the same object are what express health, operationalState (ENABLE/DISABLE), administrativeState (LOCKED/UNLOCKED/SHUTDOWN) and usageState (IDLE/ACTIVE/BUSY) expresses utilisation. ## The correct approach **ITU-T Recommendation X.731** defines the state management function for Open Systems Interconnection (OSI) systems management. **Key State Attributes** The standard defines three main state attributes for managed objects: **Administrative State:** Shows permission for use, controlled by an administrator (values include Locked, Unlocked, and Shutting Down). **Operational State:** Shows whether the resource is physically working and operational (values include Enabled and Disabled). **Usage State:** Shows whether the resource is actively in use by applications or users (values include Active, Idle, and Busy). Here is how the X.731 state attributes interact, transition, and apply to modern network environments. ## 1. State Value Interactions The three primary state attributes (Administrative, Operational, and Usage) do not operate in isolation. They form a matrix that determines the overall status of a network resource. * The Operational Gatekeeper: If the Operational State is Disabled (due to a fault), the resource cannot be used, regardless of the other states. * Administrative Control over Usage: If an administrator sets the Administrative State to Locked, the Usage State will eventually transition to Idle as existing sessions terminate. No new sessions can be created. * The Normal Operating Matrix: When a resource is healthy and active, its state combination is: Unlocked (Administrative) + Enabled (Operational) + Busy/Active (Usage). ## 2. Transitional States and Dependent Values X.731 defines specific status attributes that explain why a resource is in a certain state or how it is moving between states. * Shutting Down (Administrative): A transitional state indicating the resource will be Locked to new users, but existing users can finish their tasks. * Unknown (Operational): Used when the management system loses connectivity to the resource and cannot verify if it is Enabled or Disabled. * Dependency Relationships: A resource's state can be bound to another. For example, a virtual interface cannot transition to Enabled if its underlying physical port is Disabled. ## 3. Application to Modern Network Management While X.731 was designed for OSI networks, its core philosophy remains foundational in modern infrastructure management, such as YANG data modeling, RESTCONF/NETCONF, and Kubernetes. * YANG/NETCONF: Modern network automation uses X.731 concepts by splitting data into config (Administrative intent, like shutdown or no shutdown on a Cisco interface) and state (Operational reality, like up or down). * Kubernetes Pod Lifecycle: The transition from Pending to Running or Terminating mirrors the X.731 state flow. A deployment undergoing a rolling update mirrors the Shutting Down administrative state. * Cloud Infrastructure (AWS/Azure): An EC2 instance lifecycle utilizes these exact concepts: Stopping (Shutting Down), Stopped (Locked), and Terminated. ## OPENSLICE Implications - findNextStateBasedOnResourceList (Service.java:792) has 5 production call sites in: CROrchestrationCheckDeploymentService:120, GCOrchestrationCheckDeploymentService:102, MetricoOrchestrationCheckDeploymentService:91 (OSOM) and ServiceRepoService.updateServicesHavingThisSupportingResource:1166 (tmf.api) - Nothing in the platform ever writes usageState, operationalState, or administrativeState. cridge (KubernetesClientResource.checKCRVResourceStatus:294), Metrico all write only resourceStatus. Defaults are resourceStatus=UNKNOWN, usageState=IDLE, the other two null. ## Approach **Outcome:** the health verdict moves from a single hard-coded table in the consumer to each producer, which states its own resource's health in the model's own vocabulary. resourceStatus keeps its real, narrower job (pool inventory; still read by ResourceRepository:43-52 partner filtering and ResourceMetricsApiController) and stops driving service lifecycle. **Type of change:** foundational. It changes a cross-service contract. repos affected for now: org.etsi.osl.model.tmf, org.etsi.osl.tmf.api, org.etsi.osl.model.k8s, org.etsi.osl.cridge, org.etsi.osl.osom, org.etsi.osl.metrico - we will try a **Hard switch**, ignore resourceStatus. Derive purely from the three X.731 states. Cleanest model, but every live k8s/CR deployment stops reaching ACTIVE until cridge is changed and redeployed and existing CRs' status labels would need remapping. - Separate issues in other projects will need to reflect and adopt this correct approach **Decisions taken** - Hard switch: the derivation stops reading resourceStatus entirely. - usageState is informational and does not gate service state (X.731: a deployed-but-unused resource is legitimately IDLE, and cridge cannot observe usage from a CR). - administrativeState=SHUTDOWN is the teardown tombstone, replacing SUSPENDED. - A resource counts as healthy only when it explicitly declares administrativeState=UNLOCKED. the new derivation New org/etsi/osl/tmf/ri639/model/ResourceHealth.java — the per-resource verdict: UP | PENDING | DOWN | HELD | GONE New Resource.deriveHealth() in org/etsi/osl/tmf/ri639/model/Resource.java, evaluated in this order (order matters — SHUTDOWN outranks everything): | \# | condition | verdict | |----|--|--| | 1 | administrativeState == SHUTDOWN | GONE | | 2 | administrativeState == LOCKED | HELD | | 3 | operationalState == null or administrativeState == null | PENDING | | 4 | operationalState == ENABLE (and admin is UNLOCKED) | UP | | 5 | operationalState == DISABLE (and admin is UNLOCKED) | DOWN | Rewrite Service.findNextStateBasedOnResourceList(List), same name, same signature, so all call sites keep compiling, as a fold over deriveHealth(): | /# | condition| next state| | ------ | ------ | ------ | | 1 | this.state == TERMINATED | TERMINATED (absorbing — preserved from today) | | 2 | list empty or null | this.state (unchanged; never invent ACTIVE) | | 3 | all GONE | TERMINATED | | 4 | any GONE, DOWN, or HELD | INACTIVE | | 5 | any PENDING | ACTIVE if already ACTIVE, else RESERVED | | 6 | all UP | ACTIVE | ## Acknowledgements This work is supported by the EU-funded HORIZON-CL4-2024-DATA COP-PILOT project with Grant Agreement number 101189819.