Add more specifications for `Lifetime` fields

[tiyash-basu-frequenz]

What's needed?

The Lifetime fields need to be better documented. E.g., one field here is not well documented. It does not specify what should be the behaviour if

• the operational_lifetime field is set to None, or
• if it is present but both start and stop fields in the Lifetime message are empty.

Proposed solution

We need to define the requirement here. Here are two proposals:

Proposal 1

Entities which have lifetimes set to None are invalid.

Proposal 2

Entities which have lifetimes set to None are valid, but only if at least one of the start_timestamp and end_timestamp fields are specified.

For all the above proposals, if only the start_timestamp is provided, then the component is valid and active. If the end_timestamp is provided, the component is considered valid, but inactive past the end timestamp.

Use cases

No response

Alternatives and workarounds

No response

Additional context

No response

[llucax]

From the client perspective, unless there is a good reason not to do so, I would consider Lifetime as Bounds. If the whole lifetime is not present, I would consider it as if both start and end were not present. If start is not present, I would consider it -inf (so it always existed in the past). If end is not present, I would consider it +inf (so there is no planned time to remove the asset, it exist forever in the future until the end is set).

Considering the whole component invalid because a lifetime is missing seems too extreme IMHO (at least following the robustness principle. And if there is no lifetime to make it makes sense to consider that the component is just there.

Also, my impression is this is not about active/inactive (that's the component status) but about existence. So an inactive component is part of the component graph, and we can't read or control it, but it is still there, and can actually produce or consume power (is a virtual component, right?), while if the lifetime says it doesn't exist at a particular time, it has to be completely excluded from the component graph.

Again, this is just my impression. I guess we need to confirm/clarify this with whoever asked for it.

[tiyash-basu-frequenz]

Marking this blocked until we fully grasp the requirements. To be discussed in meetings.

[tiyash-basu-frequenz]

We discussed the following:

• Start dates cannot be in the future.
• Lifetime field set to None means that the component is active.
• Lifetime.start field set to None means the component is active until Lifetime.end.
• Lifetime.end field set to None means that the component is active.

[llucax]

A proposal to close this:

• https://github.com/frequenz-floss/frequenz-api-common/pull/259

[llucax]

I didn't add the limitation of start of not being able to be in the future because I think it is not really relevant, once we need to do the filtering we'll need to check the start anyways.