[WIP] Replace oc commands in OperatorSource automated test with client-go

[pratikjagrut]

This PR replaces the oc shell commands in OperatorSource automated test with client-go.
Steps to run this test;
make clean
dep ensure -v
make build
make test-operator-source

Jira ticket

If you get any timeout error or panic error which may cause due slow connectivity between test machine and cluster, try increasing sleep time in test.mk->test-operator-source target then use following cleanup command
oc delete sub devconsole -n openshift-operators | oc delete catsrc installed-custom-openshift-operators -n openshift-operators | oc delete csc installed-custom-openshift-operators -n openshift-marketplace | oc delete csv devconsole-operator.v0.1.0 -n openshift-operators
and retry make test-operator-source.

Signed-off-by: Pratik Jagrut [email protected]

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: tinakurian

If they are not already assigned, you can assign the PR to them by writing /assign @tinakurian in a comment when ready.

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

The pull request process is described 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

[openshift-ci-robot]

Hi @pratikjagrut. Thanks for your PR.

I'm waiting for a redhat-developer member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[akashshinde]

/ok-to-test

[akashshinde]

@pratikjagrut You are accessing 1st element of the Pod.Items[] without checking the array size. This would cause panic if pod isn't created.

[pratikjagrut]

@akashshinde I'm checking Pods length before returning it from GetPodByLabel(), so if pod isn't created it will return nil. you can check it here: https://github.com/redhat-developer/devconsole-operator/pull/213/files#diff-31828c90d3e18decf90b57b66bbe0b66R59

[akashshinde]

@pratikjagrut What if there is the case where you get both pod and error values nil from GetPodByLabel ? wouldn't it fail in that case ? So just for safe side I think you should check array length.

[pratikjagrut]

@akashshinde I have checked the Items length if len(pods.Items) == 0, but you are saying I should add an extra check if pods == nil. Okay that can be done. Thanks.

[tinakurian]

@pratikjagrut do you mind pasting a link to the jira ticket that this work is associated with in the description?

[pratikjagrut]

@pratikjagrut do you mind pasting a link to the jira ticket that this work is associated with in the description?

@tinakurian https://jira.coreos.com/browse/ODC-831

[Avni-Sharma]

can we have cleanup of resources as a separate PR/subtask if not in this PR?

[tinakurian]

Do we really need these helper functions? I don't really see the add value in these wrapper methods vs just making the call directly? Especially since it does not do any sort of additional processing here.

This could also easily get out of hand when getting other resources.

It also seems somewhat inconsistent. In other places we just make the call directly.

[pratikjagrut]

I feel it would be a good idea to isolate the helpers method and even though this are wrappers methods this would make for clean and readable test. And also in future test cases this helpers methods can be reused, suppose in future we have to write similar kind of test rather than starting from scratch we can just use helpers function e.g if I need to write similar test then I would need to create clientset for k8s and for operatorsource clientset of OLM too, so will need to write two different functions or more number of lines of code where as of now I can just call one function which will create both clientset. For this test it might look like extra work but they could come in handy for adding new test cases in operatorsource. Also this helpers are encapsulating the implementation and directly providing us with the result. I had such things in my mind and thought it would be good practice to separate the implementation and actual usable result.

[tinakurian]

GetSubscription(), GetInstallPlan() etc... probably cause more overhead. If there was an error and something had to be done with it, we would need an additional check where the helper func is called. Seems like extra overhead with no add value.

We haven't done this in our other tests and i guess i'm having a hard time understanding what benefits it really adds. Perhaps the team has a different opinion? @baijum @akashshinde @Avni-Sharma @DhritiShikhar

[baijum]

Creating a function for code readability is overkill. It also makes error traceback convoluted

[akashshinde]

@pratikjagrut What if there is the case where you get both pod and error values nil from GetPodByLabel ? wouldn't it fail in that case ? So just for safe side I think you should check array length.