text:
Documenting "context deadline exceeded" errors relating to the webhook

📢 Update from the cert-manager maintainers:
For those of you encountering problems with the cert-manager webhook, please read @maelvls 's Definitive Debugging Guide for the cert-manager Webhook Pod.

Describe the bug:
When I try to create a ClusterIssuer I get the following error
kubectl apply -f cert-issuer-letsencrypt-dev.yml
Error from server (InternalError): error when creating "cert-issuer-letsencrypt-dev.yml":
Internal error occurred: failed calling webhook "webhook.certmanager.k8s.io":
Post https://kubernetes.default.svc:443/apis/webhook.certmanager.k8s.io/v1beta1/mutations?timeout=30s:
context deadline exceeded

Expected behaviour:
Creation of ClusterIssuer works without errors
Steps to reproduce the bug:
Install cert-manager as follows
kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.10/deploy/manifests/00-crds.yaml
kubectl create namespace cert-manager
kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true
helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install \
  --name cert-manager \
  --namespace cert-manager \
  --version v0.10.1 \
  jetstack/cert-manager

Then I run
apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-dev
  namespace: cert-manager
spec:
  acme:
    # The ACME server URL
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: xxx@xxxx.com
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-dev
    # Enable the HTTP-01 challenge provider
    # http01: {}
    solvers:
    - dns01:
        cloudflare:
          email: xxxx@xxxx.com
          apiKeySecretRef:
            name: cloudflare-api-key-secret
            key: api-key

Anything else we need to know?:
Environment details::

Kubernetes version (e.g. v1.10.2): 1.15
Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): baremetal
cert-manager version (e.g. v0.4.0): 0.10.1
Install method (e.g. helm or static manifests): helm

/kind bug

I've removed cert-manager 0.10.1 and added 0.11.0 but still get the same error

@papanito Have you found any solution on this? I'm in the exact same situation.

Nope still stuck an this sucks

@munerz

@munnerz do you have a hint maybe

@papanito I completely disabled the webhook to move past the issue, but this is not recommended as it can expose the cluster to misconfiguration errors and break cert-manager.
Check this link: https://docs.cert-manager.io/en/latest/getting-started/webhook.html#disable-the-webhook-component
It is working fine with the webhook disabled though.

@hampos thanks for the hint will have a look at it

Seems that kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true is oboslete now, at least there is no mention about it in latest docs.

any updates on this issue?

any updates on this issue?
I"m also seeing this, don't know what causes the issue. still looking for a solution.

any updates on this issue?
Error from server (InternalError): error when creating "test-resources.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: context deadline exceeded

What os are you running your clusters?
For me in meanwhile cert-manager works fine, I've setup my cluster completely new on a debian 10 but I had to switch back from nfttables to legacy iptables in order to get networking working. This might me affecting you as well?

@papanito
centos7
helm3
k8s1.17.2

@javachen so I guess my guess was wrong then :-(

@papanito i check coredns and then it works

@javachen means? Was something wrong with coredns and after fixing this issue is gone?

Also having this issue, with k3s:
Error from server (InternalError): error when creating "lstage.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.kube-system.svc:443/mutate?timeout=30s: context deadline exceeded

[sseneca@alarm-master ~]$ kubectl version
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.2+k3s1", GitCommit:"cdab19b09a84389ffbf57bebd33871c60b1d6b28", GitTreeState:"clean", BuildDate:"2020-01-27T18:08:16Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/arm64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.2+k3s1", GitCommit:"cdab19b09a84389ffbf57bebd33871c60b1d6b28", GitTreeState:"clean", BuildDate:"2020-01-27T18:08:16Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/arm64"}

[sseneca@alarm-master ~]$ helm version
version.BuildInfo{Version:"v3.0.3", GitCommit:"ac925eb7279f4a6955df663a0128044a8a6b7593", GitTreeState:"clean", GoVersion:"go1.13.6"}

I'm running Arch Linux ARM, and crucially I'm pretty certain I have no firewalls at all right now.

Yup, we ran into the same issue on an Kubernetes 1.17.1 cluster.
Versions:

Kubernetes 1.17.0/1
Cilium 1.7.0-rc3 (Known Good, even if RC)
cert-manager 0.13.0
Helm v3.0.3

We also verified our network as up and running and working.
E0207 18:46:58.922930       1 controller.go:131] cert-manager/controller/issuers "msg"="re-queuing item  due to error processing" "error"="Internal error occurred: failed calling webhook \"webhook.cert-manager.io\": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=4s: context deadline exceeded" "key"="livedab-staging/fdab-le"

Unfortunately restarting the pod didn't fix the issue for me.

I somehow managed to workaround this issue when downgrading to v0.11. everything seems to working properly.
https://docs.cert-manager.io/en/release-0.11/

Same issue. Deployed with K8S manifest (not helm). Error from server (InternalError): error when creating "staging-letsencrypt.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: dial tcp 10.32.0.4:10250: i/o timeout mentioned correct IP and port, so I think coredns and services are alright.
For webhook pod, there is no log after
I0218 13:55:19.631368       1 main.go:64]  "level"=0 "msg"="enabling TLS as certificate file flags specified"
I0218 13:55:19.631867       1 server.go:121]  "level"=0 "msg"="listening for insecure healthz connections"  "address"=":6080"
I0218 13:55:19.632088       1 server.go:133]  "level"=0 "msg"="listening for secure connections"  "address"=":10250"
I0218 13:55:19.632310       1 tls_file_source.go:142]  "level"=0 "msg"="detected private key or certificate data on disk has changed. reloading certificate"

I have done this before, on another AWS EKS cluster. Comparing to this time, the only difference on networking is using weave net CNI instead of aws vpc CNI.

And the pod seems like working:
/ # curl -vk https://10.32.0.4:10250/mutate?timeout=30s
*   Trying 10.32.0.4:10250...
* TCP_NODELAY set
* Connected to 10.32.0.4 (10.32.0.4) port 10250 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: O=cert-manager.system
*  start date: Feb 18 13:54:21 2020 GMT
*  expire date: Feb 17 13:54:21 2021 GMT
*  issuer: O=cert-manager.system; CN=cert-manager.webhook.ca
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET /mutate?timeout=30s HTTP/1.1
> Host: 10.32.0.4:10250
> User-Agent: curl/7.67.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Date: Tue, 18 Feb 2020 14:57:14 GMT
< Content-Length: 0
<
* Connection #0 to host 10.32.0.4 left intact

I am install this today with the same issue, I am perplexed as I ahve many other installs:
root@bastion:/# curl -vk https://cert-manager-webhook.devops.svc:443/mutate?timeout=30s
* Expire in 0 ms for 6 (transfer 0x558fbf2f8f50)
* Expire in 1 ms for 1 (transfer 0x558fbf2f8f50)
* Expire in 0 ms for 1 (transfer 0x558fbf2f8f50)
* Expire in 2 ms for 1 (transfer 0x558fbf2f8f50)
* Expire in 1 ms for 1 (transfer 0x558fbf2f8f50)
* Expire in 1 ms for 1 (transfer 0x558fbf2f8f50)
* Expire in 4 ms for 1 (transfer 0x558fbf2f8f50)
* Expire in 3 ms for 1 (transfer 0x558fbf2f8f50)
* Expire in 3 ms for 1 (transfer 0x558fbf2f8f50)
* Expire in 4 ms for 1 (transfer 0x558fbf2f8f50)
*   Trying 10.106.156.103...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x558fbf2f8f50)
* Connected to cert-manager-webhook.devops.svc (10.106.156.103) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: O=cert-manager.system
*  start date: Feb 24 01:01:47 2020 GMT
*  expire date: Feb 23 01:01:47 2021 GMT
*  issuer: O=cert-manager.system; CN=cert-manager.webhook.ca
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET /mutate?timeout=30s HTTP/1.1
> Host: cert-manager-webhook.devops.svc
> User-Agent: curl/7.64.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 400 Bad Request
< Date: Mon, 24 Feb 2020 02:47:38 GMT
< Content-Length: 0
<
* Connection #0 to host cert-manager-webhook.devops.svc left intact

The service looks good and is responding.

I resolved my issue. May not apply to everyone, but still.
During cert creation, the API server accesses the webhook. But in my case, the API server cannot access pods in overlay network. So I have webhook running in hostNetwork mode. Now the error is gone.

where are you setting this option? hostNetwork ?

I found it, in the webhook spec. Thanks
webhook:
  hostNetwork: true

This seems to have worked for me also.

I have the same issue with:

Kubernetes version (e.g. v1.10.2): v1.17.0
Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): baremetal (openstack queen)
cert-manager version (e.g. v0.4.0): 0.13.1
Install method (e.g. helm or static manifests): helm 2.16.3

I think it is a timing issue because it was working when I was "manually" installing it, but not anymore in my terraform configuration script. Quite rough but I resolved it by adding a system delay:
sleep 1m

I resolved my issue. May not apply to everyone, but still.
During cert creation, the API server accesses the webhook. But in my case, the API server cannot access pods in overlay network. So I have webhook running in hostNetwork mode. Now the error is gone.

我在我的本地集群中没有发生这个问题，但是在华为云自建集群中，出现的这个问题。不过我是把cert-manager-webhook部署到k8s apiserver服务器上解决了这个问题（node-selector -> master server）,猜测问题可能在于，kube-apiserver需要与Pod对话，但是Pod默认位于我的华为云网络中，apiserver无法通过该网络外部路由到达cert-manager-webhook。这个可能和修改webhook -> hostNetwork功能相同。

@papanito i check coredns and then it works

care to explain what you did with coredns ?

I have run into this problem with:
Kubernetes 1.17.4
cert-manager 0.13.1/0.14.0
installed with and without helm
with and without hostNetwork: true
with flannel and calico cni's
restarted all pods multiple times.
@papanito could you please explain what you did with coredns to get it working.

@h00pz question goes to @javachen as he mentioned

@papanito i check coredns and then it works
Really don't know what that means

Folks I tracked it down to using custom service-dns-domain="k8.example.com" in my kubeadm init.

For the record, I had exactly the same under k3s v1.17.3+k3s1  installed without traefik +  / cert-manager 0.14 installed either with regular manifests or with helm.
After several full cluster removal / recreation, I managed to make it work with :

installing the nginx controller after cert-manager (not sure if it was the cause)
Waiting at each step that everything was up
using the regular cert-manager helm installer 0.14 instructions without any customization

I'm currently facing this on k3s and even with a completely clean system, and "waiting at each step".
I wasn't sure if it was some kind of network timeout or blocking but I confirmed that wasn't the case because certbot worked absolutely fine :(
Unfortunately "Context deadline exceeded" doesn't help for debugging.  There also used to be the option in the helm chart to not use the webhook and that is gone now 👎 so even though I have a working setup on one machine, I cannot with the new machine set up the same unless I go with older versions (and first I have to work out which version removed that option from the helm chart).

Interestingly for me, v0.13.0 does not solve the problem but does improve the error message.
E0325 16:10:08.780439       1 sync.go:81] cert-manager/controller/clusterissuers "msg"="error setting up issuer" "error"="Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: i/o timeout" "resource_kind"="ClusterIssuer" "resource_name"="letsencrypt" "resource_namespace"=""

I have a suspicion that some people are getting this because CloudFlare is returning an ipv6 address in their response for the API DNS lookup.  This is going to hurt for a lot of people because there's all the layers of interaction and ipv6 + kubernetes networking is always pain.
Certainly I am not getting I/O timeouts when running curl on the host machine, but according to that message, I am inside the pod.  Of course, following best security practices, there's no shell in v0.14.0's container so I can't test that theory without building a different container which then is not the official one.  Let's see how deep I can follow this rabbit hole...

The haiku about DNS is true :

It’s not DNS
There is a no way it’s DNS
It was DNS

So, for those who are in this boat who are confused as heck by it, check that you can run dns queries from inside your pods Context deadline exceeded in my case indicated the pod couldn't look up the acme api endpoint.
Also in my case, this was any outbound traffic to the internet at all from pods being blocked.
Furthermore, for those who land here where cert-manager is the first thing they set up on a cluster and are bitten by this : k3s on debian 10 requires you use the legacy iptables command (this may apply to other k8s distros, but definitely does to k3s) - https://github.com/coredns/coredns/issues/2693
I still submit that Context deadline exceeded is a poor error message and something more helpful here would be good.

I also have the same issue, I have permetal cluster and i deployed the cert-manager version 0.14.1 and .014.0 using helm , the official chart.
every thing is working find, all pods on the cert-manager namespaces is up and no errors in the logs.
but when i tried to create issuer and getting error:
Error from server (InternalError): error when creating "test-resources.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: dial tcp 10.96.12.89:443: i/o timeout
I tried to use the hostNetwork: true in pod specs but i got error :
"msg"="error running server" "error"="listen tcp :10250: bind: address already in use"

I have the same issue, sincr kubernetes 1.17. The last kubernetes version was 1.16 wet it workd. I ise centos 7, calico with wxlan and selfsignd root CA. So my problem is not  nfttables or acme api.

same for me,
[root@k8s-m nuk]# kubectl apply -f test-cert-manager.yaml
namespace/cert-manager-test created
Error from server (InternalError): error when creating "test-cert-manager.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: dial tcp 10.102.187.94:443: connect: no route to host
[root@k8s-m nuk]# kubectl get svc,ep -n cert-manager-test
No resources found in cert-manager-test namespace.
[root@k8s-m nuk]# kubectl get svc,ep -n cert-manager
NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/cert-manager           ClusterIP   10.111.69.177           9402/TCP   45m
service/cert-manager-webhook   ClusterIP   10.102.187.94           443/TCP    45m
NAME                             ENDPOINTS          AGE
endpoints/cert-manager           10.32.0.10:9402    45m
endpoints/cert-manager-webhook   10.32.0.11:10250   45m
[root@k8s-m nuk]# kubectl exec -ti dnsutils -- nslookup cert-manager-webhook.cert-manager.svc
Server:		10.96.0.10
Address:	10.96.0.10#53
Name:	cert-manager-webhook.cert-manager.svc.cluster.local
Address: 10.102.187.94
[root@k8s-m nuk]#
it seems there no DNS issue, i tried to spin busybox then..
[root@k8s-m nuk]# kubectl run -i --tty busybox --image=busybox --restart=Never -- sh
If you don't see a command prompt, try pressing enter.
/ # telnet cert-manager-webhook.cert-manager.svc 443
Connected to cert-manager-webhook.cert-manager.svc
/ # ping cert-manager-webhook.cert-manager.svc
PING cert-manager-webhook.cert-manager.svc (10.102.187.94): 56 data bytes
keep digging..

How are you testing if the letsencrypt API is reachable from cert-manager?
And from which pod should I do it?
cert-manager-5d9cd85cbb-96dfb             1/1     Running   0          19m
cert-manager-cainjector-95c885477-bk5r8   1/1     Running   0          19m
cert-manager-webhook-6ff9487489-5z57m     1/1     Running   0          19m

I think I'm facing exactly the same problem:
Events:
  Type     Reason                Age                    From          Message
  ----     ------                ----                   ----          -------
  Warning  ErrVerifyACMEAccount  2m13s (x7 over 7m23s)  cert-manager  Failed to verify ACME account: context deadline exceeded
  Warning  ErrInitIssuer         2m13s (x7 over 7m23s)  cert-manager  Error initializing issuer: context deadline exceeded

Or is it something different?

For me it was an issue with debian 10 and iptables, see here: https://discuss.kubernetes.io/t/kubernetes-compatible-with-debian-10-buster/7853

Would anyone be able to open a PR against the documentation/compatibility page to advise users of what to check if they see this message? Specifically it'd be good to call out/link to information about nftables, as there's clearly quite a few people running into this!
https://github.com/cert-manager/website/blob/master/content/en/docs/installation/compatibility.md
/kind documentation
/remove-kind bug
/area deploy
/priority important-longterm

@munnerz I think that's something I could do

https://github.com/cert-manager/website/pull/187

Hi guys. I have the same issue. Any fixes yet?

One of the problems I found is with a wrapper charts. To reproduce, wrap cert-manager to cert-manager-wrapped chart (e.g. to add a custom cluster issuer)
Webhook service will be named cert-manager-wrapped-webhook, but CRD will point to the original name cert-manager-webhook, which does not exist.

@munnerz did you see my PR? Is that about ok?

I can confirm that I have exactly the same issue. My environment:
EKS v1.16.8
CNI: Calico
Cert-Manager: v0.15.1 installed using HELM
I'm getting error:
Error from server (InternalError): error when creating "ClusterIssuerDns.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: context deadline exceeded
I'm not 100%, but I suspect the issue with a connection from the API to the webhook (Calico creates new subnet, not sure if API is able to access it)...

I resolved my issue. May not apply to everyone, but still.
During cert creation, the API server accesses the webhook. But in my case, the API server cannot access pods in overlay network. So I have webhook running in hostNetwork mode. Now the error is gone.

How did you install?  I am trying helm install, with weave, on eks and I am getting the same errors.  failed calling webhook "webhook.cert-manager.io" - The chart has hostNetwork set to false and it seems most of the instructions on how to get it to work  are using older versions. I tried forking the charts and making the change, but then there was some type of image dependency.  What was your method?

I am having the same issues as @andrewkaczynski

If anyone is interested, we were experiencing these issues in our deployment, and after some debugging I determined it was because while our VM supported the size of frames leaving the boxes, the actual underlying fabric was losing network packets before they arrived at the worker node (where the webhook Pod was running.)
This was fairly easy to prove out using tcpdump on both sides of the connection, and seeing that larger application data packets weren't ever hitting eth0 on the worker.
If this is an MTU problem for you, a potential solution is to check the settings of every interface in your stack (Calico has recommendations for different environments, as you can change the tunl0 device MTU easily enough.

We are running a fresh install of 1.17.7 via kubeadm, using the flannel VXLAN CNI. We're also seeing the following error:
Error from server (InternalError): error when creating "./selfsigned-issuer.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: context deadline exceeded

Doing some googling, I believe this is due to DNS. If I exec onto one of my NGINX pods (using this pod arbitrarily, nothing special about it) and try to resolve the above address, I get this:
nslookup cert-manager-webhook.cert-manager.svc
Server:         10.96.0.10
Address:        10.96.0.10:53

** server can't find cert-manager-webhook.cert-manager.svc: NXDOMAIN
** server can't find cert-manager-webhook.cert-manager.svc: NXDOMAIN

However, when you append .cluster.local (the full domain name), it'll resolve just fine:
bash-5.0$ nslookup cert-manager-webhook.cert-manager.svc.cluster.local
Server:         10.96.0.10
Address:        10.96.0.10:53

Name:   cert-manager-webhook.cert-manager.svc.cluster.local
Address: 10.111.57.175

And as you can see, this is the IP address of my webhook pod:
NAMESPACE              NAME                               TYPE        CLUSTER-IP
cert-manager           cert-manager-webhook               ClusterIP   10.111.57.175

So this is where I get confused... I read that .svc is the equivalent (or rather, short-version) of .svc.local. Why is it not working? Is this configurable? Reading a different issue, some person had to re-create their cluster and supply some DNS options into KubeSpray. However I'm not using KubeSpray.
Appreciate any help, thanks.

Hello,
Just wanted to let everyone know that I have it working now. Some information on our cluster:
Cluster Version: 1.17.7
CNI: Flannel, VXLAN
Provisioner: kubeadm
Cert-Manager version: 0.11.1

What worked for me is the following guide here: https://docs.cert-manager.io/en/release-0.11/getting-started/install/kubernetes.html
It is absolutely important that nothing is lingering around from your old deploy. Run kubectl get crd and delete all (new and old) cert-manager CRD's.
Run kubectl get apiservice and make sure there is nothing related to certificates and certs.
Running kubectl get cert or kubectl get clusterissuer should say something along the lines of "This resource type does not exist" (I don't have the exact error, but you get the point).
Ok, again, make sure all resources are wiped:

Pods and Deployments
Secrets
apiservice
CRD's

Great. Now install the 0.11.1 CRD's:
kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v0.11.1/cert-manager.yaml

Now install cert-manager 0.11.1. Make sure you install 0.11.1, not 0.11.0.... That version doesn't seem to work either.
Great. Now make sure your ClusterIssuer and Certificate's are using the apiVersion: cert-manager.io/v1alpha2.
My Suspicions:
When installing 1.15.11, looking at the kube-apiserver logs, it appears that it's trying to communicate to the webhook service by using its DNS (https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s). As I said above, this short-version of the DNS name does not work for some reason. Maybe it's a kubeadm thing.
When using 0.11.1, it tries to communicate via IP address instead, and I suppose this is what is making it work.
Something important that I found during my research, the kube-apiserver can't actually resolve cluster DNS. The /etc/resolv.conf is inherited from the master node. This is designed intentionally because apparently kube-apiserver is the source of truth for DNS.
Something I don't understand is from a node, why can't you ping a Service ClusterIP? You can do it for any pod on any node, not Services though. So I don't get how the kube-apiserver is making calls to the webhook.
Sorry for rambling. Please let me know if you're still struggling. I can try to help.

I resolved my issue. May not apply to everyone, but still.
During cert creation, the API server accesses the webhook. But in my case, the API server cannot access pods in overlay network. So I have webhook running in hostNetwork mode. Now the error is gone.

我在我的本地集群中没有发生这个问题，但是在华为云自建集群中，出现的这个问题。不过我是把cert-manager-webhook部署到k8s apiserver服务器上解决了这个问题（node-selector -> master server）,猜测问题可能在于，kube-apiserver需要与Pod对话，但是Pod默认位于我的华为云网络中，apiserver无法通过该网络外部路由到达cert-manager-webhook。这个可能和修改webhook -> hostNetwork功能相同。

我在华为云网络自建集群遇到同样的问题。具体怎么操作解决呢？

I can confirm that I have exactly the same issue. My environment:
EKS v1.16.8
CNI: Calico
Cert-Manager: v0.15.1 installed using HELM
I'm getting errors like:
Error from server (InternalError): error when creating "ClusterIssuerDns.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: context deadline exceeded
Error from server (InternalError): error when creating "ClusterIssuerDns.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: Address is not allowed
I'm not 100%, but I suspect the issue with a connection from the API to the webhook (Calico creates new subnet, not sure if API is able to access it)...

I got these problem too..

I am having the same issues too.

I faced this issue today and after hours of investigation I noticed weird x509 related errors when cert-manager was trying to connect to https://acme-staging-v02.api.letsencrypt.org/directory, stating the certificate doesn't belong to the URL. When the pod was running on another node, I got the 'context deadline exceeded'error as well.
As I have a catch-all DNS record in my internal DNS (test) zone pointing to a Traefik load balancer, it appeared the non-matching X509 certificate was the certificate presented by Traefik.
As the other node presenting the context deadline exceeded error is blocked by firewall to that load balancer, this got me thinking and and after going through some internal DNS logs (although I configured cert-manager to use  recursive), I could confirm that cert-manager was trying to resolve letsencrypt.org**.MYINTERNALDOMAIN.LOCAL** This explains why I got the peculiar error on just one of the nodes being able to reach the catch-all host.
After removing the internal domain from dns search (/etc/resolv.conf or in my case search: entry in cloud-config.yml) all started working fine...
So for me the conclusion is that for some reason the DNS suffix is added to the server URL even though the pod is perfectly able to resolve the host provided and removing the search fixes the issue.
Note: I am quite new to k8s so possibly the error was environment specific in my case, but since this issue is open for quite some time, maybe my findings can be helpful.

I can confirm that I have exactly the same issue. My environment:
EKS v1.16.8
CNI: Calico
Cert-Manager: v0.15.1 installed using HELM
I'm getting errors like:
Error from server (InternalError): error when creating "ClusterIssuerDns.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: context deadline exceeded
Error from server (InternalError): error when creating "ClusterIssuerDns.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: Address is not allowed
I'm not 100%, but I suspect the issue with a connection from the API to the webhook (Calico creates new subnet, not sure if API is able to access it)...

I got these problem too..

I can confirm that I have exactly the same issue. My environment:
EKS v1.16.8
CNI: Calico
Cert-Manager: v0.15.1 installed using HELM
I'm getting errors like:
Error from server (InternalError): error when creating "ClusterIssuerDns.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: context deadline exceeded
Error from server (InternalError): error when creating "ClusterIssuerDns.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: Address is not allowed
I'm not 100%, but I suspect the issue with a connection from the API to the webhook (Calico creates new subnet, not sure if API is able to access it)...

I got these problem too..

I resolved using doc https://cert-manager.io/docs/installation/compatibility/#aws-eks

@wallrj is working on this in https://github.com/cert-manager/website/issues/321.
Let's move the convesation there.
/close

I have exactly the same issue，when I try to execute kubectl apply -f test-resources.yaml, I got
Error from server (InternalError): error when creating "test-resources.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/validate?timeout=10s: context deadline exceeded
My environment 1:
Platform: UCloud
OS: CentOS 7.8
Cluster Version: 1.18.8
Node：One master，one worker
CNI: Calico
Provisioner: kubeadm, installed with：https://kuboard.cn/install/history-k8s/install-k8s-1.18.x.html
Cert-Manager version: v1.0.1，installed with regular manifests on worker
After that, I did more experiments。
The environment 2:
Platform: UCloud
OS: CentOS 7.8
Cluster Version: 1.16.6
Node：Three master，no worker
CNI: Calico
Provisioner: Binary installation, installed with：https://github.com/opsnull/follow-me-install-kubernetes-cluster
Cert-Manager version: v1.0.1，installed with regular manifests
I passed the test and everything was fine.
The environment 3:
Platform: UCloud
OS: CentOS 7.8
Cluster Version: 1.17.9
Node：Two master，no worker
CNI: Calico
Provisioner: Kubespray, installed with：https://github.com/kubernetes-sigs/kubespray
Cert-Manager version: v1.0.1，installed with regular manifests
I got the same error.
All these errors can be fixed by using hostNetwork, but I still want to know: why the binary installation can work normally?

I can confirm that I have exactly the same issue. My environment:
EKS v1.16.8
CNI: Calico
Cert-Manager: v0.15.1 installed using HELM
I'm getting errors like:
Error from server (InternalError): error when creating "ClusterIssuerDns.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: context deadline exceeded
Error from server (InternalError): error when creating "ClusterIssuerDns.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: Address is not allowed
I'm not 100%, but I suspect the issue with a connection from the API to the webhook (Calico creates new subnet, not sure if API is able to access it)...

Did you find any solution with calico?

My Solution was: Download the Cert-Manager Manifest and inserting the following Block after each "containers:"-Declaration in the Manifest:
dnsPolicy: "None"       dnsConfig:         nameservers:           - 8.8.8.8           - 8.8.4.4

And my solution was using these changes in yaml file:
Adding the hostNetwork: true to the spec of webhook, and changing the securePort and its relative ports to something other than 10250 (like 10666 that I choose 😄, also don't forget to change the related service), here are the changes:
...
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: webhook
    app.kubernetes.io/component: webhook
    app.kubernetes.io/instance: cert-manager
    app.kubernetes.io/name: webhook
  name: cert-manager-webhook
  namespace: cert-manager
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/component: webhook
      app.kubernetes.io/instance: cert-manager
      app.kubernetes.io/name: webhook
  template:
    metadata:
      labels:
        app: webhook
        app.kubernetes.io/component: webhook
        app.kubernetes.io/instance: cert-manager
        app.kubernetes.io/name: webhook
    spec:
      hostNetwork: true
      containers:
      - args:
        - --v=2
        - --secure-port=10666
        - --dynamic-serving-ca-secret-namespace=$(POD_NAMESPACE)
        - --dynamic-serving-ca-secret-name=cert-manager-webhook-ca
        - --dynamic-serving-dns-names=cert-manager-webhook,cert-manager-webhook.cert-manager,cert-manager-webhook.cert-manager.svc,$(NODE_NAME)
        env:
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        image: quay.io/jetstack/cert-manager-webhook:v1.1.0
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /livez
            port: 6080
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: cert-manager
        ports:
        - containerPort: 10666
          name: https
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz
            port: 6080
            scheme: HTTP
          initialDelaySeconds: 5
          periodSeconds: 5
          successThreshold: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: cert-manager-webhook
---
...
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: webhook
    app.kubernetes.io/component: webhook
    app.kubernetes.io/instance: cert-manager
    app.kubernetes.io/name: webhook
  name: cert-manager-webhook
  namespace: cert-manager
spec:
  ports:
  - name: https
    port: 443
    targetPort: 10666
  selector:
    app.kubernetes.io/component: webhook
    app.kubernetes.io/instance: cert-manager
    app.kubernetes.io/name: webhook
  type: ClusterIP
...

Why is this issue closed ? I am facing same issue, with the helm chart of cert-manager v1.1.0
main.go:38] cert-manager "msg"="error executing command" "error"="listen tcp :10250: bind: address already in use"
@mostafa8026 seems to have corrected the issue by changing the port 10250. Why is this even a port issue ?

did you set the hostNetwork to true? could you please provide your config?

My example using Terraform
resource "helm_release" "cert_manager_calico" {
count            = var.calico_install ? 1 : 0
name             = "cert-manager"
repository       = "https://charts.jetstack.io"
chart            = "cert-manager"
namespace        = "cert-manager"
replace          = true
values = [<<EOF
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: ops/workload
operator: In
values:
- tooling
- key: lifecycle
operator: In
values:
- OnDemand
EOF
]
set {
name  = "installCRDs"
value = "true"
}
set {
name  = "webhook.hostNetwork"
value = "true"
}
set {
name  = "webhook.securePort"
value = "10251"
}
set {
name  = "prometheus.enabled"
value = "true"
}
}

When you use the hostNetwork as true, it has some security issues, it gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node more detail. so it is better to not use this config.
because the hostNetwork is set to true, the port must be set on other config elemnts that I mention earlier.

And my solution was using these changes in yaml file:
Adding the hostNetwork: true to the spec of webhook, and changing the securePort and its relative ports to something other than 10250 (like 10666 that I choose 😄, also don't forget to change the related service), here are the changes:
...
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: webhook
    app.kubernetes.io/component: webhook
    app.kubernetes.io/instance: cert-manager
    app.kubernetes.io/name: webhook
  name: cert-manager-webhook
  namespace: cert-manager
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/component: webhook
      app.kubernetes.io/instance: cert-manager
      app.kubernetes.io/name: webhook
  template:
    metadata:
      labels:
        app: webhook
        app.kubernetes.io/component: webhook
        app.kubernetes.io/instance: cert-manager
        app.kubernetes.io/name: webhook
    spec:
      hostNetwork: true
      containers:
      - args:
        - --v=2
        - --secure-port=10666
        - --dynamic-serving-ca-secret-namespace=$(POD_NAMESPACE)
        - --dynamic-serving-ca-secret-name=cert-manager-webhook-ca
        - --dynamic-serving-dns-names=cert-manager-webhook,cert-manager-webhook.cert-manager,cert-manager-webhook.cert-manager.svc,$(NODE_NAME)
        env:
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        image: quay.io/jetstack/cert-manager-webhook:v1.1.0
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /livez
            port: 6080
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: cert-manager
        ports:
        - containerPort: 10666
          name: https
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz
            port: 6080
            scheme: HTTP
          initialDelaySeconds: 5
          periodSeconds: 5
          successThreshold: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: cert-manager-webhook
---
...
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: webhook
    app.kubernetes.io/component: webhook
    app.kubernetes.io/instance: cert-manager
    app.kubernetes.io/name: webhook
  name: cert-manager-webhook
  namespace: cert-manager
spec:
  ports:
  - name: https
    port: 443
    targetPort: 10666
  selector:
    app.kubernetes.io/component: webhook
    app.kubernetes.io/instance: cert-manager
    app.kubernetes.io/name: webhook
  type: ClusterIP
...

My values.yaml file.
# Default values for cert-manager.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
global:
  ## Reference to one or more secrets to be used when pulling images
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
  ##
  imagePullSecrets: []
  # - name: "image-pull-secret"

  # Optional priority class to be used for the cert-manager pods
  priorityClassName: ""
  rbac:
    create: true

  podSecurityPolicy:
    enabled: false
    useAppArmor: true

  # Set the verbosity of cert-manager. Range of 0 - 6 with 6 being the most verbose.
  logLevel: 4

  leaderElection:
    # Override the namespace used to store the ConfigMap for leader election
    namespace: "kube-system"

installCRDs: false

replicaCount: 1

strategy: {}
  # type: RollingUpdate
  # rollingUpdate:
  #   maxSurge: 0
  #   maxUnavailable: 1

# Comma separated list of feature gates that should be enabled on the
# controller pod.
featureGates: ""

image:
  repository: quay.io/jetstack/cert-manager-controller
  # You can manage a registry with
  # registry: quay.io
  # repository: jetstack/cert-manager-controller

  # Override the image tag to deploy by setting this variable.
  # If no value is set, the chart's appVersion will be used.
  # tag: canary

  # Setting a digest will override any tag
  # digest: sha256:0e072dddd1f7f8fc8909a2ca6f65e76c5f0d2fcfb8be47935ae3457e8bbceb20
  pullPolicy: IfNotPresent

# Override the namespace used to store DNS provider credentials etc. for ClusterIssuer
# resources. By default, the same namespace as cert-manager is deployed within is
# used. This namespace will not be automatically created by the Helm chart.
clusterResourceNamespace: ""

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  # name: ""
  # Optional additional annotations to add to the controller's ServiceAccount
  # annotations: {}

# Optional additional arguments
extraArgs: []
  # Use this flag to set a namespace that cert-manager will use to store
  # supporting resources required for each ClusterIssuer (default is kube-system)
  # - --cluster-resource-namespace=kube-system
  # When this flag is enabled, secrets will be automatically removed when the certificate resource is deleted
  # - --enable-certificate-owner-ref=true

extraEnv: []
# - name: SOME_VAR
#   value: 'some value'

resources: {}
  # requests:
  #   cpu: 10m
  #   memory: 32Mi

# Pod Security Context
# ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
securityContext: {}
# legacy securityContext parameter format: if enabled is set to true, only fsGroup and runAsUser are supported
# securityContext:
#   enabled: false
#   fsGroup: 1001
#   runAsUser: 1001
# to support additional securityContext parameters, omit the `enabled` parameter and simply specify the parameters
# you want to set, e.g.
# securityContext:
#   fsGroup: 1000
#   runAsUser: 1000
#   runAsNonRoot: true

# Container Security Context to be set on the controller component container
# ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
containerSecurityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true

volumes: []

volumeMounts: []

# Optional additional annotations to add to the controller Deployment
# deploymentAnnotations: {}

# Optional additional annotations to add to the controller Pods
# podAnnotations: {}

podLabels: {}

# Optional DNS settings, useful if you have a public and private DNS zone for
# the same domain on Route 53. What follows is an example of ensuring
# cert-manager can access an ingress or DNS TXT records at all times.
# NOTE: This requires Kubernetes 1.10 or `CustomPodDNS` feature gate enabled for
# the cluster to work.
# podDnsPolicy: "None"
# podDnsConfig:
#   nameservers:
#     - "1.1.1.1"
#     - "8.8.8.8"

nodeSelector: {}

ingressShim:
  defaultIssuerName: letsencrypt-staging
  defaultIssuerKind: ClusterIssuer
  # defaultIssuerGroup: ""

prometheus:
  enabled: true
  servicemonitor:
    enabled: false
    prometheusInstance: default
    targetPort: 9402
    path: /metrics
    interval: 60s
    scrapeTimeout: 30s
    labels: {}

# Use these variables to configure the HTTP_PROXY environment variables
http_proxy: "proxy-for-org"
https_proxy: "proxy-for-org"
# no_proxy: 127.0.0.1,localhost

# expects input structure as per specification https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#affinity-v1-core
# for example:
#   affinity:
#     nodeAffinity:
#      requiredDuringSchedulingIgnoredDuringExecution:
#        nodeSelectorTerms:
#        - matchExpressions:
#          - key: foo.bar.com/role
#            operator: In
#            values:
#            - master
affinity: {}

# expects input structure as per specification https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#toleration-v1-core
# for example:
#   tolerations:
#   - key: foo.bar.com/role
#     operator: Equal
#     value: master
#     effect: NoSchedule
tolerations: []

webhook:
  replicaCount: 1
  timeoutSeconds: 10

  strategy: {}
    # type: RollingUpdate
    # rollingUpdate:
    #   maxSurge: 0
    #   maxUnavailable: 1

  securityContext: {}

  # Container Security Context to be set on the webhook component container
  # ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
  containerSecurityContext: {}
    # capabilities:
    #   drop:
    #   - ALL
    # readOnlyRootFilesystem: true
    # runAsNonRoot: true

  # Optional additional annotations to add to the webhook Deployment
  # deploymentAnnotations: {}

  # Optional additional annotations to add to the webhook Pods
  # podAnnotations: {}

  # Optional additional annotations to add to the webhook MutatingWebhookConfiguration
  # mutatingWebhookConfigurationAnnotations: {}

  # Optional additional annotations to add to the webhook ValidatingWebhookConfiguration
  # validatingWebhookConfigurationAnnotations: {}

  # Optional additional arguments for webhook
  extraArgs: []

  resources: {}
    # requests:
    #   cpu: 10m
    #   memory: 32Mi

  ## Liveness and readiness probe values
  ## Ref: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
  ##
  livenessProbe:
    failureThreshold: 3
    initialDelaySeconds: 60
    periodSeconds: 10
    successThreshold: 1
    timeoutSeconds: 1
  readinessProbe:
    failureThreshold: 3
    initialDelaySeconds: 5
    periodSeconds: 5
    successThreshold: 1
    timeoutSeconds: 1

  nodeSelector: {}

  affinity: {}

  tolerations: []

  # Optional additional labels to add to the Webhook Pods
  podLabels: {}

  image:
    repository: quay.io/jetstack/cert-manager-webhook
    # You can manage a registry with
    # registry: quay.io
    # repository: jetstack/cert-manager-webhook

    # Override the image tag to deploy by setting this variable.
    # If no value is set, the chart's appVersion will be used.
    # tag: canary

    # Setting a digest will override any tag
    # digest: sha256:0e072dddd1f7f8fc8909a2ca6f65e76c5f0d2fcfb8be47935ae3457e8bbceb20

    pullPolicy: IfNotPresent

  serviceAccount:
    # Specifies whether a service account should be created
    create: true
    # The name of the service account to use.
    # If not set and create is true, a name is generated using the fullname template
    # name: ""
    # Optional additional annotations to add to the controller's ServiceAccount
    # annotations: {}

  # The port that the webhook should listen on for requests.
  # In GKE private clusters, by default kubernetes apiservers are allowed to
  # talk to the cluster nodes only on 443 and 10250. so configuring
  # securePort: 10250, will work out of the box without needing to add firewall
  # rules or requiring NET_BIND_SERVICE capabilities to bind port numbers <1000
  securePort: 10250

  # Specifies if the webhook should be started in hostNetwork mode.
  #
  # Required for use in some managed kubernetes clusters (such as AWS EKS) with custom
  # CNI (such as calico), because control-plane managed by AWS cannot communicate
  # with pods' IP CIDR and admission webhooks are not working
  #
  # Since the default port for the webhook conflicts with kubelet on the host
  # network, `webhook.securePort` should be changed to an available port if
  # running in hostNetwork mode.
  hostNetwork: false

cainjector:
  enabled: true
  replicaCount: 1

  strategy: {}
    # type: RollingUpdate
    # rollingUpdate:
    #   maxSurge: 0
    #   maxUnavailable: 1

  securityContext: {}

  # Container Security Context to be set on the cainjector component container
  # ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
  containerSecurityContext: {}
    # capabilities:
    #   drop:
    #   - ALL
    # readOnlyRootFilesystem: true
    # runAsNonRoot: true

  # Optional additional annotations to add to the cainjector Deployment
  # deploymentAnnotations: {}

  # Optional additional annotations to add to the cainjector Pods
  # podAnnotations: {}

  # Optional additional arguments for cainjector
  extraArgs:
    - --leader-elect=false

  resources: {}
    # requests:
    #   cpu: 10m
    #   memory: 32Mi

  nodeSelector: {}

  affinity: {}

  tolerations: []

  # Optional additional labels to add to the CA Injector Pods
  podLabels: {}

  image:
    repository: quay.io/jetstack/cert-manager-cainjector
    # You can manage a registry with
    # registry: quay.io
    # repository: jetstack/cert-manager-cainjector

    # Override the image tag to deploy by setting this variable.
    # If no value is set, the chart's appVersion will be used.
    # tag: canary

    # Setting a digest will override any tag
    # digest: sha256:0e072dddd1f7f8fc8909a2ca6f65e76c5f0d2fcfb8be47935ae3457e8bbceb20

    pullPolicy: IfNotPresent

  serviceAccount:
    # Specifies whether a service account should be created
    create: true
    # The name of the service account to use.
    # If not set and create is true, a name is generated using the fullname template
    # name: ""
    # Optional additional annotations to add to the controller's ServiceAccount
    # annotations: {}

I'm seeing this on fresh aks clusters, right after installing of cert-manager, when I create an Issuer. Strange is that 2/3 clusters have this issue, but one of them doesn't, although they are provisioned in the same way.
Starting: kubectl apply LetsEncrypt Staging Issuer
==============================================================================
Task         : Kubectl
Description  : Deploy, configure, update a Kubernetes cluster in Azure Container Service by running kubectl commands
Version      : 1.181.0
Author       : Microsoft Corporation
Help         : https://aka.ms/azpipes-kubectl-tsg
==============================================================================
==============================================================================
			Kubectl Client Version: v1.21.0
			Kubectl Server Version: v1.18.14
==============================================================================
/opt/hostedtoolcache/kubectl/1.21.0/x64/kubectl apply -f /home/vsts/work/_temp/kubectlTask/1620812300598/inlineconfig.yaml -o json
Error from server (InternalError): error when creating "/home/vsts/work/_temp/kubectlTask/1620812300598/inlineconfig.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s: context deadline exceeded
##[error]Error from server (InternalError): error when creating "/home/vsts/work/_temp/kubectlTask/1620812300598/inlineconfig.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s: context deadline exceeded
commandOutput
##[error]The process '/opt/hostedtoolcache/kubectl/1.21.0/x64/kubectl' failed with exit code 1
Finishing: kubectl apply LetsEncrypt Staging Issuer

I am also seeing the same issue. I have a charmed kubernetes cluster running with flannel and calico. I changed the deployment config to use hostnetwork and changed the port and nothing.
Events:
Type     Reason                Age                From          Message

Warning  ErrVerifyACMEAccount  33s (x4 over 73s)  cert-manager  Failed to verify ACME account: context deadline exceeded
Warning  ErrInitIssuer         33s (x4 over 73s)  cert-manager  Error initializing issuer: context deadline exceeded
My DNS working because I can access letsencrypt from any port and the challenge see to have worked.

Hello @meyskens,
Since the webhook is clearly not working properly for a significant portion of the cert-manager users here, would it not be best to give us an option to disable it in the helm chart configuration?
It seems like delaying on this and see folks downgrading is encouraging running old code in production.
The webhook is clearly not very stable and I'm not quite sure what usefulness it actually provides, since there is the most minimal documentation around it.

I have the same issue using My solution is to disable the firewalld in the master node

I have the same issue by
https://github.com/jetstack/cert-manager/releases/download/v1.0.3/cert-manager.yaml
And the solution work for me is to disable the firewalld in the k8s apiserver node.

I have the same issue.
The next solution works for me:
kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook  kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io/cert-manager-webhook

I have this issue.  What I (think) I have discovered is that when connected to a pod, there is a problem in the routing between one pod and other services/pods.  In my case, I think it's my AWS security group being too restrictive, so various pods couldn't talk to each other.

I resolved my issue. May not apply to everyone, but still.
During cert creation, the API server accesses the webhook. But in my case, the API server cannot access pods in overlay network. So I have webhook running in hostNetwork mode. Now the error is gone.

我在我的本地集群中没有发生这个问题，但是在华为云自建集群中，出现的这个问题。不过我是把cert-manager-webhook部署到k8s apiserver服务器上解决了这个问题（node-selector -> master server）,猜测问题可能在于，kube-apiserver需要与Pod对话，但是Pod默认位于我的华为云网络中，apiserver无法通过该网络外部路由到达cert-manager-webhook。这个可能和修改webhook -> hostNetwork功能相同。

我在华为云网络自建集群遇到同样的问题。具体怎么操作解决呢？

do you have resolved this problem ?

This is a very strange issue I've seen it twice in a row in my CI:
Error: UPGRADE FAILED: failed to create resource: Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post "[https://cert-manager-webhook.cert-manager.svc:443/validate?timeout=10s](https://cert-manager-webhook.cert-manager.svc/validate?timeout=10s)": context deadline exceeded
But I tried again after one hour and it works.
Running Kubernetes 1.21 and using cert-manager v1.6.1

I ran into this a second time yesterday.  It turns out that failing webhooks (or indeed any contact with svc/kubernetes) may fail if your IP range of your nodes overlaps with your CNI.  In my case, I luckily was standing up three different clusters yesterday and used 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16 as the node ranges.  The ones on 10.2.0.0/16 and 10.3.0.0/16 worked flawlessly, the one on 10.1.0.0/16 was having all kinds of problems and failing with webhook errors among other things.
Looking deeper, it turns out that on microk8s (or perhaps all installs?) with Calico CNI, the default range for addresses is 10.1.0.0/16, and the routing got all kinds of messed up.  Moving my node range to 10.4.0.0/16 fixed it right up.  So, take a look at your address ranges.  There's no way for K8s to know if it's misconfigured and overlapping.

📢 Update from the cert-manager maintainers:
For those of you encountering problems with the cert-manager webhook, please read @maelvls 's Definitive Debugging Guide for the cert-manager Webhook Pod.

In the context of AWS (EKS), in addition to hostNetwork = true & webhook.securePort = 10260,
I configured NODE security group to accept Ingress 10260/tcp from the Security Group of the Cluster API by specifying the security group attached to the Cluster API as the source.
The security group for the source field on the node security group can be found at EKS console.
<your cluster name> => Networking=>Additional security groups
Make sure that the source security group is correct.
See this post to understand why specifying security group to the source works: https://stackoverflow.com/a/57893722/9956279

I encountered a similar issue, which generated the following error message:
Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded

Upon investigation, I determined that the root cause was a DNS problem within the cluster. To confirm this, I initiated an Alpine pod and executed a ping command, which resulted in a failure when attempting to ping "google.com."
To resolve the issue, I needed to correct the CoreDNS configuration map. In my case, the problem stemmed from an incorrect cluster domain, which was originally set to <wrong-domain>.at.
Here's how I fixed it:
I edited the CoreDNS configuration map to replace <wrong-domain>.at with the correct cluster domain.
# kubectl -n kube-system get configmaps/coredns -o yaml

apiVersion: v1
data:
  Corefile: |-
    .:53 {
        errors
        health {
            lameduck 5s
        }
        ready
        log . {
            class error
        }
        prometheus :9153

        kubernetes <wrong-domain>.at in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
        }
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }
kind: ConfigMap

Additionally, it's worth mentioning that the issue might also be related to IPv6. If you're using IPv6, ensure that the network where the cluster is deployed supports IPv6 as well.

For anyone still encountering the "context deadline exceeded" error from the webhook, please do the following:

Increase the ValidatingWebhookConfiguration and MutatingWebhookConfiguration timeout to its maximum value of 30 seconds, so that the underlying cause of the error is revealed. In cert-manager 1.14 this will become the default value. See https://github.com/cert-manager/cert-manager/pull/6488
Read https://cert-manager.io/docs/troubleshooting/webhook/#error-context-deadline-exceeded
Read https://cert-manager.io/docs/installation/best-practice/#network-requirements-and-network-policy

authors: AMoghrabi Magicloud ManuelSchmitzberger Simon0Liu TonyLuo adam-thg andrewkaczynski aplex bflorat devopstales feichaohao h00pz hampos iMartyn javachen jhughes2112 johannwagner jurgenweber knightXun krmao ltetrel lukasmrtvy madmesi mercer meyskens mokhos mostafa8026 munnerz obensouda papanito pilipchik pyr0hu rahbal randywatson1979 rootsh scrothers smalinskiy snukone sseneca stg609 suisrc sushi86 takahiko-okada techcto tomdb-BE wallrj zzaareer

repo: cert-manager/cert-manager


text:
Helm Add commonLabels option

Add Helm option to add common labels to all installed resources.

/approve

/retest

source: gharchive/pull-request

repo: cert-manager/csi-driver-spiffe

license_type: permissive

license_source: github-api


text:
Pattern matching for "name"?

A very common pattern is to allow anyone to access their own named repository. Thus, if I can successfully authenticate as "jimd", then I should be able to access a repo that is at jimd/.
The current config (seems) not to support it. It should be fairly simple to do the following, though:
acl:
  # All logged in users can access their own images
  - match: {account: "/^(.+)$/", name: "/^\1\/*"}
    actions: ["*]
  # alternate pattern, depending on your regexp engine
  - match: {account: "/^(.+)$/", name: "/^\$1\/*"}
    actions: ["*]

this seems reasonable. i will review a PR implementing this, otherwise it'll need to wait until i have spare time.

wait... this always assumes capture groups come from account, a generic solution would allow capturing anywhere. but would introduce dependencies. how about instead we allow expansion of any field from AuthRequestInfo, which contains:
type AuthRequestInfo struct {
	Account string
	Type    string
	Name    string
	Service string
	Actions []string
}

you could then use ${Account} or something like that, without using regex capturing.

What are the meanings of the other fields?

Account: OK, authenticated user
Type: what is this?
Name: is this the rep in the request, e.g. deitch/myapp?
Service: is this the service in the request, e.g. hub.docker.io or my.private.reg:5000?
Actions: I guess these are ["push","pull"]

Type comes from the request, but currently is always "repository"
Name is the name of the repo, i.e. image (i find this repository/image name duality confusing)
Service also comes from the token request and is configured in registry config's auth.token.service parameter. Thus, even today you could have two completely different registries talking to the same auth server and be able to write completely distinct set of acls for them by matching on service.
Actions are the "scopes" requested. since 1.8 they are always push and pull.

Got it. And these are the same keys that are used in the JSON object under match?

yes

So then there would be special variables in the match, then?
acl:
  # All logged in users on any domain can access their own images
  - match: {account: "/^(.+)$/", name: "${account}"}
    actions: ["*]
  # All logged in users on foo.reg can access their own images
  - match: {account: "/^(.+)$/", service: "foo.reg", name: "${account}"}
    actions: ["*]

That makes sense. Let's start with that. At some point it would need to be more powerful, allowing regex within the variable, but one step at a time.

I will try to find a little time to do a PR.

yes, something like that. you don't need to capture in the account matcher anymore, just make sure it's not empty, i.e. user is authenticated: account: ".+"

Yeah, that makes sense. Easier than the mess of capturing regexp.

Is this it over here?  https://github.com/cesanta/docker_auth/blob/master/auth_server/authz/acl.go#L76

I did manage to patch it, but I am trying to figure out how this is built. What is the bindata doing?

bindata is a way to embed static file (gauth template) into the binary.
all you need should be running make

In theory, yeah. In practice, of course, all of the import paths are hard-coded to github.com/cesanta/docker_auth, because of the go package structure. So I have to change every one of them but not add those to the git commit.
Here was my q to stack overflow: http://stackoverflow.com/questions/32166642/how-to-handle-go-import-absolute-paths-and-github-forks/32166819
I am hating go at this very moment. How did they build such a great language with such disastrous package management?

hear, hear... it's a mess alright. yeah, definitely not just make for you...

I guess I could just put it in $GOPATH/cesanta/docker_auth. This whole rigid go package structure breaks git forks, destroys encapsulation, what a disastrous mess.

PR in.

image with #26 is now in :latest, will push to stable in a couple days.

Excellent! Thank you!

source: gharchive/issue

authors: deitch rojer

license_source: bigquery


text:
metamodel error trying to run tests on JS

Lots of SDK tests fail (but not all). Here's a reproducer:
module simple "1.0.0" {
    import ceylon.test "1.3.2-SNAPSHOT";
}

import ceylon.test {...}

shared class Test1() {
    test shared void runtest1(){
        print("hello2");
    }
}

$ ceylon compile-js && ceylon test-js simple
Note: Created module simple/1.0.0
NODE_PATH=/Users/jvasileff/Dropbox/Repos/ceylon/ceylon/dist/dist/repo:/private/var/folders/cw/vkgzjns15b14q4r5g992gwdw0000gn/T/tmp.4C4jmCpg/modules:/Users/jvasileff/Dropbox/Root/dot.ceylon/repo:/Users/jvasileff/Dropbox/Root/dot.ceylon/cache:[Maven] Aether:[NPM] npm:/private/var/folders/cw/vkgzjns15b14q4r5g992gwdw0000gn/T/tmp.4C4jmCpg/modules
======================== TESTS STARTED =======================
running: simple::Test1
ceylon.language::AssertionError "Assertion failed:
	violated is Class<Object,[]> classModel = c.apply<Object>()
	at DefaultTestInstanceProvider.ceylon (18:19-18:70)"
    at AssertionError (/Users/jvasileff/Dropbox/Repos/ceylon/ceylon/dist/dist/repo/ceylon/language/1.3.2-SNAPSHOT/ceylon.language-1.3.2-SNAPSHOT.js:4124:1)
    at Object.asrt$ (/Users/jvasileff/Dropbox/Repos/ceylon/ceylon/dist/dist/repo/ceylon/language/1.3.2-SNAPSHOT/ceylon.language-1.3.2-SNAPSHOT.js:290:25)
    at cons.defaultTestInstanceProvider$.instance (/Users/jvasileff/Dropbox/Root/dot.ceylon/repo/ceylon/test/1.3.2-SNAPSHOT/ceylon.test-1.3.2-SNAPSHOT.js:1368:5)
    at cons.defaultTestExecutor$.getInstance (/Users/jvasileff/Dropbox/Root/dot.ceylon/repo/ceylon/test/1.3.2-SNAPSHOT/ceylon.test-1.3.2-SNAPSHOT.js:1134:92)
    at cons.defaultTestExecutor$.$wgb9lg$53e (/Users/jvasileff/Dropbox/Root/dot.ceylon/repo/ceylon/test/1.3.2-SNAPSHOT/ceylon.test-1.3.2-SNAPSHOT.js:881:31)
    at cons.defaultTestExecutor$.execute (/Users/jvasileff/Dropbox/Root/dot.ceylon/repo/ceylon/test/1.3.2-SNAPSHOT/ceylon.test-1.3.2-SNAPSHOT.js:847:22)
    at $5fv (/Users/jvasileff/Dropbox/Root/dot.ceylon/repo/ceylon/test/1.3.2-SNAPSHOT/ceylon.test-1.3.2-SNAPSHOT.js:2345:44)
    at cons.taskExecutor$.executionLoop (/Users/jvasileff/Dropbox/Root/dot.ceylon/repo/ceylon/test/1.3.2-SNAPSHOT/ceylon.test-1.3.2-SNAPSHOT.js:3426:1)
======================== TEST RESULTS ========================
run:     0
success: 0
failure: 0
error:   1
skipped: 0
aborted: 0
time:    0s

simple::Test1.runtest1 - error (ceylon.language::AssertionError "Assertion failed:
	violated is Class<Object,[]> classModel = c.apply<Object>()
	at DefaultTestInstanceProvider.ceylon (18:19-18:70)")

======================= TESTS FAILED ! =======================
ceylon test-js: Node process exited with non-zero exit code: 100

Seems to be fixed now: https://github.com/ceylon/ceylon/commit/e0107ed4673f3aad98b3838a7087691d402baaf0

authors: jvasileff quintesse

repo: ceylon/ceylon


text:
SEC-1051: restricted inline-styles to improve CSP

Ticket: SEC-1051
Changelog: None
Signed-off-by: Mikita Pilinka mikita.pilinka@northern.tech

@mineralsfree please check staging

authors: aleksandrychev mineralsfree

repo: cfengine/build-website

license: MIT


text:
[Suggestion] [1.19.2 Fabric] REI Compat

REI Compat for soda maker and/or grilling

Agreed. This mod would seriously benefit from it. @cflip

Is there a simple API I can use to add support? The grill uses smoking recipes if I recall correctly so that should automatically be supported.

https://www.craft.me/s/qj8mHyTVd7qkOZ
https://www.curseforge.com/minecraft/mc-mods/roughly-enough-items
https://github.com/shedaniel/RoughlyEnoughItems

repo: cflip/GrillinGalore


text:
CFPB Django App Skeleton

Based on a few conversations I've been involved with recently, we need to define what a "normal" Django app is at CFPB, how it works, and what it includes.
To help with my work on #5, I've created a Django app skeleton that includes some rudimentary front-end stuff (still an area that needs work and collaboration from @cfpb/front-end-team-admin). It is wrapped up with a script to make it easy to create a new CFPB Django app, along with some test scaffolding (Travis, basic test requirements, flake8, and tox for running multiple Python environment tests locally).
This is all in an installable Python package.
I'd welcome any thoughts.
The skeleton is here:
https://github.com/willbarton/cfpb-django-app
And the resulting project is here:
https://github.com/willbarton/myapp

I will add, some of this is based on the work that's been done in in https://github.com/cfpb/college-costs.
I would like to create something a little more like 18F's go script than the develop.sh script currently is (though I really, really dislike the overloading of Go's go that 18F has done).

repo: cfpb/back-end


text:
Create and group test type gulp tasks

Create gulp tasks that group tests on a per high-level type, versus specific implementation. This will help make the build pipeline easier to standardize across projects.
gulp test:unit → JS unit testing, macro, and processor tests.
gulp test:acceptance → browser tests. (I incorrectly thought these would be integration tests, but looks like they're higher level than that.)
References:
http://stackoverflow.com/questions/4904096/whats-the-difference-between-unit-functional-acceptance-and-integration-test
http://image.slidesharecdn.com/2010604buildingthetestingpipeline-100607161146-phpapp02/95/building-the-testing-pipeline-26-728.jpg?cb=1275927238

This was fixed in https://github.com/cfpb/cfgov-refresh/pull/859

repo: cfpb/cfgov-refresh


text:
Remove tax-time-saving from urls.py

This page has moved into Wagtail (http://[content server]/admin/pages/319/) and no longer requires these URL rules.
This was marginally more effort than reviewing and deploying cfpb/tax-time-saving#9 and cfpb/tax-time-saving#10, and furthers our goal of moving all basic content into Wagtail.
Removals

tax-time-saving rules from urls.py

Testing

This can be tested on the content server now; I tested this update live on the server.

Review

@rosskarchner
@cfpb/cfgov-backends

Todos

When this is deployed, deprecate the tax-time-saving repo and remove its jobs from Jenkins.

Checklist

[x] Changes are limited to a single goal (no scope creep)
[x] Code can be automatically merged (no conflicts)
[x] Code follows the standards laid out in the front end playbook
[x] Passes all existing automated tests
[x] New functions include new tests
[x] New functions are documented (with a description, list of inputs, and expected output)
[x] Placeholder code is flagged
[x] Visually tested in supported browsers and devices
[x] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)

👍 x 💯

authors: Scotchester rosskarchner


text:
Remove browserSync and gulp watch

browserSync is in dependencies because it's a dependency in production as part of the gulp workflow, but it is not run. browserSync also has snyk reported vulnerabilities https://snyk.io/test/npm/browser-sync. This PR sets up an architecture to keep it in devDependencies.
Additions

Adds browser-sync utility for running browser-sync dependency in non-production environments.

Removals

Removes browsersync gulp task and merges it with the watch task.
browser-sync dependency.
gulp watch task.

Changes

Sets the NODE_ENV value in cli_flags.sh

Testing

Run ./frontend.sh to get into development state.
Run gulp watch and see that it runs.
Edit a CSS file (like main.less) and save it and see that it re-compiles.
Edit a JS file (like common.js) and save it and see that it re-compiles.
ctrl+c to quit watch.
Run ./frontend.sh production to get into production state.
Run gulp watch and see that it says NODE_ENV is in production.
Run gulp build and see that it passes.

Todo

If you run ./frontend.sh production first it modifies package-lock.json, and when ./frontend.sh is run subsequently, the devDependencies aren't installed—requiring npm install be run between the two. This PR should not be merged before this is resolved.

browser-sync has been removed. Ready for review again. Thanks!


text:
Need validation on adding/removing users on the user management page

When you add a new user there's no indication if it failed or not. Same with removing.

Is this resolved now? If not, let's chat.

There is no visual indicator that something went wrong. It shouldn't be too hard to add though.

authors: dgreisen-cfpb himedlooff

repo: cfpb/devdash


text:
Adds GH issue/PR templates

Additions

Adds auto-generation of PR/issue template when creating PRs/issues.

Testing

After merging this, it shouldn't be necessary to copy/paste the issue or PR template when opening PRs/issues. I don't think this can be tested till it's merged.

Review

@Scotchester
@contolini

Screenshots

Thanks for updating this, completely forgot about this repo 👍

authors: anselmbradford jimmynotjim

repo: cfpb/generator-cf


text:
Status codes meaning

Package
dio
Version
5.7.0
Operating-System
Android
Adapter
Default Dio
Output of flutter doctor -v
No response
Dart Version
No response
Steps to Reproduce
Post false credentials to sign-in api en
Expected Result
The status code of 401 has the following meaning: : "unauthorized access due to invalid or missing credentials"
Actual Result
The status code of 401 has the following meaning: "Client error - the request contains bad syntax or cannot be fulfilled"

Closing as intended. We don't want to reference all status code meanings here which is redundant. The MDN link has been provided through the exception.

repo: cfug/dio


text:
请问改变输入输入网络图片大小都需要改变什么

我现在在做车道线检测和目标检测联合部署，但是发现两个模型的输入需要的图片大小不一致，所以要做两次resize，图片预处理耗时比较严重，我现在希望模型检测的时候可以统一做一个resize，所以想在训练图片的时候就统一大小，比如我现在train_h等于360，train_w等于640，我发现改变train_h参数的时候模型可以训练，但是改变train_w就会报错，我想问一下我需要改什么参数才不报错。非常希望能回复我

@Handaphoser
会报什么错呢？

我设置了以下参数
train_width= 640#800
train_height=360 #320
train_w改变不报错，改了train_h报错
File "/media/huangzd5/handaphoser/projects/Ultra-Fast-Lane-Detection-v2-master/model/model_culane.py", line 54, in forward
fea = fea.view(-1, self.input_dim)
RuntimeError: shape '[-1, 1760]' is invalid for input of size 15360

@Handaphoser
因为设置的train_height不是32的倍数，网络在下采样32倍时不是规整的网格，你可以将train_height设置为352。或者如果你就是想让train_height变为360，那么相应的计算输入维度的时候，你就需要改一下这个部分的代码：
https://github.com/cfzd/Ultra-Fast-Lane-Detection-v2/blob/849fa7b90c189b646d12adc1d807bec54e982031/model/model_culane.py#L24

好的，非常感谢。另外还有一个问题，
demo.py
if valid_row[0,:,i].sum() > num_cls_row / 2:
if valid_col[0,:,i].sum() > num_cls_col / 4:
为什么一个除以4.一个除以2

@Handaphoser
这个就是一个超参，代表你想过滤掉多短的车道线，一般来说，车道线从竖直方向上来看，会占图像的一半，从水平方向来看，会占图像的1/4左右。所以就设置为了对于长度小于半个高度的车道线，或者长度小于1/4宽度的车道线，直接过滤掉。

嗯嗯，刚才看了一下确实是这样的。谢谢答疑

authors: Handaphoser cfzd


text:
Backup on interval

Hi @cgcel,
This tool is fantastic for pairing with Google Drive/File Stream, iCloud, Dropbox, etc without having to setup complex syncers like other plugins.
However, I wish it had a backup on interval function rather than just a backup on startup. Is this something you'd be interested in adding?
For example, backing up the vault every 10 minutes while deleting previous backups to save on storage.
Thanks!
Matt

Looks great, I will add this feature to the plugin.

Thank you for the quick reply! I look forward to it!
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
On Wed, Oct 18, 2023 at 11:27 PM GC Chen @.***> wrote:

Looks great, I will add this feature to the plugin.
—
Reply to this email directly, view it on GitHub
[https://github.com/cgcel/obsidian-local-backup/issues/1#issuecomment-1770033234],
or unsubscribe
[https://github.com/notifications/unsubscribe-auth/ACWQ7S4XIUMXMZNCKVV67GTYAC247AVCNFSM6AAAAAA6GSPG4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZQGAZTGMRTGQ].
You are receiving this because you authored the
thread.[https://ci6.googleusercontent.com/proxy/XYfJQ0aunTuthtpRXgsFUXbEXPiHqOEIayrFpXLO3GXVrJzzsbcCEM-HgAsvP-F4gQ7nR1hj6igfoQX8iJv9rqnyEGuPzPpmJxohUSzesjPa66KQ8Kys-BAeI3plmWqdiUquabjz33cGHqYl-C-3IcQA6x3_b1knET5RTRbFKiczeVua27cIm4Yz4hXA7z9QBCAXQGwhCCb8DDIZMJJZsmc6qTyflaAhbmcE1hG7Js7mYDxJ7A=s0-d-e1-ft#https://github.com/notifications/beacon/ACWQ7S5BDSJEWTSOVJKJBQTYAC247A5CNFSM6AAAAAA6GSPG4GWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTJQCIFE.gif]Message
ID: @.***>

Hi, 0.0.6 released just now, have a try on interval backup, I suggest to set a normal interval (like >=10min) because this plugin costs cpu io resources.

authors: cgcel mswdev

repo: cgcel/obsidian-local-backup


text:
Missing offline-markers in lists

The orange markers indicating offline-logs are not visible in all lists.

Why do you consider this high priority?

because this must be solved as fast as possible. Most of the users (or at least many of them) are using this feature and would complain if it's missing.
But this is the same issue as the two other ones, so we can close it.

authors: Bananeweizen SammysHP

repo: cgeo/c-geo-opensource


text:
Add support for bitmap "layers" with transparency support

So we can implement fusion and segmentation masks natively in the rendering pipeline

A couple of quick notes:

It would be useful to be able to select multiple imageIds, preferably with embedded image registration references (i.e. RCS in DICOM Registration References) or discrete image registration definitions within Cornerstone, as the different layers. I've worked around the issue already without layers by doing CSS-based overlays, but it certainly doesn't provide the same effect as actual layering would.
When layering, it would be good to have the ability to transform the layers via a simple API once created as well (i.e. storing original layer references for effectively non-destructive layering). A good use case would be creating an image registration system where you might want to layer two or more imaging modalities on top of each other to align them, but the application needs to be able to modify the two layers independently.

OK had some time to think about this a bit.  Making this as flexible as it needs to be is going to increase the complexity of cornerstone core which is something I want to avoid.  I am starting to think we should make the rendering pipeline pluggable and move this whole thing into another library.
I don't see any issue with doing transformations on the layers.  I am thinking we will keep the design "immediate mode" rather than "retained mode".  So if you adjust the transformation, you would have to trigger an invalidation as well.
DICOM SEG objects have a concept called "FRACTIONAL" which contain a value per point between 0-255 that would probably map transparency or a color table.  Still researching this one to make sure I understand it fully.

Here is a live demo of what I have so far:
https://rawgit.com/swederik/cornerstone/composition/example/layers/index.html
It needs a ton of work, obviously.

This is finally available. Example here: https://rawgit.com/chafey/cornerstone/master/example/layers/index.html

authors: chafey mko swederik

repo: chafey/cornerstone

license: mit


text:
Polygon ROI

Along the lines of the rectangle ROI but with the ability to specify multiple knot points.
Something like this: http://ttic.uchicago.edu/~smaji/projects/mturk/interfaces/segmentation/person.html?category-image=person,2011_000745_10.jpg which has some cool features for detecting a closed polygon and indicating such (floating dot gets larger when near initial point).
Also see OsiriX which has the feature albeit with some smoothing offered:
https://osirixpluginbasics.wordpress.com/2010/11/27/polygon-roi-tcpolygon-topolygon-tpencil/

The polygon tool is basically a specific version of: https://github.com/chafey/cornerstoneTools/issues/35.
Perhaps the freehand tool just needs an option to always force the "straight line mode".

this would be something nice to have, looking forward to this.

@JamesAPetts, I believe the freehand tool more closely resembles what this issue wanted to accomplish. Is that correct?
This issue has seen little activity in 2-years, so I'll close it for now. Feel free to comment if my assumptions are off, or if there are relevant action items for our freehand tool.

authors: cancan101 dannyrb snagytx

repo: chafey/cornerstoneTools


text:
按照go相关文档操作，浏览器只是列出目录中的文件

https://github.com/golang/go/wiki/WebAssembly
os: windows10
brower: chrome68
浏览器只是列出目录中的文件,并没有允许

必须要启动web服务，不能直接用浏览器打开本地文件

看错了，你需要修改html文件，将wasm改为对应的名字。然后打开html页面


text:
chore(rollup): update rollup to the latest version

Closes #100 and #97
Can be merged after #113

@keithamus any updates?

@keithamus please check this one as well. I updated it

repo: chaijs/chai-spies


text:
[backport] Fix docstrings in computational_graph

Backport of #4984

Jenkins, test this please.

Jenkins CI test (for commit b67ae34dabd00c9da8e6e84ad30cd8900b8049cf) succeeded without errors!

authors: chainer-ci kmaehashi

repo: chainer/chainer


text:
test-setup-kind: fails for kubernetes version 1.24 due to incompatibility issues

I found in the logs of knative activator deployment 2023/08/09 16:04:49 Failed to get k8s version kubernetes version "1.24.15" is not compatible, need at least "1.25.0-0" (this can be overridden with the env var "KUBERNETES_MIN_VERSION")
You can find one occurrence of this issue here: https://github.com/chainguard-dev/actions/actions/runs/5811350964/job/15754381602?pr=292#step:6:431

closing this issue as fixed here: https://github.com/chainguard-dev/actions/pull/292

repo: chainguard-dev/actions


text:
ctypes - missing

Pleas provide missing ctypes.pas unit.

Unit ctypes is part of Free Pascal. With what compiler or platform are you trying to compile for?

I'm using Delphi, looking for an MQTT client library, didn't know FPC had this file. Sorry.

I'd be happy if someone added Delphi compatibility into this library. Most likely this can be done by adding a Delphi-specific ctypes unit (by adapting FPC's maybe?), and maybe a few syntax changes here or there. But I'm not going to do it myself, as Delphi is not my particular interest. Pull requests are welcomed though. Closing, as the original issue is solved.

authors: chainq jaclas

repo: chainq/mosquitto-p

license: ISC


text:
添加英文 README 翻译

我很喜欢 Pinghsu 这个主题！
添加了英文的 README 翻译，希望能merge，谢谢！

合了

authors: ZigaoWang chakhsu

repo: chakhsu/pinghsu


text:
Atomic recipe variants with enums does not work

Description
Hello there,
When I try to use enums as a variant value, the class name is properly generated on the JSX side, but the CSS is not.
The issue is occuring in both sva and cva.
If I replace the enum with the string value, everything works as expected.
Link to Reproduction
https://play.panda-css.com/4A7xKO7CnE
Steps to reproduce
You can see on the playground link that the JSX is containing the class name but there are no styles attached to it.
JS Framework
React (TS)
Panda CSS Version
0.16.0
Browser
Google Chrome 118
Operating System

[ ] macOS
[ ] Windows
[X] Linux

Additional Information
No response

the fix would be to use an object instead of an enum
const Size = {
S: 's',
L: 'l',
};

Thanks @astahmer for the workaround.
Is this a limitation of PandaCSS or can we expect to have the enum support at some point?

coming next version probably

just ran into this, could it be prevented somehow (perhaps with the eslint plugin) if its not going to be supported?

authors: astahmer fseglard hjoelh

repo: chakra-ui/panda


text:
[Suggestion] Update all prices

What's your suggestion?
a simple 1 click solution to update all currently listed items without having to go though the whole list item by item

#51

authors: Cyenia Ninjistix

repo: chalkos/Marketbuddy


text:
name not corrected

@changcheng967 so bad!
did not change the name of the readme.md engine name to kata_speed!

finished


text:
Infinite loop makes changeset version command hang

Affected Packages
@changesets/git
Problem
a loop that never ends
https://github.com/atlassian/changesets/blob/18d3da3b707fe834e0bb1cddce1186bb24b75ef2/packages/git/src/index.ts#L112
Proposed solution

Even if there is a constant condition there this loop should not be infinite. There are multiple breaks in it and one of them should get hit by design. This is clearly a bug (it shouldn't hang) but I wouldn't blame this on this while statement.
Do you have some link to a repro case? Some GH action run perhaps?

I don't have a repro currently because it hangs on a private repository in our Jenkins. But I know for sure that this is the part that hangs infinitely. When I changed that line to while (false), the publish proceeded.

Would you be able to patch the content of this function with some extra console.logs and rerun the failing job to investigate this?

deepenCloneBy() does not check if the git command was successful. It fails over and over and the loop continues indefinitly.
https://github.com/atlassian/changesets/blob/18d3da3b707fe834e0bb1cddce1186bb24b75ef2/packages/git/src/index.ts#L164-L166

Ok, thanks - that is good to know! I will try to make sure to wrap all those git calls with some error handling unless somebody beats me to it.

spawn will never throw an exception, it just return a response with code != 0

Yeah - I know. I've just referred to this kind of check as error handling. After all, if this would actually throw then there wouldn't be a problem as the while loop would be just terminated. And this is my actual plan right now: throw for code != 0. I would like to first learn more about why this fails in your case to decide if we should keep throwing or if we should simply return commit: null or smth in such scenarios.

We run snapshot releases on pull requests and seems like there is no Git in the container that runs the release. Even if there is, I don't think fetching the history is a good idea as our repository is very big and it would cause a major slowdown. I think at least for snapshot releases it should not fail.

@zkochan I've prepared a PR to fix the infinite loop: https://github.com/atlassian/changesets/pull/584
I would still need to get a little bit more information about your setup to address this in a better way. Is your workflow file public so I could take a look at it?

No, it is not public.
It is a project that uses git shallow cloning. It appears that the Git CLI was present. I can't investigate it further because I already spent a lot of time on it and the fork that I created solves the issue.
The lack of debug information made it impossible to investigate (I tried the --verbose flag). If some debugging info will be added, it will be easier to figure out the reason next time.

I also get a infinite loop with all packages fixed in pre mode.
changeset pre enter alpha
Running with debugger
node --inspect-brk node_modules/@changesets/cli/bin.js version
Seems to loop forever in assemble-release-plan

@fivethreeo could you share a repro case? It's hard to debug this & fix it for me without one

https://github.com/jaredpalmer/razzle/tree/alpha

Thank you for the link - could you list your exact repro steps though? You have mentioned running yarn changeset pre enter alpha but this just results in:
$ /workspace/razzle/node_modules/.bin/changeset pre enter alpha
🦋  error `changeset pre enter` cannot be run when in pre mode
🦋  info If you're trying to exit pre mode, run `changeset pre exit`
error Command failed with exit code 1.

I already ran that, just run the version command.

releasesValidated seems to never become true in the while loop

dependentAdded and fixedConstraintUpdated are always true. I forced them to be false in debugger and version completes successfully.

so I think releases get mutated by both determineDependents and matchFixedConstraint for every while loop

If I remove fixed from config it works

Thanks for looking into this - I should have a fix for this soon-ish

Any updates on when the fix for handling the git errors will be merged? I'm running into this issue as well when the git fetch --deepen call fails.
For my particular use case, I was running into the error fatal: error in object: unshallow which I was able to fix with a git repack -d, but it would be nice if changeset version showed the error instead of hanging.

authors: Andarist echo99 fivethreeo zkochan

repo: changesets/changesets


text:
Main overflow scroll 삭제

현재상황

https://github.com/channel-io/design-system/blob/0439d8d753f6dddcde0295e2dd938f532fb5a83d/src/layout/Main/Main.styled.ts#L23-L24
해당 코드로 인해 항상 스크린샷과 같이 Main 영역 하단에 빈 스크롤바가 표시됨.
재현 방법
Windows에서 테스트, 또는 macOS에서 스크롤 막대 보기: 항상 설정
기대한 동작
https://github.com/channel-io/design-system/pull/229#discussion_r576099222
화면 width가 적을 때 가로 스크롤이 되는 것을 기대한 것으로 보임
실제 동작
항상 의미없는 empty 스크롤바가 나오고 있음.
Reference

scroll 삭제를 넘어서 근본적으로 화면 너비가 부족할 때 레이아웃 간의 동작을 수정해야 합니다.

repo: channel-io/bezier-react