[ryjones]

The replace holding logr at v0.4.0 stopped go mod tidy working. grpc 1.79's test packages reach github.com/go-logr/logr/funcr through OpenTelemetry, and tidy walks tests of dependencies, so it reported:

github.com/go-logr/logr/funcr: module github.com/go-logr/logr@latest found
(replaced by github.com/go-logr/logr@v0.4.0), but does not contain package
github.com/go-logr/logr/funcr

Dependabot runs a strict go mod tidy, so every Go module update it opened would have failed the same way.

The pin existed because klog v2.8.0 and controller-runtime v0.9.0 are written against logr v0, where Logger is an interface. The way out is to raise those rather than hold logr back. controller-runtime v0.11 is the first release built against logr v1, and it pairs with the Kubernetes 1.23 libraries, so:

sigs.k8s.io/controller-runtime v0.9.0 -> v0.11.2
k8s.io/{api,apimachinery,client-go,
apiextensions-apiserver,code-generator}
v0.21.5 -> v0.23.17
github.com/go-logr/zapr v0.4.0 -> v1.2.4
k8s.io/klog/v2 (indirect) v2.8.0 -> v2.30.0

The only source change the move needs is the Kubernetes 1.23 rename of the embedded Handler on corev1.Probe to ProbeHandler, in the three deployment overrides that set gRPC-web probes. Everything else compiles as is; the operator already passes logr.Logger by value.

Verified with go build, go vet, a strict go mod tidy, and the unit tests (85 packages ok, controllers included). The integration and end-to-end suites need a cluster and are left to CI.

[ryjones]

@hyperledger-labs/fabric-operator-committers I propose a release of 1.0.10 if this is merged.

I started looking into the CI and publishing over here due to fabric-samples having failing CI.