Uploaded image for project: 'Service Binding'
  1. Service Binding
  2. APPSVC-300

[SBO] Extended Deletion

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Obsolete
    • Icon: Undefined Undefined
    • None
    • None
    • Service Binding
    • None

      In the current implementation (APPSVC-251), the operator is re-issuing the binding plan in order to achieve unbinding. The steps taken to bind are simply undone. However, there's a drawback on doing so, if the plan is changed between creation and deletion, we may leave SBO annotations behind.

      For example, consider the use-case the backing service operator has updated OLM metadata, and decided that a given ConfigMap is not needed in the new version. The SBR was issued before OLM changes, therefore, the ConfigMap has annotations to identify it's part of a SBR. Also after OLM changes, the SBR is removed, and therefore it won't be able to identify the ConfigMap since it's not part of OLM plans anymore.

      Design Change

      As a suggestion, we could come up with a data-structure to be used in SBR's status field, and accumulate the total list of resources in the status field. Therefore, unbinding would be done via inspecting the status, instead of re-planing.

      Acceptance Criteria

      Have a project PR containing:

      • Design changes;
      • Documentation accordingly;
      • Tests to cover new design implementation;

              Unassigned Unassigned
              olemefer Otávio Fernandes
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: