Prior state for reconcile

[shawkins]

If we want to implement edge handling based upon differences in the current resource state and the prior state known to the operator sdk, is there a way to get that in 3.x?

[csviri]

@shawkins that is not possible by definition.

Would be theoretically possible to get it using the cache, but if the operator is restarted the previous event would not be accessible (for example).

[shawkins]

@shawkins that is not possible by definition.

Sorry, I'm not being precise enough with the wording. In the same way that an informer update event provides both the last known state from the informer cache and the new state, I want to be able to compare the old (which should be the last known state to the operator sdk) and the new state. I understand the implications about edge handling wrt missed or mishandled events.

Would be theoretically possible to get it using the cache

So the primary cache at the time of the reconcile call has not yet been updated to the new state?

but if the operator is restarted the previous event would not be accessible

Correct, a restart without the operator separately saving the last known state, would be expected to fully reconcile everything as those are logically add events.

[csviri]

Sorry, no the cache contains the most recent object, I wrote it incorrectly. ( Currently using directly the informer cache )

So in short is not possible. Only the new resource is accessible through the api. It was accessible before (V1.x). But there is a consensus in the community that on a reconciliation all resources should be reconciled. So from v2.x on purpose we removed access to the previous resource. ( Discussed this also with folks from go operators that time)

Since the cached state of a resource is used to compare the desired state it should be very efficient to reconcile a resource.

It would be helpful if you describe your use case more in details , to so we have a better understanding.

[shawkins]

It would be helpful if you describe your use case more in details , to so we have a better understanding.

In a couple of circumstances we have wanted to quickly filter event processing based upon exactly what is changing - which would be coupled with a scheduled or other backup mechanism that would more completely update the desired state if necessary.

The most general approach is just to use the informer prior state, but of course we can take responsibility for creating annotations of hashes or similar to do nearly the same thing if that is not possible through the operator sdk logic anymore.