Persistence and resource lifecycle/lifetime

[cristian-recoseanu]

Currently the wording in the Behaviour: Persistence of Updates section is:

"The API implementation MUST persist updates to the core information properties for the lifetime of a resource uniquely identified by its ID, including consistency over reboots, power cycles, and software upgrades."

I think traditional devices which have fairly static UUID allocations are well covered by the statement.

In terms of more dynamic devices I think we might need to better capture the relationship between persistence requirements and lifecycle/lifetime of resources. I think at the very least we need to define what is the lifetime of a resource.

Some options are:

• A. Does the lifetime of a resource end when the host Node expects to never use its UUID again? (e.g. a Node which has a remove resource workflow that permanently destroys the use of that UUID and future newly created resources are not expected to reuse that UUID).
• B. Does the lifetime of a resource end when its UUID disappears from the APIs hosted by the Node/Device?

For a Node/Device which has a limited number of operating profiles it can swap between, options A and B may result in different persistence outcomes.

For A the Node/Device is required to persist information for every operating profile even if it is currently offline because their lifetime never really ends.

For B the Node/Device only needs to persist the information for the current online operating profile. Switching away from the current operating profile could clear all associated information as the lifetime of resources ends.

Ultimately I believe our goal is to specify what is the minimum guarantee implementers can rely on.

[garethsb]

Nicely put!

[peterbrightwell]

Update 2023-06-01: Action all to respond to the A/B question so we can look at a PR.

[garethsb]

I think in the last call we largely agreed on Option A?

So something like this... please suggest improvements...

The API implementation MUST persist updates to the annotation properties for the lifetime of a resource uniquely identified by its ID, including consistency over reboots, power cycles, and software upgrades.

The lifetime of a resource ends when the API implementation intends not to use its ID again. If the implementation removes the resource from the API but can reinstate the resource with the same ID later, for example, as a result of switching between operating profiles, the annotation properties MUST/SHOULD be persisted.

[peterbrightwell]

Update 2023-06-15:

Tweaked text:

The API implementation MUST persist updates to the annotation properties for the lifetime of a resource uniquely identified by its ID, including consistency over reboots, power cycles, and software upgrades.

The lifetime of a resource ends when the API implementation intends not to use its ID again. Hibernated and reawakened resources are still within their lifetime.

The annotation properties MUST be persisted for the lifetime of the resource, so if the implementation removes the resource from the API and reinstates that same resource, it uses the same ID.

[garethsb]

"Hibernated and reawakened" is evocative but without further definition seems insufficiently precise to me.

If the example of "switching between operating profiles" isn't helpful, is there a better one?

[cristian-recoseanu]

We wanted to more clearly capture the fact that if a resource is not in the NodeAPI it doesn't necessarily mean its lifetime has ended.

[garethsb]

"If the implementation removes the resource from the API but can reinstate the resource with the same ID later"

Any other suggestions?

"If the implementation removes the resource from the API, for example when switching away from its current operating profile, but can reinstate the resource with the same ID later, for example as a result of switching back to that operating profile, the lifetime of the resource has not ended and the annotation properties MUST be persisted "