XML

Word

Printable

Type: Story
Resolution: Done
Priority: Minor
Fix Version/s: Primaza 0.1
Affects Version/s: None
Component/s: Service Binding
Labels:
None

Story Points:
3
Blocked:
False
Blocked Reason:
None
Ready:
False
Epic Link:
Register Primaza Clusters
Testing Instructions:

Hide

    Scenario: Service Bindings are pushed to new Cluster Environments' application namespaces
        Given Primaza Cluster "main" is running
        And Worker Cluster "worker" for "main" is running
        And Clusters "main" and "worker" can communicate
        And On Primaza Cluster "main", Worker "worker"'s ClusterContext secret "primaza-kw" is published
        And On Worker Cluster "worker", application namespace "applications" exists
        And On Primaza Cluster "main", Resource is created
        """
        apiVersion: primaza.io/v1alpha1
        kind: ClusterEnvironment
        metadata:
            name: worker
            namespace: primaza-system
        spec:
            environmentName: dev
            clusterContextSecret: primaza-kw
        """
        And On Primaza Cluster "main", ClusterEnvironment "worker" state will eventually move to "Online"
        And On Primaza Cluster "main", ClusterEnvironment "worker" status condition with Type "Online" has Status "True"
        And On Primaza Cluster "main", ClusterEnvironment "worker" status condition with Type "ApplicationNamespacePermissionsRequired" has Status "False"
        And On Primaza Cluster "main", ClusterEnvironment "worker" status condition with Type "ServiceNamespacePermissionsRequired" has Status "False"
        And On Primaza Cluster "main", Resource is created
        """
        apiVersion: primaza.io/v1alpha1
        kind: RegisteredService
        metadata:
          name: primaza-rsdb
          namespace: primaza-system
        spec:
          serviceClassIdentity:
            - name: type
              value: psqlserver
            - name: provider
              value: aws
          serviceEndpointDefinition:
            - name: host
              value: mydavphost.io
            - name: port
              value: "5432"
            - name: user
              value: davp
            - name: password
              value: quedicelagente
            - name: database
              value: davpdata
          sla: L3
          """
        And On Primaza Cluster "main", RegisteredService "primaza-rsdb" state will eventually move to "Available"
        When On Primaza Cluster "main", Resource is created
        """
        apiVersion: primaza.io/v1alpha1
        kind: ServiceClaim
        metadata:
          name: sc-test
          namespace: primaza-system
        spec:
          serviceClassIdentity:
          - name: type
            value: psqlserver
          - name: provider
            value: aws
          serviceEndpointDefinitionKeys:
          - host
          - port
          - user
          - password
          - database
          environmentTag: dev
          application:
            kind: Deployment
            apiVersion: apps/v1
            selector:
              matchLabels:
                a: b
                c: d
        """
        When On Primaza Cluster "main", Resource is updated
        """
        apiVersion: primaza.io/v1alpha1
        kind: ClusterEnvironment
        metadata:
            name: worker
            namespace: primaza-system
        spec:
            environmentName: dev
            clusterContextSecret: primaza-kw
            applicationNamespaces:
            - applications
        """
        Then On Worker Cluster "worker", Service Binding "sc-test" exists in "applications"

    Scenario: Service Bindings are pushed to application namespaces of new Cluster Environments

Show
    Scenario: Service Bindings are pushed to new Cluster Environments' application namespaces         Given Primaza Cluster "main" is running         And Worker Cluster "worker" for "main" is running         And Clusters "main" and "worker" can communicate         And On Primaza Cluster "main", Worker "worker"'s ClusterContext secret "primaza-kw" is published         And On Worker Cluster "worker", application namespace "applications" exists         And On Primaza Cluster "main", Resource is created         """         apiVersion: primaza.io/v1alpha1         kind: ClusterEnvironment         metadata:             name: worker             namespace: primaza-system         spec:             environmentName: dev             clusterContextSecret: primaza-kw         """         And On Primaza Cluster "main", ClusterEnvironment "worker" state will eventually move to "Online"         And On Primaza Cluster "main", ClusterEnvironment "worker" status condition with Type "Online" has Status "True"         And On Primaza Cluster "main", ClusterEnvironment "worker" status condition with Type "ApplicationNamespacePermissionsRequired" has Status "False"         And On Primaza Cluster "main", ClusterEnvironment "worker" status condition with Type "ServiceNamespacePermissionsRequired" has Status "False"         And On Primaza Cluster "main", Resource is created         """         apiVersion: primaza.io/v1alpha1         kind: RegisteredService         metadata:           name: primaza-rsdb           namespace: primaza-system         spec:           serviceClassIdentity:             - name: type               value: psqlserver             - name: provider               value: aws           serviceEndpointDefinition:             - name: host               value: mydavphost.io             - name: port               value: "5432"             - name: user               value: davp             - name: password               value: quedicelagente             - name: database               value: davpdata           sla: L3           """         And On Primaza Cluster "main", RegisteredService "primaza-rsdb" state will eventually move to "Available"         When On Primaza Cluster "main", Resource is created         """         apiVersion: primaza.io/v1alpha1         kind: ServiceClaim         metadata:           name: sc-test           namespace: primaza-system         spec:           serviceClassIdentity:           - name: type             value: psqlserver           - name: provider             value: aws           serviceEndpointDefinitionKeys:           - host           - port           - user           - password           - database           environmentTag: dev           application:             kind: Deployment             apiVersion: apps/v1             selector:               matchLabels:                 a: b                 c: d         """         When On Primaza Cluster "main", Resource is updated         """         apiVersion: primaza.io/v1alpha1         kind: ClusterEnvironment         metadata:             name: worker             namespace: primaza-system         spec:             environmentName: dev             clusterContextSecret: primaza-kw             applicationNamespaces:             - applications         """         Then On Worker Cluster "worker", Service Binding "sc-test" exists in "applications"     Scenario: Service Bindings are pushed to application namespaces of new Cluster Environments
Git Pull Request:
https://github.com/primaza/primaza/pull/74
Intelligence Requested:
Market:

Sprint:
AppSvc Sprint 233

SFDC Cases Links:
SFDC Cases Counter:
SFDC Cases Open:

Owner: Architect:

Francesco Ilario

Story (Required)

As a Primaza Developer, I would like Primaza to push Service Bindings in application namespaces on Cluster Environment creation and update so that I will have Service Bindings in new application namespaces

Background (Required)

A namespace can be added to a Cluster Environment's application namespaces list after that several Service Bindings are created.
It is hence needed to push all matching Service Bindings to the application namespace.

See epic for arch document link.

Glossary

See glossary in architecture document

Out of scope

In Scope

Reconcile Service Bindings

Approach(Required)

When a creation or update event on a Cluster Environment occurs, its application namespaces should be reconciled.
For each application namespace, matching Service Bindings should be pushed.
If the Service Binding already exists in the namespace, the error should be ignored.

Demo requirements(Required)

Dependencies

Edge Case

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
ClusterEnvironment controller pushes matching Service Bindings to all application namespaces during reconciliation

QE
There are test cases for application namespace initialization that checks for Service Bindings existence

Docs
There is Section in our docs dedicated to explaining application namespaces initialization
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

Assignee:: Kartikey Mamgain (Inactive)

Reporter:: Francesco Ilario

Votes:: 0 Vote for this issue

Watchers:: 2 Start watching this issue

Created:: 2023/03/01 11:42 AM

Updated:: 2023/03/22 3:54 PM

Resolved:: 2023/03/22 3:54 PM

Details

Description