Fixes for Deprecation of io/ioutil (in Go 1.16)

[cndoit18]

Please see https://golang.org/doc/go1.16#ioutil

We have a lot of references to ioutil which we need to migrate to newer package(s) mentioned in the url above:
https://cs.k8s.io/?q=io%2Fioutil&i=nope&files=.*%5C.go&excludeFiles=&repos=kubernetes-sigs/controller-runtime

We also need some verify scripts to ensure we don't add back this package

[coderanger]

I think we'll have to wait a while on this one unless we want to 100% require Go 1.16+, which seems like it's too soon to require that every operator project using controller-runtime be able to upgrade.

[cndoit18]

I think we'll have to wait a while on this one unless we want to 100% require Go 1.16+, which seems like it's too soon to require that every operator project using controller-runtime be able to upgrade.

#1389
our dependence has been updated, so I think it is possible

[cndoit18]

/assign @cndoit18

[coderanger]

controller-runtime is a library, so while this repo is built and tested with Go 1.16, I don't think we (yet) require that all library users use 1.16. I could be wrong though, I haven't tried building any of my operators with 1.15 lately :) If we already made the choice to use 1.16-only stuff then 100% yes we should do this. Otherwise we should probably ride the deprecation another few months at least to give people time to switch without cutting them off from new c-r releases.

[cndoit18]

controller-runtime is a library, so while this repo is built and tested with Go 1.16, I don't think we (yet) require that all library users use 1.16. I could be wrong though, I haven't tried building any of my operators with 1.15 lately :) If we already made the choice to use 1.16-only stuff then 100% yes we should do this. Otherwise we should probably ride the deprecation another few months at least to give people time to switch without cutting them off from new c-r releases.

you are right. the key issue is whether we require users to use Go 1.16

[k8s-triage-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[palnabarun]

I think we should sit on this until we stop supporting Go versions that don't have io/ioutil (<1.16).

/lifecycle frozen
/priority important-longterm