Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

failed with: OpenAPI spec does not exist #27

Open
deyaeddin opened this issue Jun 3, 2021 · 13 comments
Open

failed with: OpenAPI spec does not exist #27

deyaeddin opened this issue Jun 3, 2021 · 13 comments
Labels
priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.

Comments

@deyaeddin
Copy link

Hi, I'm trying to implement Hetzner DNS API based on this sample, Everything is working as expected and the webhook issue the certificates normally, however, I'm getting this log error constantly:

controller.go:129] OpenAPI AggregationController: action for item v1alpha1.acme.mycompany.com: Rate Limited Requeue.
controller.go:116] loading OpenAPI spec for "v1alpha1.acme.mycompany.com" failed with: OpenAPI spec does not exist

any idea how to fix it?

@andreee94
Copy link

I have got the same error with the freenom dsn resolver.

Still no idea on how to fix it.

@rbaumgar
Copy link

I have the same issue with Cert Manager Webhook for Dynu

Any idea?

@irbekrm
Copy link
Contributor

irbekrm commented Jan 20, 2023

controller.go:116] loading OpenAPI spec for "v1alpha1.acme.mycompany.com" failed with: OpenAPI spec does not exist

v1alpha1.acme.mycompany.com is the default API GroupVersion in this sample webhook repository. The error comes from when a new apiserver config is created in Kubernetes.

Perhaps the group name in chart values has not been changed https://github.com/cert-manager/webhook-example/blob/master/deploy/example-webhook/values.yaml#L9 ?

If it seems like the webhook repository does not reference v1alpha1.acme.mycompany.com anywhere, but the error is still present, it would be good if someone could add instructions how to reproduce it.

@atsai1220
Copy link

Looking at the referenced cert manager webhooks (dynu, freenom, and others on GitHub) and my own, it looks like the error messages are present even if we update the group name to something explicit.

It seems another project implements the openapi spec kubernetes-sigs/prometheus-adapter#335

May need to implement this: https://github.com/kubernetes/kube-openapi

@vdobes
Copy link

vdobes commented Mar 29, 2023

I got the same problem with PowerDNS webhook, still no fix?

@bcspragu
Copy link

bcspragu commented Aug 22, 2023

Update: Ignore this, my issue is different, seems to be a problem with using too new of a version of k8s.io/api

I hit what appears to be a variation of this on my attempt at a custom webhook for Porkbun

cert-manager: error executing command" err="error installing APIGroup for solvers: unable to get openapi models: OpenAPIV3 config must not be nil

I dug into the webhook code and nothing obvious stuck out to me.

@irreleph4nt
Copy link

Update: Ignore this, my issue is different, seems to be a problem with using too new of a version of k8s.io/api

I hit what appears to be a variation of this on my attempt at a custom webhook for Porkbun

cert-manager: error executing command" err="error installing APIGroup for solvers: unable to get openapi models: OpenAPIV3 config must not be nil

I dug into the webhook code and nothing obvious stuck out to me.

@bcspragu if you are still interested / haven't solved your problem yet, consider this: I ran into the same error message and as it turns out, the problem was the go version used in the Dockerfile, i.e. the go version used for building the hook.

I overcame the problem by looking at other working hooks, realizing the most recent version any of them used was:

FROM golang:1.19-alpine AS build_deps

If you set your Dockerfile to use v1.19, your problem will likely disappear. To make my build work, I referenced the webhook for google-domains, merging their go.mod and go.sum files with the one go v1.21 created for my own project, simply adding the additional lines required for my project to their files.

@bcspragu
Copy link

@bcspragu if you are still interested / haven't solved your problem yet, consider this: I ran into the same error message and as it turns out, the problem was the go version used in the Dockerfile, i.e. the go version used for building the hook.

Thanks for the tip! In my case, I don't remember the exact resolution, but I think I had fixed my issue by just not upgrading k8s.io/api (i.e. reverting most of my go.mod changes). That Porkbun webhook now works excellent for my use case, and I'm running it on Go 1.21

@aureq
Copy link

aureq commented Sep 18, 2023

This issue should be now solved.

  • compile the webhook against cert-manager 1.13.0
  • run the webhook with cert-manager 1.13.0

I haven't seen a single error across my cluster for the last 24 hours.

Note that upgrading to cert-manager to 1.13.0 alone isn't enough. The webhook needs to be compiled against cert-manager 1.13.0.

Here is an excerpt of my go.mod

go 1.20

require (
	github.com/cert-manager/cert-manager v1.13.0
	github.com/ovh/go-ovh v1.4.2
	k8s.io/api v0.28.1
	k8s.io/apiextensions-apiserver v0.28.1
	k8s.io/apimachinery v0.28.1
	k8s.io/client-go v0.28.1
)

@irreleph4nt
Copy link

irreleph4nt commented Sep 22, 2023

This issue should be now solved.

  • compile the webhook against cert-manager 1.13.0
  • run the webhook with cert-manager 1.13.0

I haven't seen a single error across my cluster for the last 24 hours.

Note that upgrading to cert-manager to 1.13.0 alone isn't enough. The webhook needs to be compiled against cert-manager 1.13.0.

Here is an excerpt of my go.mod

go 1.20

require (
	github.com/cert-manager/cert-manager v1.13.0
	github.com/ovh/go-ovh v1.4.2
	k8s.io/api v0.28.1
	k8s.io/apiextensions-apiserver v0.28.1
	k8s.io/apimachinery v0.28.1
	k8s.io/client-go v0.28.1
)

Whilst I can confirm building against v1.13 works when also deploying with the same version, the information provided is incomplete. More development has to be done for the hook to actually work:

  • between v1.11 and v1.13, cert-manager moved the test/acme/dns folder contents out of the repo and back in. They messed up however and obmitted the /dns/ folder when moving back in, which requires an update to the test suite in main_test.go
  • the controller-runtime in v1.13 has a bug, making it complain log.SetLogger(...) has never been called, requiring adjustments in the solver code
  • v1.13 is significantly more aggressive when triggering requests in the extended test suite. This got out of control so much that a rework of a solver was required to adjust for API rate limits. The same solver works perfectly fine against the same API when compiled with v1.11

@aureq
Copy link

aureq commented Sep 23, 2023

@irreleph4nt I'm not part of the cert-manager/jetstack team but what you describe sounds like separate issues (though connected perhaps). Have you considered raising separate issues and linking them to this one?

On your 2nd point, do you have more details and some code to propose?

@SgtCoDFish
Copy link
Member

I really appreciate you all commenting here and discussing this! We (the maintainer team) are stretched pretty thin at the moment and it looks like the webhook-example has passed us by a bit. I've put out a call to action to hopefully get someone to take a look at this repo soon!

Thank you all for being part of the community, appreciate you all! ❤️

@aureq
Copy link

aureq commented Nov 16, 2023

Likewise @SgtCoDFish we all also very much appreciate all the work you and the entire team are doing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.
Projects
None yet
Development

No branches or pull requests