Reconciler should know when dependent resource already exist

[scrocquesel]

When the AbstractDependentResource already exist prior to creating the primary resource, the reconciler should know about it to be able to handle the situation and update the primary resource status accordingly.
For eg., the reconciler may set a CONFLICT status to let the user knows the observed spec conflict with an existing resource.

I have pushed a commit to demonstrate the use case on mysql-schema sample : https://github.com/scrocquesel/java-operator-sdk/tree/schema-already-exist

Be aware that, on startup, when match is true, the dependent resource alone cannot tell if there is a possible conflict or if it is what it should be from a prior reconciliation, actual and desired just match. Only the reconciler can tell apart if it saves the previous observed state.

For eg.

return context.get(BUILT_SCHEMA, Schema.class).map(s -> {
      updateStatusPojo(schema, context.getMandatory(MYSQL_SECRET_NAME, String.class),
          context.getMandatory(MYSQL_SECRET_USERNAME, String.class));
      log.info("Schema {} created - updating CR status", schema.getMetadata().getName());
      return UpdateControl.updateStatus(schema);
    }).orElseGet(() -> context.get(EXISTING_SCHEMA, Schema.class).map(s -> {
      if (schema.getStatus().getStatus() != "CREATED")
        schema.getStatus().setStatus("CONFLICT");
      log.info("Schema {} already exists - updating CR status", schema.getMetadata().getName());
      return UpdateControl.updateStatus(schema);
    }).orElse(UpdateControl.noUpdate()));

[scrocquesel]

Sorry, I forgot to mention that currently there is no way to set (EXISTING_SCHEMA, Schema.class) in the context from the dependent abstraction implementation.

[csviri]

@scrocquesel is this issue still relevant? not sure if I follow, so you need to know if the resource existed on beginning of reconciliation. This kinda contradicts with the Kubernetes / Controller philosophy of level based event handling. That you should not work based on the history but just the current state. What is the goal you want to achieve with this?

BTW we were discussion some more inf returned from dependentResource.reconcile(), to denote what exactly happened during the reconciliation. Like if the resource is created, updated or deleted during the reconciliation. Just want to understand you use case more.

[csviri]

see also: #1030
(this is for standalone mode)

[scrocquesel]

ReconcileResult.noOperation with a not empty resource is enough. I guess the objective is that the manager save this result in the context for non standalone mode.

[scrocquesel]

@csviri would it be possible to add a get/setReconcileResult on ManagedDependentResourceContext like

private final ConcurrentHashMap<DependentResource<?, ?>, ReconcileResult<?>> reconcileResults =
      new ConcurrentHashMap<>();

  /**
   * Retrieve a reconcile result of the specified dependent resource implementation.
   *
   * @param dependentResource the dependent resource implementation
   * @return an Optional containing the reconcile result or {@link Optional#empty()} if no such
   *         object exists
   */
  @SuppressWarnings("unchecked")
  public <R, T extends DependentResource<R, ?>> Optional<ReconcileResult<R>> getReconcileResult(
      DependentResource<R, ?> dependentResource) {
    return Optional.ofNullable(reconcileResults.get(dependentResource))
        .map(r -> (ReconcileResult<R>) r);
  }

  /**
   * Set a reconcile result of the specified dependent resource implementation.
   *
   * @param dependentResource the dependent resource implementation
   * @param reconcileResult the reconcile result to add to the context associated with the specified
   *        dependent resource
   */
  public <R, T extends DependentResource<R, ?>> void setReconcileResult(
      DependentResource<R, ?> dependentResource, ReconcileResult<R> reconcileResult) {
    reconcileResults.put(dependentResource, reconcileResult);
  }

so the controller can actually put the dependent reconcile result to be retrived from the reconciler ?

dependents.forEach(dependent -> context.managedDependentResourceContext()
    .setReconcileResult(dependent, dependent.reconcile(resource, context)));

I think there is an ongoing discussion to have a better API around the untyped get/put methods but I don't remember where.

[csviri]

Yes, this should be possible, especially with after other PR with named managed dependent resources.
#1058
cc @metacosm

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.