github.com/google/gnostic/openapiv2 moved to github.com/google/gnostic-models/openapiv2

[licat233]

~/go/pkg/mod/k8s.io/client-go@v0.27.3/applyconfigurations/meta/v1/unstructured.go:64:38: cannot use doc (variable of type *"github.com/google/gnostic/openapiv2".Document) as *"github.com/google/gnostic-models/openapiv2".Document value in argument to proto.NewOpenAPIData

[nyetwurk]

The title of this ticket is almost entirely useless.

it should be something like github.com/google/gnostic/openapiv2 moved to github.com/google/gnostic-models/openapiv2

[nyetwurk]

https://github.com/google/gnostic-models/tags

https://github.com/google/gnostic/tags

[nyetwurk]

#1075

[nyetwurk]

kubernetes/kube-openapi#404

[nyetwurk]

kubernetes/kubernetes#118384

gnostic OpenAPI components were moved to the gnostic-models library. gnostic is pinned on v0.5.7-v3refs because we did not want to capture the additional dependencies introduced with later versions of gnostic. The OpenAPI component has been moved to gnostic-models so update the library path to reflect that.

[miparnisari]

i'm getting

# k8s.io/client-go/applyconfigurations/meta/v1
../../go/pkg/mod/k8s.io/client-go@v0.27.3/applyconfigurations/meta/v1/unstructured.go:64:38: cannot use doc (variable of type *"github.com/google/gnostic/openapiv2".Document) as *"github.com/google/gnostic-models/openapiv2".Document value in argument to proto.NewOpenAPIData

with

k8s.io/client-go v0.27.3 // indirect

I've managed to workaround this by adding this to go.mod

replace k8s.io/client-go => k8s.io/client-go v0.28.0-alpha.3

[busser]

I had the same issue with client-go as a direct dependency.

The following change to my go.mod fixed the problem:

  require (
    // ...
-   k8s.io/client-go v0.27.3
+   k8s.io/client-go v0.28.0-alpha.3
    // ...
  )

Thanks @miparnisari!

[sosheskaz]

In my env, this can be solved with a light touch, without using an alpha release of client-go, by running the following:

go get k8s.io/kube-openapi@2546d827e515dca59571ec245eef2302e11018e1 && go mod tidy

Kube-openapi is the entity which injects the dependency on gnostic-models and breaks backwards compatibility. This resets it to the commit before the change to gnostic-models happened.

[yasin-cs-ko-ak]

Thank you so much for this!!! I was bugging around this like two days.

[troy0820]

Definitely appreciate the workaround

[ldemailly]

having the same mystery issue trying to doing some updates, if anyone searches for exact error and want to use the workaround above (which worked, thx!) - my error was:

# k8s.io/client-go/applyconfigurations/meta/v1
../../go/pkg/mod/k8s.io/client-go@v0.25.12/applyconfigurations/meta/v1/unstructured.go:64:38: cannot use doc (variable of type *"github.com/google/gnostic/openapiv2".Document) as *"github.com/google/gnostic-models/openapiv2".Document value in argument to proto.NewOpenAPIData

[liggitt]

Agree that using the specific versions of dependencies like kube-openapi and gnostic matching what is referenced by the client-go version you are using is the correct solution here. See the comment at #1075 (comment) about updating to latest commits of v0 dependencies belong likely to cause issues.

[ldemailly]

probably a huge faq/can of worm but why isn't k8s using 1.x instead of 0.x go packages where x == k8s 1.x, why not 1.x directly?

I'm aware of issues with go and v2 but... this is not about v2... v0->v1 and v1 updates are still smooth sailing afaik?

[liggitt]

The kubernetes project essentially spends all its API compatibility effort budget on maintaining REST API compatibility.

The exported go package APIs don't maintain perfect compatibility across releases (function signatures occasionally change, etc), so we don't want to make a promise about compatibility we don't think we can keep by versioning these go libraries as v1.x

[ldemailly]

ic... it's true to the letter of semver but practically people do expect on MAJOR.MINOR.PATCH that when MINOR changes, something changed, and it would probably be less confusing if MAJOR of go matched MAJOR of k8s (== 1 for the forseable future) like you make MINOR,PATCH match

but thanks though for the rationale (and having taken the time to reply ❤️), it makes sense as well but is a bit too "pure" imo

[ofey404]

In my env, this can be solved with a light touch, without using an alpha release of client-go, by running the following:

go get k8s.io/kube-openapi@2546d827e515dca59571ec245eef2302e11018e1 && go mod tidy

Kube-openapi is the entity which injects the dependency on gnostic-models and breaks backwards compatibility. This resets it to the commit before the change to gnostic-models happened.

Thank you a lot!

The client-go is pinned to 0.26 in my environment because our web framework (an external dependency) is not migrated to 0.28.

So only your solution works!

[kwenzh]

the same trouble in v0.27.1, change to v0.28.1, it works

 cannot use doc (variable of type *"github.com/google/gnostic/openapiv2".Document) as *"github.com/google/gnostic-models/openapiv2".Document value in argument to proto.NewOpenAPIData

[shashidhar-patil]

the same trouble in v0.27.1, change to v0.28.1, it works

 cannot use doc (variable of type *"github.com/google/gnostic/openapiv2".Document) as *"github.com/google/gnostic-models/openapiv2".Document value in argument to proto.NewOpenAPIData

Facing same issue in v0.28.1 . Can anyone help?

[optik-aper]

I am seeing this error when upgrading from client-go v0.28.2 to v0.30.2

[chengjingtao]

in my env, this can be solved by upgrading version of kustomize/api and kustomize/kyaml

k8s.io/client-go v0.31.0 

go get sigs.k8s.io/kustomize/api@v0.17.2
go get sigs.k8s.io/kustomize/kyaml@v0.17.1

In fact, the kustomize version should be same as kustomize version used in https://github.com/kubernetes/kubernetes/blob/master/go.mod

Remember to confirm the version of k8s package you referenced