[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: To complete the pull request process, please ask for approval from baijum after the PR has been reviewed.

The full list of commands accepted by this bot can be found here.

<details open> Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":["baijum"]} -->

Fixes #897

@isutton SBO's deployment is service-binding-operator (https://github.com/redhat-developer/service-binding-operator/pull/913/checks?check_run_id=2804236225#step:8:72), however your detector in tests is looking for service-binding-operator-controller-manager

make deploy uses kustomize, which I could find a namePrefix field set to service-binding-operator-, resulting in a Deployment named service-binding-operator-controller-manager, as seen below:

$ kubectl -n service-binding-operator-system get all
NAME                                                               READY   STATUS              RESTARTS   AGE
pod/service-binding-operator-controller-manager-68fbd6f645-9grwz   0/1     ContainerCreating   0          4m37s

NAME                                               TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/service-binding-operator-webhook-service   ClusterIP   10.97.49.240   <none>        443/TCP   4m37s

NAME                                                          READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/service-binding-operator-controller-manager   0/1     1            0           4m37s

NAME                                                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/service-binding-operator-controller-manager-68fbd6f645   1         1         0       4m37s

To build the image, I've used make image OPERATOR_REGISTRY=$(minikube ip):5000 producing the image 192.168.49.2:5000/redhat-developer/servicebinding-operator:991bc81d, which looks correct. The image is being built using Minikube's Docker, which has been exposed by running eval $(minikube docker-env).

As seen in here WATCH_NAMESPACE is being set by default to the resource's namespace:

env:
- name: WATCH_NAMESPACE
  valueFrom:
    fieldRef:
      apiVersion: v1
      fieldPath: metadata.namespace

@pedjak If you do not oppose, I'll remove this configuration from manager.yaml.

The existing mappings on the ServiceBinding resource were introduced as a way to make it easier for a user to enrich an existing Secret into a form appropriate for binding to an application workload. This approch had a few issues that can be better addressed by other resources that interoperate with the ServiceBiding resource. The issues include:

• the ServiceBinding controller needs to be able to read and write Secrets
• Go templates were used to compose new values, which worked for basic templating, but were limited in their capabilities
• the capabilities of the Go templates are an implemenation detail of how the controller is built and could change over time independent of the speced behavior.

The behavior applied by mappings can be reintroduced as dedicated resources that can themselves expose a Secret as a ProvisionedService, which can be consumed by a ServiceBinding. This change further separates the concerns of provisioning a service from binding a service.

The .spec.type and .spec.provider fields are also removed, as they are syntactic sugar on top of mappings.

Refs #145 Resolves #155

Signed-off-by: Scott Andrews [email protected]

The Provisioned Service section of the README says:

The Secret data SHOULD contain a type entry with a value that identifies the abstract classification of the binding. 

The Application Projection section of the README says:

The Secret data MUST contain a type entry with a value that identifies the abstract classification of the binding.

The difference is between SHOULD and MUST convention.

On the classes.json documentation page, there is an example excerpt from a metadata file that includes "clefs", "noteheads", and "flags". However, in the table below, flags are not mentioned as a class defined by the spec.

The current spec supports an allow-list for containers to limit which containers in the application are bound. Sometimes a deny-list for containers would be more appropriate. The deny-list would limit which containers in the application are not bound. The allow-list could be mutually exclusive with the deny-list (only one of them exist). I propose to add .spec.application.skipContainers field to specify the deny-list for containers.

This can be added post 1.0 release in a backward-compatible way.

It would be awesome if we could get a strack trace for SIGSEGV signals. My docker container exits with exit code 139 / SIGSEV. However, there is no stack trace printed.

Code to reproduce:

var array: [Int] = []

let parallelQueue = DispatchQueue(label: "test", attributes: .concurrent)

parallelQueue.asyncAfter(deadline: .now() + 15) {
    for i in 0...100000 {
        array.append(i)
    }
}

parallelQueue.asyncAfter(deadline: .now() + 15) {
    for i in 0...100000 {
        array.append(i)
    }
}

Using Backtrace version 1.2.3.

ServiceBinding resource type schema has a .status.observedGeneration field:

...
status:
  binding:              # LocalObjectReference, optional
    name:               # string
  conditions:           # []metav1.Condition containing at least one entry for `Ready`
  observedGeneration:   # int64

But there is no normative text about the .status.observedGeneration field explaining its significance. Probably the spec should give some info about that field's usage pattern.

There was some comment about that field in the past here: https://github.com/k8s-service-bindings/spec/issues/126#issuecomment-710105155

@isutton SBO's deployment is most likely called controller-manager (https://github.com/redhat-developer/service-binding-operator/pull/913/files#diff-acdef1a63fe932b7de3c48f1a4fce36f79787a3f5b9136539c3d214491a27cacR4), however your detector in tests is looking for service-binding-operator-controller-manager (https://github.com/redhat-developer/service-binding-operator/pull/913/files#diff-6b43685101835ebb3b69db6de7d76eb64e396b3cdf560619630e0055d4c593b8R44) that is why it does not find it

The Collect Logs in GHA (the archived sbo.log) does not care about the particular name - it takes whatever is there (https://github.com/redhat-developer/service-binding-operator/blob/master/.github/workflows/pr-checks.yaml#L114) so that is why the log is fine.

motivation: 5.4 was released, add 5.4 CI

changes: add docker-compose setup for 5.4

• Created an "extensions" directory and moved the Secret Generation extension inside
• Created "extensions/README.md" with a brief introduction and a table of extensions (No., Title, and Status columns)
• Updated the extension with a brief introduction and status section

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: To complete the pull request process, please assign isutton after the PR has been reviewed. You can assign the PR to them by writing /assign @isutton in a comment when ready.

The full list of commands accepted by this bot can be found here.

<details open> Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":["isutton"]} -->

By and large, this is the issue with keeping placeholder content in the repo. It becomes murky as to what it means and why it exists.

What if we moved it into a directory named "extensions" and added a README.md that contained this paragraph?

One more sentence pointing to the release cycle:

Note: This spec is dependent on "Service Binding Specification for Kubernetes", but there is no direct association -- neither containment nor aggregation. Both specs are going to have their independent release cycles.

We can add a note. I need some help with phrasing it. Here is my attempt:

Note: This spec is dependent on "Service Binding Specification for Kubernetes", but there is no direct association -- neither containment nor aggregation.

Hi,

After a long covid-type delay I'm submitting the SSMN 01 font and a descriptive PDF. The license chosen is the CC Creative Commons. I hope that this font meets with your requirements.

Best, Emile Ellberger SSMN 01_ font and PDF.zip

it needs to be clear that this content is not a required part of the spec

There are a couple of options to proceed with testing the admission webhook in this PR:

I would suggest that we keep the scope of this PR focused and avoid spending time on crafting a superb dev experience, covering both CRC and Minikube. For local testing and for most of the cases, we can have an option to disable webhooks, so that we can still start a local process to connect to a cluster. Probably that could be also the default behaviour as well.

Otherwise, for running all acceptance tests, I would pick today option number 2, and work on improving over time. There is no need to use quay at all, if using minikube, we can use local cluster registry, and hence even run the tests without an internet connection. This is how our CI jobs are running tests even today, see:

https://github.com/redhat-developer/service-binding-operator/blob/4cf9811fe24804cc884ea0e2c2a83bd4cd065fd9/.github/workflows/pr-checks.yaml#L97

in case of CRC you can either use its local registry or have another registry running on your machine and use the same approach. IMHO, there is really no need to use CRC locally anymore, minikube works great and covers all our needs meanwhile.

cc @pmacik - wdyt?

We were bitten by https://github.com/golang/go/wiki/CommonMistakes#using-reference-to-loop-iterator-variable

Fixed the loop to use the new variable.

Fixes #966

What is the environment (Minikube, Openshift)?

minikube

What is the SBO version used?

v0.7.1

What are the steps to reproduce this issue?

1. deployed sample deployment and operator and operand into the same namespace called test

<details> <summary>deployment.yaml</summary>

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - command:
        - sleep
        - infinity
        image: busybox
        name: busybox

</details>

<details> <summary>operator.yaml</summary>

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: operatorgroup
  namespace: test
spec:
  targetNamespaces:
  - test
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: my-postgresql-operator-dev4devs-com
  namespace: test
spec:
  channel: alpha
  name: postgresql-operator-dev4devs-com
  source: operatorhubio-catalog
  sourceNamespace: olm

</details>

<details> <summary>operand.yaml</summary>

apiVersion: postgresql.dev4devs.com/v1alpha1
kind: Database
metadata:
  name: postgresql
  namespace: test
spec:
  databaseName: example
  databasePassword: postgres
  databaseStorageRequest: 1Gi
  databaseUser: postgres
  image: centos/postgresql-96-centos7
  size: 1

</details>

2. created SericeBinding with detectBindingResources: true

<details> <summary>binding.yaml</summary>

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  name: busybox-postgresql
  namespace: test
spec:
  application:
    group: apps
    name: busybox
    resource: deployments
    version: v1
  bindAsFiles: false
  detectBindingResources: true
  services:
    - group: postgresql.dev4devs.com
      kind: Database
      name: postgresql
      namespace: test
      version: v1alpha1

</details>

In my namespace, there are two Services

▶ k get svc
NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
postgresql                    ClusterIP   10.110.53.111   <none>        5432/TCP            14m
postgresql-operator-metrics   ClusterIP   10.99.217.236   <none>        8383/TCP,8686/TCP   14m

postgresql-operator-metrics Service has operator (Database.postgresql.dev4devs.com) as ownerReference

▶ k get svc postgresql-operator-metrics -o jsonpath="{.metadata.ownerReferences}" | jq
[
  {
    "apiVersion": "apps/v1",
    "blockOwnerDeletion": true,
    "controller": true,
    "kind": "Deployment",
    "name": "postgresql-operator",
    "uid": "8c11676c-fb8d-4881-8f71-ddcba37581f2"
  }
]

postgresql Service has operand (Database.postgresql.dev4devs.com) as ownerReference

▶ k get svc postgresql -o jsonpath="{.metadata.ownerReferences}" | jq                 
[
  {
    "apiVersion": "postgresql.dev4devs.com/v1alpha1",
    "blockOwnerDeletion": true,
    "controller": true,
    "kind": "Database",
    "name": "postgresql",
    "uid": "43149969-d701-460a-8566-4337cbe4cc50"
  }
]

What is the expected behaviour?

Deployment busybox has DATABASE_CLUSTERIP env variable containing IP address of the postgresql Service

What is the actual behaviour?

Deployment busybox has DATABASE_CLUSTERIP env variable containing IP address of the postgresql-operator-metrics Service which is not tied to the service defined in ServiceBinding

▶ k exec -it busybox-75fcb776bc-5m4hr -- env | grep CLUSTERIP                                         
DATABASE_CLUSTERIP=10.99.217.236

▶ k get svc
NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
postgresql                    ClusterIP   10.110.53.111   <none>        5432/TCP            14m
postgresql-operator-metrics   ClusterIP   10.99.217.236   <none>        8383/TCP,8686/TCP   14m

Service Binding Operator Logs

<details> <summary>logs</summary>

{"level":"info","ts":1621435172.1368315,"logger":"controller-runtime.metrics","msg":"metrics server is starting to listen","addr":":8080"}
{"level":"info","ts":1621435172.1373563,"logger":"setup","msg":"starting manager"}
{"level":"info","ts":1621435172.1376226,"logger":"controller-runtime.manager","msg":"starting metrics server","path":"/metrics"}
I0519 14:39:32.137605       1 leaderelection.go:243] attempting to acquire leader lease  operators/8fa65150.coreos.com...
I0519 14:39:32.143465       1 leaderelection.go:253] successfully acquired lease operators/8fa65150.coreos.com
{"level":"info","ts":1621435172.1436667,"logger":"controller","msg":"Starting EventSource","reconcilerGroup":"binding.operators.coreos.com","reconcilerKind":"ServiceBinding","controller":"servicebinding","source":"kind source: /, Kind="}
{"level":"info","ts":1621435172.2441118,"logger":"controller","msg":"Starting Controller","reconcilerGroup":"binding.operators.coreos.com","reconcilerKind":"ServiceBinding","controller":"servicebinding"}
{"level":"info","ts":1621435172.244153,"logger":"controller","msg":"Starting workers","reconcilerGroup":"binding.operators.coreos.com","reconcilerKind":"ServiceBinding","controller":"servicebinding","worker count":1}
{"level":"info","ts":1621436719.492417,"logger":"controllers.ServiceBinding","msg":"Reconciling","serviceBinding":"test/busybox-postgresql","sb":{"apiVersion":"binding.operators.coreos.com/v1alpha1","kind":"ServiceBinding","namespace":"test","name":"busybox-postgresql"}}
{"level":"info","ts":1621436720.3018339,"logger":"controllers.ServiceBinding","msg":"Done","serviceBinding":"test/busybox-postgresql","retry":false,"error":null}

</details>

There are a couple of options to proceed with testing the admission webhook in this PR:

1. Extract OpenShift's tls.key and tls.crt files to /tmp/k8s-webhook-server/serving-certs, which is the default location used by the ServiceBinding Operator (required to receive payloads from the API server).

   • Requires logic to extract tls.key and tls.crt files from vanilla Kubernetes.
   • Requires configuration to access the mutation webhook available outside the cluster.
   • Is it possible to use kubectl port-forward for this?
     • It might be possible that kubectl port-forward could help with this, as it is possible to define a specific service, although to be seen is whether it requires at least one active Pod available, or kube port-forward does work without a running Pod, making the client effectively a Pod of some sorts.

2. Build the image locally, push to quay.io and execute the tests using a remote instance of the ServiceBinding Operator initialized through make deploy.

   This workflow invokes the following operations, regardless if the build happens at the same physical host as the destination cluster: build -> push to remote -> pull from remote.

   This solution seems to be the least effort, but waste a lot of resources since even when testing on the same host, a roundtrip to quay.io is required. If this approach is chosen, must be considered technical debt and scheduled for further developments.

3. Build the image locally, and copy it to the destination cluster using skopeo; from what I've seen it can not copy or sync images from local Docker registry cache, only from the remote registry in the case --src docker is informed.

4. Do not rely on a Kubernetes or OpenShift cluster, and adapt the integration tests to use envtest instead.