chore(refactor): Operator-sdk upgrade

[RealHarshThakur]

Pull Request template

Why is this PR required? What issue does it fix?:
Operator-sdk is used to scaffold the project and beyond that, it will help when creating webhooks, etc

What this PR does?:
Upgrades operator-sdk to latest version

Does this PR require any upgrade changes?:

If the changes in this PR are manually verified, list down the scenarios covered::

Any additional information for your reviewer? :
Mention if this PR is part of any design or a continuation of previous PRs

Pending tasks:

• Migrate project structure
• Fix import types
• Upgrade client-go
• Fix ndm operator's main.go (it has outdated operator-sdk dependencies)
• Fix unit tests
• Fix integration tests which are failing due to lack of preupgrade checks

References:

• https://github.com/kubernetes-sigs/controller-runtime/releases (for breaking changes in controller runtime)
• https://sdk.operatorframework.io/docs/building-operators/golang/migration/

Checklist:

• Fixes #
• PR Title follows the convention of <type>(<scope>): <subject>
• Has the change log section been updated?
• Commit has unit tests
• Commit has integration tests
• (Optional) Are upgrade changes included in this PR? If not, mention the issue/PR to track:
• (Optional) If documentation changes are required, which issue on https://github.com/openebs/openebs-docs is used to track them:

[RealHarshThakur]

@akhilerm Mentioned some of these concerns in Slack too.
I am not sure about some of the changes:

• Changed GVK (blockdevice.openebs.io to blockdevices.blockdevice.openebs.io) . Should probably revert back to original API group .
• I don't know if this is the right way to do this: https://github.com/openebs/node-disk-manager/pull/561/files#diff-a20906eb0434b5deaf080095f98faa6ab0cd1420cece8129fc0ec7102c14d9f6R278
• Currently ndm operator main.go is commented because it has outdated dependencies of operator-sdk , I am wondering if we still need ndm-operator at all. Anyway, updated the rest of the code base ndm-operator relies on

Boilerplate, dockerfiles, etc were generated by operator-sdk which I'll clean up and structure in Makefile when operator-sdk is to be used.

[akhilerm]

Some comments:

1. What is the use of config/ directory
2. Are the controllers meant to be at the root of the project?

[shubham14bajpai]

For the packaging of the latest operator-sdk the main.go, apis/ and controller/ are at the root which is ideal for a single controller. But in this repo we have multiple operators so can we move them back into cmd/ and pkg/ structure instead of strictly following the operator-sdk pattern.

[RealHarshThakur]

@shubham14bajpai I think it's possible to have multiple controllers with same layout because main.go creates a manager to run all of them. We can remove the kustomize and others thing we don't use but I am not sure if we should move away from project structure as it will make upgrading the operator-sdk version difficult as mentioned in their docs. It will also hinder using some of the features https://v1-5-x.sdk.operatorframework.io/docs/faqs/#can-i-customize-the-projects-generated-with-sdk-tool

[akhilerm]

@shubham14bajpai I think it's possible to have multiple controllers with same layout because main.go creates a manager to run all of them. We can remove the kustomize and others thing we don't use but I am not sure if we should move away from project structure as it will make upgrading the operator-sdk version difficult as mentioned in their docs. It will also hinder using some of the features https://v1-5-x.sdk.operatorframework.io/docs/faqs/#can-i-customize-the-projects-generated-with-sdk-tool

How is it done in jiva operator @shubham14bajpai ?

[shubham14bajpai]

@shubham14bajpai I think it's possible to have multiple controllers with same layout because main.go creates a manager to run all of them. We can remove the kustomize and others thing we don't use but I am not sure if we should move away from project structure as it will make upgrading the operator-sdk version difficult as mentioned in their docs. It will also hinder using some of the features https://v1-5-x.sdk.operatorframework.io/docs/faqs/#can-i-customize-the-projects-generated-with-sdk-tool

How is it done in jiva operator @shubham14bajpai ?

In case of jiva-operator we wanted to be less dependent on the operator-sdk binary as that itself has breaking changes if we upgrade after a long time. As the operator-sdk generates the code using the standard k8s kubebuilder etc. I restructured the packages in line with other repos and added targets to the makefile using standard k8s patterns as I did for the crd generation PR. This helps us have more control over smaller parts of the code.

[RealHarshThakur]

Currently, kubebuilder and operator-sdk are following the same package structure. Also, I think there are some good features we have to start utilizing from Operator-sdk like OLM, score card testing and small features like this which might be valuable at some point. After their 1.0 release, there are no major breaking changes. Having said that, if we're sure we don't need those features , then I think we can stop relying on operator-sdk altogether but IMHO, I think we should stick to Operator-SDK and if we ever face any issue, we can easily fall back on controller-gen, etc .

[shubham14bajpai]

Yes it makes sense if these features are used. In case of jiva-operator it was a simple reconciler and these features are not required.

[sonatype-lift]

Critical OSS Vulnerability:  

pkg:golang/golang.org/x/net@0.0.0-20180724234803-3673e40ba225

5 Critical, 0 Severe, 0 Moderate and 0 Unknown vulnerabilities have been found in a transitive dependency of pkg:golang/k8s.io/apimachinery@0.19.2

CRITICAL Vulnerabilities (5)

---

CVE-2018-17143

[CVE-2018-17143] Improper Input Validation

The html package (aka x/net/html) through 2018-09-17 in Go mishandles <template><tBody><isindex/action=0>, leading to a "panic: runtime error" in inBodyIM in parse.go during an html.Parse call.

CVSS Score: 7.5

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

---

CVE-2018-17848

[CVE-2018-17848] Data Handling

The html package (aka x/net/html) through 2018-09-25 in Go mishandles <math><template><mn><b></template>, leading to a "panic: runtime error" (index out of range) in (*insertionModeStack).pop in node.go, called from inHeadIM, during an html.Parse call.

CVSS Score: 7.5

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

---

CVE-2018-17847

[CVE-2018-17847] Improper Input Validation

The html package (aka x/net/html) through 2018-09-25 in Go mishandles <svg><template><desc><t><svg></template>, leading to a "panic: runtime error" (index out of range) in (*nodeStack).pop in node.go, called from (*parser).clearActiveFormattingElements, during an html.Parse call.

CVSS Score: 7.5

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

---

CVE-2018-17142

[CVE-2018-17142] Improper Input Validation

The html package (aka x/net/html) through 2018-09-17 in Go mishandles <math><template><mo><template>, leading to a "panic: runtime error" in parseCurrentToken in parse.go during an html.Parse call.

CVSS Score: 7.5

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

---

CVE-2018-17846

[CVE-2018-17846] Resource Management Errors

The html package (aka x/net/html) through 2018-09-25 in Go mishandles <table><math><select><mi><select></table>, leading to an infinite loop during an html.Parse call because inSelectIM and inSelectInTableIM do not comply with a specification.

CVSS Score: 7.5

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

---

(at-me in a reply with help or ignore)

[sonatype-lift]

Severe OSS Vulnerability:  

pkg:golang/golang.org/x/crypto@0.0.0-20190308221718-c2843e01d9a2

0 Critical, 1 Severe, 0 Moderate and 0 Unknown vulnerabilities have been found in a transitive dependency of pkg:golang/google.golang.org/protobuf@1.24.0

SEVERE Vulnerabilities (1)

---

[CVE-2019-11840] Use of Insufficiently Random Values

An issue was discovered in supplementary Go cryptography libraries, aka golang-googlecode-go-crypto, before 2019-03-20. A flaw was found in the amd64 implementation of golang.org/x/crypto/salsa20 and golang.org/x/crypto/salsa20/salsa. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications.

CVSS Score: 5.9

CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

---

(at-me in a reply with help or ignore)

[sonatype-lift]

Critical OSS Vulnerability:  

pkg:golang/golang.org/x/net@0.0.0-20180724234803-3673e40ba225

5 Critical, 0 Severe, 0 Moderate and 0 Unknown vulnerabilities have been found in a transitive dependency of pkg:golang/github.com/spf13/cobra@1.1.1

CRITICAL Vulnerabilities (5)

---

CVE-2018-17143

[CVE-2018-17143] Improper Input Validation

The html package (aka x/net/html) through 2018-09-17 in Go mishandles <template><tBody><isindex/action=0>, leading to a "panic: runtime error" in inBodyIM in parse.go during an html.Parse call.

CVSS Score: 7.5

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

---

CVE-2018-17848

[CVE-2018-17848] Data Handling

The html package (aka x/net/html) through 2018-09-25 in Go mishandles <math><template><mn><b></template>, leading to a "panic: runtime error" (index out of range) in (*insertionModeStack).pop in node.go, called from inHeadIM, during an html.Parse call.

CVSS Score: 7.5

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

---

CVE-2018-17847

[CVE-2018-17847] Improper Input Validation

The html package (aka x/net/html) through 2018-09-25 in Go mishandles <svg><template><desc><t><svg></template>, leading to a "panic: runtime error" (index out of range) in (*nodeStack).pop in node.go, called from (*parser).clearActiveFormattingElements, during an html.Parse call.

CVSS Score: 7.5

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

---

CVE-2018-17142

[CVE-2018-17142] Improper Input Validation

The html package (aka x/net/html) through 2018-09-17 in Go mishandles <math><template><mo><template>, leading to a "panic: runtime error" in parseCurrentToken in parse.go during an html.Parse call.

CVSS Score: 7.5

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

---

CVE-2018-17846

[CVE-2018-17846] Resource Management Errors

The html package (aka x/net/html) through 2018-09-25 in Go mishandles <table><math><select><mi><select></table>, leading to an infinite loop during an html.Parse call because inSelectIM and inSelectInTableIM do not comply with a specification.

CVSS Score: 7.5

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

---

(at-me in a reply with help or ignore)

[sonatype-lift]

Severe OSS Vulnerability:  

pkg:golang/golang.org/x/crypto@0.0.0-20181029021203-45a5f77698d3

0 Critical, 1 Severe, 0 Moderate and 0 Unknown vulnerabilities have been found in a transitive dependency of pkg:golang/github.com/spf13/cobra@1.1.1

SEVERE Vulnerabilities (1)

---

[CVE-2019-11840] Use of Insufficiently Random Values

An issue was discovered in supplementary Go cryptography libraries, aka golang-googlecode-go-crypto, before 2019-03-20. A flaw was found in the amd64 implementation of golang.org/x/crypto/salsa20 and golang.org/x/crypto/salsa20/salsa. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications.

CVSS Score: 5.9

CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

---

(at-me in a reply with help or ignore)

[sonatype-lift]

Severe OSS Vulnerability:  

pkg:golang/golang.org/x/crypto@0.0.0-20181029021203-45a5f77698d3

0 Critical, 1 Severe, 0 Moderate and 0 Unknown vulnerabilities have been found in a transitive dependency of pkg:golang/k8s.io/apiextensions-apiserver@0.20.1

SEVERE Vulnerabilities (1)

---

[CVE-2019-11840] Use of Insufficiently Random Values

An issue was discovered in supplementary Go cryptography libraries, aka golang-googlecode-go-crypto, before 2019-03-20. A flaw was found in the amd64 implementation of golang.org/x/crypto/salsa20 and golang.org/x/crypto/salsa20/salsa. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications.

CVSS Score: 5.9

CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

---

(at-me in a reply with help or ignore)

[sonatype-lift]

Severe OSS Vulnerability:  

pkg:golang/golang.org/x/crypto@0.0.0-20181029021203-45a5f77698d3

0 Critical, 1 Severe, 0 Moderate and 0 Unknown vulnerabilities have been found in a transitive dependency of pkg:golang/sigs.k8s.io/controller-runtime@0.8.2

SEVERE Vulnerabilities (1)

---

[CVE-2019-11840] Use of Insufficiently Random Values

An issue was discovered in supplementary Go cryptography libraries, aka golang-googlecode-go-crypto, before 2019-03-20. A flaw was found in the amd64 implementation of golang.org/x/crypto/salsa20 and golang.org/x/crypto/salsa20/salsa. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications.

CVSS Score: 5.9

CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

---

(at-me in a reply with help or ignore)

[RealHarshThakur]

@akhilerm LGTM , I think there could be small things we could be missing as PR has gotten so huge but we can fix them later.

[akhilerm]

@akhilerm LGTM , I think there could be small things we could be missing as PR has gotten so huge but we can fix them later.

@RealHarshThakur can you make a list of those things, so that we can refer back to this PR, incase we need to update it later.

[shubham14bajpai]

LGTM

[RealHarshThakur]

@akhilerm I meant I don't see anything wrong immediately. There could be no issues too :D

[akhilerm]

LGTM