Closed pkwarren closed 10 months ago
For example, k8s.io/kube-openapi recently updated to switch to gnostic-models in https://github.com/kubernetes/kube-openapi/pull/402. The latest release of https://github.com/kubernetes/apimachinery/releases/tag/v0.27.2 and https://github.com/kubernetes/apiserver/releases/tag/v0.27.2 are still using gnostic (although unreleased versions look like they're switching to use gnostic-models).
This is a known issue. The latest releases of apimachinery v0.27.2 uses a corresponding version of kube-openapi that also uses gnostic instead of gnostic-models: https://github.com/kubernetes/apimachinery/blob/v0.27.2/go.mod#L26. Please stick to the pinned dependency versions to prevent drift in the modules.
Ok - we hit this with an upgrade to kube-openapi (which has no tags so it picked up the latest commit). Hopefully over the next few releases of libraries things will stabilize to only depend on gnostic-models instead of a combination of gnostic-models and gnostic.
Would you be open to a PR which updates the generated proto code to come from gnostic-models and provides type aliases for compatibility with existing code, i.e. replace discovery/discovery.pb.go
with:
package discovery_v1
import (
models "github.com/google/gnostic-models/discovery"
)
type Annotations = models.Annotations
type Any = models.Any
type Auth = models.Auth
...
type Simple = models.Simple
type StringArray = models.StringArray
var File_discovery_discovery_proto = models.File_discovery_discovery_proto
This should allow for a Go module to depend on code both from gnostic and gnostic-models without panicing.
Sounds like a great idea, do you want to go ahead with the PR? cc @timburks
Sounds like a great idea, do you want to go ahead with the PR? cc @timburks
Opened #400 with a proposed change.
Summary of the issue: gnostic was renamed to gnostic-models in kubernetes which affects mainly importers of client-go and kube-openapi. Some of the workarounds have been described in https://github.com/kubernetes/client-go/issues/1269#issuecomment-1613565035 and https://github.com/kubernetes/client-go/issues/1269#issuecomment-1603511589.
These issues should be fully resolved once kubernetes 1.28 is released and a workaround is not needed to use an alpha client. In the meantime, #400 is a generalized way of solving this for projects that do not have any kubernetes dependencies.
We've encountered an issue in recent versions of upstream libraries that mix dependencies - sometimes pulling in
gnostic
and other timesgnostic-models
. This leads to a panic at runtime, and it causes golangci-lint to fail with an internal error.Here's a small example program illustrating the panic:
This leads to a panic:
Generated code should ideally only live in a single place - is it possible to update gnostic to pull generated code from gnostic-models so that it only exists in one go module?