feat: primary resource caching for followup reconciliation(s)

[csviri]

It provides facilities to cache the primary resource for follow-up reconciliations, thus ensuring that the reconciler always handles the up-to-date primary.

Later, we might extend this to the resource part, not just status (in terms of utils, cache already supports that) - now the utility methods focus on status.

[xstefank]

LGTM

[afalhambra-hivemq]

When using the PatchAndCacheStatusWithLock approach, we will need to explicitly use optimistic locking here, which in theory it should be fine.
However, the default retry mechanism provided by the JOSDK when a 409 conflict happen doesn't pick the latest resource status, forcing us to implement a custom retry mechanism for this. Otherwise the default retry mechanism is not useful here.

Anyways, I can raise a separate issue for that default mechanism to see if it can be improved there.

Beside that, great work and thanks a lot for this PR.

[afalhambra-hivemq]

Can we add small JavaDoc for this exposed method as well?

[afalhambra-hivemq]

Suggested change

	public static final int DEFAULT_PERIOD = 30;
	private static final int DEFAULT_PERIOD = 30;

[csviri]

This is for tests, and for reusability would stick with the public approach

[afalhambra-hivemq]

Maybe to make sure and guarantee no status update is lost, we could check an array or a list of values from 1 to 10 are present (all of them in particular order).
Otherwise, this assert isGreaterThan(10) will eventually be true regardless of the caching.

[csviri]

Hi there is that is error check, what should induce that there was monotonic, but yeah definitelly can improve the azsserts

[csviri]

When using the PatchAndCacheStatusWithLock approach, we will need to explicitly use optimistic locking here, which in theory it should be fine. However, the default retry mechanism provided by the JOSDK when a 409 conflict happen doesn't pick the latest resource status, forcing us to implement a custom retry mechanism for this. Otherwise the default retry mechanism is not useful here.

Anyways, I can raise a separate issue for that default mechanism to see if it can be improved there.

Beside that, great work and thanks a lot for this PR.

Probably the best would be to not use the approach with the lock, but the lockless alternative.

[afalhambra-hivemq]

Probably the best would be to not use the approach with the lock, but the lockless alternative.

The only drawback here with the lockless alternative is that it will require us to handle the cache in the operator itself

[csviri]

Probably the best would be to not use the approach with the lock, but the lockless alternative.

The only drawback here with the lockless alternative is that it will require us to handle the cache in the operator itself

Yes, but that is as simple as in the integration test. We might interate on this in the future, but in the short term I think that is best for you.

[csviri]

Just thinking more about this, that the locked version in this form is not very useful. Since it fails to fulfill its purpose, thus to make sure that the resource is updated with a generated id.

On the other hand we could do something that (now deprecated in client) is the resource(resource).replace(), that would basically retry locally the update, thus if fails read the resource and try again in place.

Some kind of retry would be nice also for patch withouth the lock. So will spend some more time on this to improve.

[afalhambra-hivemq]

resource(resource).replace(), that would basically retry locally the update

Curious here, what do you mean by retry locally?

Some kind of retry would be nice also for patch withouth the lock. So will spend some more time on this to improve.

That would be awesome! Thanks

[csviri]

Curious here, what do you mean by retry locally?

Basically that you configure fabric8 client to retry.

[csviri]

@afalhambra-hivemq @metacosm @xstefank added docs and made some improvements.