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

Application Agent watches Service Bindings' resources

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Major Major
    • Primaza 0.1
    • None
    • Service Binding
    • None
    • 8
    • False
    • None
    • False
    • Hide
      Scenario: Service binding projection works for multiple applications matching the labels

          Given Primaza Cluster "main" is running
          And On Primaza Cluster "main", namespace "applications" exists
          And On Primaza Cluster "main", Primaza Application Agent is deployed into namespace "applications"
          And On Primaza Cluster "main", Resource is created
          """
          apiVersion: v1
          kind: Secret
          metadata:
              name: demo
              namespace: applications
          stringData:
              username: AzureDiamond
          """
          And On Primaza Cluster "main", Resource is created
          """
          apiVersion: primaza.io/v1alpha1
          kind: ServiceBinding
          metadata:
              name: application-binding
              namespace: applications
          spec:
              serviceEndpointDefinitionSecret: demo
              application:
                  apiVersion: apps/v1
                  kind: Deployment
                  selector:
                      matchLabels:
                          app: myapp
          """
          And On Primaza Cluster "main", ServiceBinding "application-binding" on namespace "applications" state will eventually move to "Ready"
          When On Primaza Cluster "main", test application "applicationone" is running in namespace "applications"
          Then On Primaza Cluster "main", in demo application's pod running in namespace "applications" file "/bindings/application-binding/username" has content "AzureDiamond"
      Show
      Scenario: Service binding projection works for multiple applications matching the labels     Given Primaza Cluster "main" is running     And On Primaza Cluster "main", namespace "applications" exists     And On Primaza Cluster "main", Primaza Application Agent is deployed into namespace "applications"     And On Primaza Cluster "main", Resource is created     """     apiVersion: v1     kind: Secret     metadata:         name: demo         namespace: applications     stringData:         username: AzureDiamond     """     And On Primaza Cluster "main", Resource is created     """     apiVersion: primaza.io/v1alpha1     kind: ServiceBinding     metadata:         name: application-binding         namespace: applications     spec:         serviceEndpointDefinitionSecret: demo         application:             apiVersion: apps/v1             kind: Deployment             selector:                 matchLabels:                     app: myapp     """     And On Primaza Cluster "main", ServiceBinding "application-binding" on namespace "applications" state will eventually move to "Ready"     When On Primaza Cluster "main", test application "applicationone" is running in namespace "applications"     Then On Primaza Cluster "main", in demo application's pod running in namespace "applications" file "/bindings/application-binding/username" has content "AzureDiamond"
    • AppSvc Sprint 236, AppSvc Sprint 237

      Owner: Architect:

      Francesco Ilario

      Story (Required)

      As a Primaza Administrator,
      I would like Application Agent to watch for new deployments/pods matching Service Bindings' labels
      so that it can bind workloads created after Service Binding

      Background (Required)

      As defined in the Primaza architecture document, we can select workloads to bind to a service by using a label selector.
      Workloads that matches a label selector may also be created after the Service Binding is created.
      The Application Agent should be able to bind the new workloads to the services.

      See epic for arch document link.

      Glossary

      See glossary in architecture document

      Out of scope

      NA

      In Scope

      • Label matching of new workloads

      Approach(Required)

      When a Service Binding is created, if the label selector matching mechanism is used, a watcher for the Service Binding's workload and labels must be registed too.
      When a watched resource is created, it should be bound to the Service Binding's Secret.
      For watching resoruces it may be used the DynamicInformer. An example of implementation can be found here.

      Demo requirements(Required)

      NA

      Dependencies

      NA

      Edge Case

      NA

      BDD Tests

      You can find BDD Test specification for this story in the "Testing Instruction" Field Tab or in the GitHub Issue linked to this story.
      Click here for all BDD Tests Issues.

      Acceptance Criteria

      • Development
        Service Agent binds ServiceBinding's label selector filtered workloads created after the ServiceBinding itself
      • QE
        There are test cases for binding of matching workloads created after ServiceBinding
      • Docs
        There is a section in our Application Agent docs dedicated to explaining how it monitors resources matching Service Bindings
        Update architecture document with any changes while implementing

      INVEST Checklist

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

      Legend

      Unknown
      Verified
      Unsatisfied

              kmamgain@redhat.com Kartikey Mamgain (Inactive)
              rh-ee-filario Francesco Ilario
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: