Deterministic polling for the resource changes

[Danil-Grigorev]

This issue intent is to track changes, which will allow deterministic evaluation of the resource changes.

Currently the detection of the plan updates in UI is implemented based on assumptions, which does not guarantee recognition of such changes. Proposed algorithm is intended to fix this issue.

The steps for that are the following. Openshift API usually returns the updated/created object as a response to an HTTP operation like GET, PUT, POST and PATCH. This object is the one, registered by the kubernetes cluster, and contains the initial values assigned by it.

Therefore the returned response should be the source of truth for any further operations, not the one returned however long after by a following GET request.

So, for any PUT, POST or PATCH operation we expect to:

1. Store the return value for the operation in the redux state.
2. Any response to GET later on should be processed and used only when it differs from initial one, in the metadata.generation field.
3. If the represented resource state does not contain expected value, return and execute the step 1 with the current value of the resource.

Here is how I would imagine that:

let updatedPlan = yield client.patch(...);
updatedPlan = yield waitForGenerationUpdate(updatedPlan.data);
// Result equals expected state or:
updatedPlan = yield waitForGenerationUpdate(updatedPlan.data);

function* waitForGenerationUpdate(plan: IMigPlan) {
  yield put(PlanActions.planReconcilePolling(plan));
  yield take(PlanActionTypes.PLAN_RECONCILE_POLL_STOP);

  return yield call(getPlan, plan.metadata.name);
}

function* planReconcileWatch(plan) {
  const retries = 10;
  const planGeneration = plan.planValues.metadata.generation;
  try {
    for (let requestNumber = 0; requestNumber < retries; requestNumber++) {
      const updatedPlan = yield call(getPlan, plan.planValues.metadata.name);
      if (updatedPlan.metadata.generation !== planGeneration) {
        break;
      }
      yield delay(ReconcilePollPeriod);
    }
  } catch (err) {
    yield put(AlertActions.alertError('Error during plan reconcile' + err));
  } finally {
    yield put(PlanActions.stopPlanReconcilePolling());
  }
}

This would allow resource editation on the fly, and with the single action (which will be generic for every resource) prevent any updates or unnecessary operations on a resource with is in a Reconcile in progress state, from the UI perspective.