Change API Group and Kind, and Spec #495

sbose78 · 2020-05-27T04:15:50Z

TLDR;

This is how the new CR looks like

---
apiVersion: operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  name: example-servicebinding
  namespace: sbose
spec:
  services:
    - name: demo-database
      group: postgresql.baiju.dev
      kind: Database
      version: v1alpha1

  application:
    name: nodejs-rest-http-crud
    group: apps
    version: v1
    resource: deployments

NOTE: I've used the operators.coreos.com API Group for the time-being since we are in discussions with the OLM team on moving this project to github.com/operator-framework . However, folks are open to using a different API Group too. While I don't want to deviate too much, I am considering using an OperatorFramework-ish group & kind. Suggestions welcome! :)

What should you review?

You don't really need to start looking at all 80+ files changed.
This file is what you need to be look at, to begin with: servicebinding_types.go

Motivation

Primarily

Align the ServiceBinding API with the Proposal which also takes into account the new specification.
Open up the API for review by the OLM team. ( There's no point doing an API review for the API which is in master since it was going to change )

Also ..

Standardize use of Golang Kubernetes APIs. Example, used corev1.LocalObjectReference instead of name wherever application.

Changes

Set a Group and Kind which is Kubernetes / OperatorFramework friendly.

apiVersion: operators.coreos.com/v1alpha1
kind: ServiceBinding

Removed spec.backingServiceSelector
Replaced spec.applicationSelector with spec.application,
Using Application *Application instead of Application Application ( feedback by OLM team )
Using DetectBindingResources *bool instead of DetectBindingResources bool ( feedback by OLM team )
Replaced spec.backingServiceSelectors with spec.services
Replaced spec.customEnvVar with spec.dataMapping <--- we don't have agreement on this, we may keep this as is.
Replaced resourceRef in application and services to name corev1.LocalObjectReference
PENDING: The Application type has a label selector and a LocalObjectReference do I need to set a name and then use a label selector? I think that these should be a union type
PENDING: Change spec.application ( Application ) to spec.applications ( []Application ). To do so without breaking changes ini add extraFieldsModifier to binder #426 , some amount of refactoring is needed.

Pre-merge checklist

Update docs and samples scenarios
Safe to freeze new community operator releases to let the UI catch up.
Finalize API Group ( see NOTE in the motivation section )
CRD Spec Reviewed by OLM team

Testing

No extra tests added. Ensured existing ones work!
Validated manually by creating a binding between a nodejs app & Database.

openshift-ci-robot · 2020-05-27T04:15:55Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

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

sbose78 · 2020-05-27T04:28:08Z

@lanceliuu Could you see my comment in the pre-merge checklist above. I would need your assistance in refactoring that feature to be able to support multiple applications. A PR would be nice :)

sbose78 · 2020-05-27T04:43:28Z

Should we use corev1.LocalObjectReference for spec.services.name? Doing so feels right since a standard Kubernetes API is being used, but at the same time, the CRD validation schema doesn't mark it as required.

services:
    - name: demo-database <--- corev1.LocalObjectReference
      group: postgresql.baiju.dev
      kind: Database
      version: v1alpha1

LocalObjectReference struct {
    // Name of the referent.
    // More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
    // TODO: Add other useful fields. apiVersion, kind, uid?
    // +optional
    Name string `json:"name,omitempty" protobuf:"bytes,1,opt,name=name"`
}

Suggestions ?

baijum · 2020-05-27T04:47:08Z

NOTE: I've used the operators.coreos.com Group for the time-being since we are in discussions with the OLM team to moving this project to github.com/operator-framework . However, folks are open to use a different Group and Kind too. While I don't want to deviate too much, I am considering using an OperatorFramework-ish group & kind. Suggestions welcome! :)

Issue #364 is discussing the same, right? I thought we decided to use service.binding group based on the discussion there.

sbose78 · 2020-05-27T04:56:25Z

@baijum Correct, we could end up using service.binding as the group as well.

However, groups tend to be upstream or downstream organization / technology specific and service.binding is neither. operators.coreos.com is currently the Operator Framework org widely in use. I'd like to see if we can get any alignment.

codecov · 2020-05-27T05:15:54Z

Codecov Report

Merging #495 into master will decrease coverage by 0.12%.
The diff coverage is 78.57%.

@@            Coverage Diff             @@
##           master     #495      +/-   ##
==========================================
- Coverage   63.07%   62.95%   -0.13%     
==========================================
  Files          27       27              
  Lines        1774     1768       -6     
==========================================
- Hits         1119     1113       -6     
  Misses        489      489              
  Partials      166      166

Impacted Files	Coverage Δ
...ntroller/servicebinding/annotations/annotations.go	`0.00% <ø> (ø)`
...controller/servicebinding/annotations/attribute.go	`80.00% <ø> (ø)`
...ntroller/servicebinding/annotations/bindinginfo.go	`88.23% <ø> (ø)`
...controller/servicebinding/annotations/configmap.go	`85.71% <ø> (ø)`
...kg/controller/servicebinding/annotations/errors.go	`0.00% <ø> (ø)`
.../controller/servicebinding/annotations/resource.go	`65.65% <ø> (ø)`
...kg/controller/servicebinding/annotations/secret.go	`69.23% <ø> (ø)`
pkg/controller/servicebinding/common.go	`29.41% <ø> (ø)`
pkg/controller/servicebinding/controller.go	`0.00% <ø> (ø)`
pkg/controller/servicebinding/custom_env_parser.go	`80.95% <ø> (ø)`
... and 16 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a3e812b...b4dc1ab. Read the comment docs.

Avni-Sharma · 2020-05-27T09:40:58Z

Should we use corev1.LocalObjectReference for spec.services.name? Doing so feels right since a standard Kubernetes API is being used, but at the same time, the CRD validation schema doesn't mark it as required.
services:
    - name: demo-database <--- corev1.LocalObjectReference
      group: postgresql.baiju.dev
      kind: Database
      version: v1alpha1
LocalObjectReference struct {
    // Name of the referent.
    // More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
    // TODO: Add other useful fields. apiVersion, kind, uid?
    // +optional
    Name string `json:"name,omitempty" protobuf:"bytes,1,opt,name=name"`
}
Suggestions ?

Name is required so IMO we should keep it as is, unless we have any scenario where it is optional

pkg/apis/apps/v1alpha1/servicebinding_types.go

DhritiShikhar · 2020-05-27T14:50:25Z

pkg/apis/apps/v1alpha1/servicebinding_types.go

+// Service defines the selector based on resource name, version, and resource kind
+type Service struct {
+	metav1.GroupVersionKind     `json:",inline"`
+	corev1.LocalObjectReference `json:",inline"`


We have LabelSelector for Service.
Let's have it for Services as well. We do support multiple services.

Wondering if that might affect the way we are:

referring to backing services in custom env var.

using env prefixes per service.

DhritiShikhar · 2020-05-27T14:51:23Z

pkg/apis/apps/v1alpha1/servicebinding_types.go

 	// +optional
 	LabelSelector               *metav1.LabelSelector `json:"labelSelector,omitempty"`
 	metav1.GroupVersionResource `json:",inline"`
-	ResourceRef                 string `json:"resourceRef,omitempty"`
+	corev1.LocalObjectReference `json:",inline"`


Isn't this // +optional as well? In case when LabelSelector is being used.

Yeah, the content of the struct is actually optional

LocalObjectReference struct { // Name of the referent. // More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names // TODO: Add other useful fields. apiVersion, kind, uid? // +optional Name string `json:"name,omitempty" protobuf:"bytes,1,opt,name=name"` }

We could bubble up the information at this Application struct level too though.

DhritiShikhar · 2020-05-27T14:59:20Z

pkg/apis/apps/v1alpha1/servicebinding_types.go

-	ResourceRef             string `json:"resourceRef"`
+// Service defines the selector based on resource name, version, and resource kind
+type Service struct {
+	metav1.GroupVersionKind     `json:",inline"`


We can remove metav1.GroupVersionKind and just have corev1.TypedLocalObjectReference.

// TypedLocalObjectReference contains enough information to let you locate the // typed referenced object inside the same namespace. type TypedLocalObjectReference struct { // APIGroup is the group for the resource being referenced. // If APIGroup is not specified, the specified Kind must be in the core API group. // For any other third-party types, APIGroup is required. // +optional APIGroup *string `json:"apiGroup" protobuf:"bytes,1,opt,name=apiGroup"` // Kind is the type of resource being referenced Kind string `json:"kind" protobuf:"bytes,2,opt,name=kind"` // Name is the name of resource being referenced Name string `json:"name" protobuf:"bytes,3,opt,name=name"` }

That is an excellent idea. We could use it for Services only though. Since name is optional in Applications , we'll not be able to use TypedLocalObjectReference.

..umm.. but APIGroup *string isn't supposed to accept the Version

for services we need group version and Kind, corev1.TypedLocalObjectReference will indeed not give the Version

Moreover corev1.TypedLocalObjectReference is for the same namespace and we can have services in different namespaces

Perhaps corev1.ObjectReference can be a good fit, since it has both Namespace and APIVersion members?

Regardless, can you clarify the importance of the API version in this particular case?

I gave it a shot here #495 (comment)

pkg/controller/servicebinding/reconciler.go

pkg/controller/servicebinding/binder.go

pedjak · 2020-05-27T10:01:10Z

Makefile

@@ -358,13 +358,13 @@ deploy-rbac:
 .PHONY: deploy-crds
 ## Deploy-CRD: Deploy CRD
 deploy-crds:
-	$(Q)kubectl apply -f deploy/crds/apps.openshift.io_servicebindingrequests_crd.yaml
+	$(Q)kubectl apply -f deploy/crds/operators.coreos.com_servicebindings_crd.yaml


could we make this a bit more name agnostic, and avoid future changes as well:

$(Q)kubectl apply -f deploy/crds/*_crd.yaml

pedjak · 2020-05-27T10:01:34Z

Makefile


 .PHONY: deploy-clean
 ## Deploy-Clean: Removing CRDs and CRs
 deploy-clean:
-	$(Q)-kubectl delete -f deploy/crds/apps_v1alpha1_servicebindingrequest_cr.yaml
-	$(Q)-kubectl delete -f deploy/crds/apps.openshift.io_servicebindingrequests_crd.yaml
+	$(Q)-kubectl delete -f deploy/crds/operators.coreos.com_servicebindings_cr.yaml


same question as above

would you also consider extracting operators.coreos.com in a variable and use it consistently across Makefile? It would make later updates easier.

pedjak · 2020-05-27T10:05:24Z

Makefile

@@ -414,7 +414,7 @@ endif
 ## Copy crd from deploy/crds to manifests-upstream/
 consistent-crds-manifests-upstream:
 	$(Q)cd ./manifests-upstream/${OPERATOR_VERSION}/ && ln -srf ../../deploy/crds/apps_v1alpha1_servicebindingrequest_crd.yaml \


this line should be updated as well, since apps_v1alpha1_servicebindingrequest_crd.yaml is getting renamed.

pedjak · 2020-05-27T14:32:29Z

deploy/crds/operators.coreos.com_servicebindings_cr.yaml

@@ -0,0 +1,18 @@
+---


The PR diff and later git history would look nicer if we rename the files using git mv ... command, and then apply the necessary changes/ With that git will able to understand that operators.coreos.com_servicebindings_cr.yaml is the successor of apps_v1alpha1_servicebindingrequest_cr.yaml , and all pending PRs that might contain changes to the old file would be applied correctly to the new one.

pedjak · 2020-05-27T14:40:55Z

pkg/apis/apps/v1alpha1/servicebinding_types.go


 	// DetectBindingResources is flag used to bind all non-bindable variables from
 	// different subresources owned by backing operator CR.
 	// +optional
 	DetectBindingResources bool `json:"detectBindingResources,omitempty"`
 }

-// ServiceBindingRequestStatus defines the observed state of ServiceBindingRequest
+// ServiceBindingStatus defines the observed state of ServiceBindingStatus


ServiceBindingStatus defines the observed state of ServiceBindingStatus

you have a loop here :) It should be ServiceBindingStatus defines the observed state of ServiceBinding

Haha, done, here you go

pkg/apis/apps/v1alpha1/servicebinding_types.go

pedjak · 2020-05-27T14:57:42Z

pkg/apis/apps/v1alpha1/servicebinding_types.go

+	metav1.GroupVersionKind     `json:",inline"`
+	corev1.LocalObjectReference `json:",inline"`
+	EnvVarPrefix                *string `json:"envVarPrefix,omitempty"`


could you provide description for these fields? Could we replace metav1.GroupVersionKind and corev1.LocalObjectReference with corev1.ObjectReference perhaps? That would open up a possibility to refer Services in a different namespace, if needed.

Yes, we could. @DhritiShikhar provided similar feedback 👍 .

Sorry, Dhriti had a slightly different feedback.
#495 (comment)

Made an attempt to use corev1.ObjectReference but I see all the important fields ( Kind, Name, APIVersion) are optional.

The only option I see is to use the metav1.TypeMeta in combination with name/corev1.LocalObjectReference.

+1 for metav1.TypeMeta as it has APIVersion instead of separate group and version.

Please consider this as well: kubernetes/community#4705.

Would we use

Group, Version, Resource for an application but
*APIVersion & Kind for a service ?

@redhat-developer/service-binding Could you please chip in?

Please consider this as well: kubernetes/community#4705.

@isutton Would do you have a specific recommendation with regards to this ?

in role.yaml we define the resources on which we can perform the CRUD actions, a GVK is not specified. Since we edit/update the deployment with the envFrom: secretRef, we should use GVR schema when referring applications instead of GVK, IMO. From services we just collect information, not perform any update on it.

Avni-Sharma · 2020-05-28T08:31:06Z

pkg/controller/servicebinding/reconciler_test.go

@@ -50,7 +50,7 @@ func TestApplicationSelectorByName(t *testing.T) {
 	backingServiceResourceRef := "backingServiceRef"
 	applicationResourceRef := "applicationRef"
 	f := mocks.NewFake(t, reconcilerNs)
-	f.AddMockedUnstructuredServiceBindingRequest(reconcilerName, backingServiceResourceRef, applicationResourceRef, deploymentsGVR, nil)
+	f.AddMockedUnstructuredServiceBinding(reconcilerName, backingServiceResourceRef, applicationResourceRef, deploymentsGVR, nil)


We might want to log an issue for changes in variable names passed to mock functions. Not necessarily to be addressed in this PR

Some of the variable names could remain, they might make things more expressive?

DhritiShikhar · 2020-05-28T08:53:21Z

pkg/apis/apps/v1alpha1/servicebinding_types.go

+	Secret corev1.LocalObjectReference `json:"secretRef"`
+	// ApplicationObjects contains all the application objects filtered by label
+	// +optional
+	Applications []BoundApplication `json:"applications,omitempty"`


Since we cannot bind to more than one application now, we should not have a list here.

@DhritiShikhar it is possible to have more than one application even if you can only declare one entry in spec.application.

Application embeds metav1.LabelSelector as follows:

// Application defines the selector based on labels and GVR type Application struct { // +optional LabelSelector *metav1.LabelSelector `json:"labelSelector,omitempty"` metav1.GroupVersionResource `json:",inline"` corev1.LocalObjectReference `json:",inline,omitempty"` }

It is then used in Binder.search() to list all resources matching the given GVR in the given namespace:

objects, err := b.dynClient.Resource(gvr).Namespace(ns).List(opts) if err != nil { return nil, ApplicationNotFound }

This call to List() can return multiple resources if multiple resources exist with labels declared in spec.application.matchLabels.

xliuxu · 2020-05-28T09:34:46Z

@sbose78 Sure. I will pick up the item changing Application to []Application

navidsh · 2020-05-28T12:06:02Z

pkg/controller/servicebinding/servicebinder.go

@@ -26,13 +26,13 @@ const (
 	// BindingFail binding has failed
 	BindingFail = "BindingFail"
 	//Finalizer annotation used in finalizer steps
-	Finalizer = "finalizer.servicebindingrequest.openshift.io"
+	Finalizer = "finalizer.servicebinding.openshift.io"


Thoughts on finalizer.servicebinding.openshift.io -> finalizer.servicebinding.operators.coreos.com?

Being fixed in 5f8ae1e , thanks.

navidsh · 2020-05-28T12:24:40Z

pkg/apis/apps/v1alpha1/servicebinding_types.go

+
+	// DataMapping is used to map CR/CSV/CRD attributes to Custom env variables
+	// +optional
+	DataMapping []corev1.EnvVar `json:"dataMapping,omitempty"`


Since DataMapping is a list, should it be plural (DataMappings)?

Shall we revisit this rename?

The reason for this is is the input is a map of environment variable names and templates and its output are rendered environment variables, which makes it much closer to customEnvVars than dataMapping.

Sure! I don't mind revisiting the name

examples/java_postgresql_customvar/README.md

navidsh · 2020-05-28T13:37:22Z

.../service-binding-operator/0.0.23/service-binding-operator.v0.0.23.clusterserviceversion.yaml

@@ -5,19 +5,19 @@ metadata:
    alm-examples: |-
      [
        {
-          "apiVersion": "apps.openshift.io/v1alpha1",


Is the version going to remain as 0.0.23?

This, I think is the template, but the version probably isn't used anywherre.

navidsh · 2020-05-28T13:38:12Z

.../service-binding-operator/0.0.23/service-binding-operator.v0.0.23.clusterserviceversion.yaml

              "group": "apps",
              "resource": "deployments",
              "resourceRef": "nodejs-rest-http-crud",
              "version": "v1"
            },
-            "backingServiceSelector": {
+            "services": {


This should be updated to reflect that services is an array

Fixed in 67cd32c

examples/knative_postgresql_customvar/README.md

examples/knative_postgresql_customvar/service-binding-request.yaml

examples/java_postgresql_customvar/README.md

examples/nodejs_postgresql/README.md

sbose78 · 2020-06-03T19:58:17Z

@pedjak Thanks for the review, I'll get to your review comment shortly after I'm done handling the API changes!

openshift-ci-robot · 2020-06-06T11:31:27Z

@sbose78: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

openshift-ci-robot · 2020-06-16T20:03:19Z

@sbose78: The following tests failed, say /retest to rerun all failed tests:

Test name	Commit	Details	Rerun command
ci/prow/4.5-unit	`68a7dea`	link	`/test 4.5-unit`
ci/prow/4.5-e2e	`68a7dea`	link	`/test 4.5-e2e`
ci/prow/4.5-lint	`68a7dea`	link	`/test 4.5-lint`
ci/prow/e2e	`68a7dea`	link	`/test e2e`
ci/prow/unit	`68a7dea`	link	`/test unit`
ci/prow/lint	`68a7dea`	link	`/test lint`

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

sbose78 · 2020-06-16T20:40:58Z

I've summarized the changes in CHANGES section which contains feedback from OLM team.

Set a Group and Kind which is Kubernetes / OperatorFramework friendly.

apiVersion: operators.coreos.com/v1alpha1
kind: ServiceBinding

Removed spec.backingServiceSelector
Replaced spec.applicationSelector with spec.application,
Using Application *Application instead of Application Application ( feedback by OLM team )
Using DetectBindingResources *bool instead of DetectBindingResources bool ( feedback by OLM team )
Replaced spec.backingServiceSelectors with spec.services
Replaced spec.customEnvVar with spec.dataMapping <--- we don't have agreement on this, we may keep this as is.
Replaced resourceRef in application and services to name corev1.LocalObjectReference
PENDING: The Application type has a label selector and a LocalObjectReference do I need to set a name and then use a label selector? I think that these should be a union type
PENDING: Change spec.application ( Application ) to spec.applications ( []Application ). To do so without breaking changes ini add extraFieldsModifier to binder #426 , some amount of refactoring is needed.

The objective of this PR was to gather feedback from internal/external stakeholders. The objective has been met and summarized here in this comment and the Description. I'm closing the PR and letting the team take up the work to implement these in a separate PR.

Update API Group and Kind, update attributes

7ab0937

openshift-ci-robot requested review from Avni-Sharma and baijum May 27, 2020 04:15

undo openshift api group update

48b322f

sbose78 requested review from pedjak, akashshinde, DhritiShikhar and isutton May 27, 2020 04:47

DhritiShikhar reviewed May 27, 2020

View reviewed changes

pkg/apis/apps/v1alpha1/servicebinding_types.go Outdated Show resolved Hide resolved

DhritiShikhar reviewed May 27, 2020

View reviewed changes

pkg/apis/apps/v1alpha1/servicebinding_types.go Outdated Show resolved Hide resolved

sbose78 mentioned this pull request May 27, 2020

Rename to "applications" and "services" #348

Closed

DhritiShikhar reviewed May 27, 2020

View reviewed changes

pkg/controller/servicebinding/reconciler.go Outdated Show resolved Hide resolved

DhritiShikhar reviewed May 27, 2020

View reviewed changes

pkg/controller/servicebinding/reconciler.go Show resolved Hide resolved

DhritiShikhar reviewed May 27, 2020

View reviewed changes

pkg/controller/servicebinding/binder.go Show resolved Hide resolved

pedjak reviewed May 27, 2020

View reviewed changes

sbose78 added 5 commits May 27, 2020 17:06

docs & tags

c3f19b1

resolve conflict

6176e17

make services mandatory

4463f52

udpate openapi schema to make services required

9356c40

update secretName desription

97a73ba

Avni-Sharma reviewed May 28, 2020

View reviewed changes

DhritiShikhar reviewed May 28, 2020

View reviewed changes

navidsh reviewed May 28, 2020

View reviewed changes

examples/java_postgresql_customvar/README.md Outdated Show resolved Hide resolved

navidsh reviewed May 28, 2020

View reviewed changes

examples/knative_postgresql_customvar/README.md Show resolved Hide resolved

navidsh reviewed May 28, 2020

View reviewed changes

examples/knative_postgresql_customvar/service-binding-request.yaml Outdated Show resolved Hide resolved

isutton suggested changes May 28, 2020

View reviewed changes

examples/java_postgresql_customvar/README.md Outdated Show resolved Hide resolved

examples/nodejs_postgresql/README.md Outdated Show resolved Hide resolved

openshift-ci-robot added the needs-rebase label May 30, 2020

sbose78 added 2 commits June 3, 2020 14:32

resolve conflicts

62ac6e2

resolve conflict

7cd407d

openshift-ci-robot removed the needs-rebase label Jun 3, 2020

sbose78 added 7 commits June 3, 2020 15:11

vendor changes

f9377ba

update name of finalizer

5f8ae1e

rename to secretRef

9b3f3d4

fix csv example

ae587fc

fix docs

5fc6187

fix erroneous replacements in docs

0c7f9c2

fix example

67cd32c

openshift-ci-robot added the needs-rebase label Jun 6, 2020

make Application & DetectBindingResources a pointer

68a7dea

sbose78 closed this Jun 16, 2020

akashshinde mentioned this pull request Aug 25, 2020

Breaking api changes - Refactor ServiceBindingRequest api #608

Merged

8 tasks

Change API Group and Kind, and Spec #495

Change API Group and Kind, and Spec #495

Conversation

sbose78 commented May 27, 2020 • edited

TLDR;

This is how the new CR looks like

What should you review?

Motivation

Primarily

Also ..

Changes

Pre-merge checklist

Testing

openshift-ci-robot commented May 27, 2020

sbose78 commented May 27, 2020 • edited

sbose78 commented May 27, 2020

baijum commented May 27, 2020

sbose78 commented May 27, 2020 • edited

codecov bot commented May 27, 2020 • edited

Codecov Report

Avni-Sharma commented May 27, 2020

Choose a reason for hiding this comment

sbose78 May 27, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sbose78 May 27, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Avni-Sharma Jun 4, 2020 • edited

Choose a reason for hiding this comment

Avni-Sharma May 28, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DhritiShikhar May 28, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xliuxu commented May 28, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sbose78 Jun 3, 2020 • edited

Choose a reason for hiding this comment

sbose78 commented Jun 3, 2020

openshift-ci-robot commented Jun 6, 2020

openshift-ci-robot commented Jun 16, 2020

sbose78 commented Jun 16, 2020

sbose78 commented May 27, 2020 •

edited

sbose78 commented May 27, 2020 •

edited

sbose78 commented May 27, 2020 •

edited

codecov bot commented May 27, 2020 •

edited

sbose78 May 27, 2020 •

edited

sbose78 May 27, 2020 •

edited

Avni-Sharma Jun 4, 2020 •

edited

Avni-Sharma May 28, 2020 •

edited

DhritiShikhar May 28, 2020 •

edited

sbose78 Jun 3, 2020 •

edited