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

Implement the label selector feature as per the spec 1.0

    • 8
    • False
    • None
    • False
    • Hide
      Before this update, service bindings that used label selectors to pick up workloads did not project service binding data into the new workloads that matched the given label selectors. As a result, the Service Binding Operator could not periodically bind such new workloads. With this update, service bindings now project service binding data into the new workloads that match the given label selector. The Service Binding Operator now periodically attempts to find and bind such new workloads.
      Show
      Before this update, service bindings that used label selectors to pick up workloads did not project service binding data into the new workloads that matched the given label selectors. As a result, the Service Binding Operator could not periodically bind such new workloads. With this update, service bindings now project service binding data into the new workloads that match the given label selector. The Service Binding Operator now periodically attempts to find and bind such new workloads.
    • AppSvc Sprint 216, AppSvc Sprint 217, AppSvc Sprint 218

      Owner: Architect:

      Story (Required)

      As a developer I will like my workloads with labels that match an SBO CR label selector to be bound even after the workloads are created after the SBO CR.

      Background (Required)

      Label Selector is a very flexible feature that allow a group of compute resources to be bound as a group. This will provide more value to SBO as it will simplify the service endpoint data projection for big applications that have many compute resources include custom compute resources. As long as developer label their compute resources and created the corresponding SBO CR with label selector as target for the workload. This will enable developer to even package the SBO CRs in their Helm Charts or Operators with the only variable being the target service CR they need to bind to.

      Glossary

      Out of scope

      In Scope

      Approach(Required)

      Once the SBO CR is created with a label selector we can start watching for all compute resources with that match the label selector on the current namespace. Kubernetes allows for filtering by labels when we watch: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#list-and-watch-filtering

      Dependencies

      Edge Case

      Acceptance Criteria

      All compute resources matching a specific label are bound.

      INVEST Checklist

      Dependencies identified
      Blockers noted and expected delivery timelines set
      Design is implementable
      Acceptance criteria agreed upon
      Story estimated

      Legend

      Unknown
      Verified
      Unsatisfied

            [APPSVC-1083] Implement the label selector feature as per the spec 1.0

            Jasper Chui added a comment -

            Review complete. Closing story. 

            Jasper Chui added a comment - Review complete. Closing story. 

            Was the performance test done on the PR? Any difference?

            David Peraza added a comment - Was the performance test done on the PR? Any difference?

            One open question I have: if a cluster administrator removes labels from a workload, so that it no longer matches a label selector of a service binding, SBO won't get notified of the change and won't remove projections.  Should I call this out under known issues, and should that be in upstream documentation as well as release notes?

            Andy Sadler added a comment - One open question I have: if a cluster administrator removes labels from a workload, so that it no longer matches a label selector of a service binding, SBO won't get notified of the change and won't remove projections.  Should I call this out under known issues, and should that be in upstream documentation as well as release notes?

            I've updated the PR with documentation for upstream.

            Andy Sadler added a comment - I've updated the PR with documentation for upstream.

            Jasper Chui - You have transitioned this issue to In Progress before specifying a priority. Please work with product management to set a priority.

            OpenShift Jira Bot added a comment - Jasper Chui - You have transitioned this issue to In Progress before specifying a priority. Please work with product management to set a priority.

            I consider this as a feature as the spec doesn't mandate to reconcile future resources

            Baiju Muthukadan added a comment - I consider this as a feature as the spec doesn't mandate to reconcile future resources

            Ask the spec team if this feature is necessary for spec compliance.

            Baiju Muthukadan added a comment - Ask the spec team if this feature is necessary for spec compliance.

              ansadler@redhat.com Andy Sadler
              dperaza@redhat.com David Peraza
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: