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

"Waiting for next available executor" #6661

Closed
fabriziocucci opened this Issue Dec 29, 2016 · 14 comments

Comments

Projects
None yet
7 participants
@fabriziocucci

fabriziocucci commented Dec 29, 2016

I'm on OSX El Capitan and I'm definitely new of fabric8, so bear with me.

I started with this, followed by this.

Now if I run:
kubectl get pods

I get the following:

configmapcontroller-3703242456-f9ctf       1/1       Running   3          15h
exposecontroller-2934573704-pp18d          1/1       Running   3          15h
fabric8-3192130638-a4gq5                   2/2       Running   6          15h
fabric8-docker-registry-1981087684-yyxee   1/1       Running   3          15h
fabric8-forge-3730694965-h7w6b             1/1       Running   1          15h
gogs-3384048149-qru2j                      1/1       Running   2          15h
jenkins-1661962136-mgdsr                   1/1       Running   2          15h
nexus-3628846063-fi18n                     1/1       Running   3          15h

I've created a new Java WAR project in the default team with the CanaryRelease. The following two commits have been automatically generated:

devops-edit --from=fabric8/tomcat-8 --pipeline=maven/CanaryRelease/Jenkinsfile
gogsadmin committed
project-new --type=Java Web Application (WAR) --topLevelPackage=org.example --version=1.0.0-SNAPSHOT --stack=None --targetLocation=/tmp/fabric8-forge/user/gogsadmin --named=third --buildSystem=Maven
gogsadmin committed 

The first build is triggered and the output is the following:

...
First time build. Skipping changelog.
[Pipeline] podTemplate
[Pipeline] {
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor 

...and it stays like this forever!

In the Jenkinksfile, I noticed this:

...
def label = "buildpod.${env.JOB_NAME}.${env.BUILD_NUMBER}".replace('-', '_').replace('/', '_')
...
node(label) {
...
}

But if I open Jenkins, I can see that there is only the master node and the build is blocked in the queue (because there is no node with that label?).

Any help would be much appreciated! 😄

@donshoarma

This comment has been minimized.

Show comment
Hide comment
@donshoarma

donshoarma Dec 29, 2016

We have the same issue:

When running a build I ran into the following problem:
(Pipeline logging)

/usr/bin/git rev-list 057e306664e9afbb8e2d7bc08cc83b98871fad56 # timeout=10
[Pipeline] podTemplate
[Pipeline] {
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor

(Jenkins system logging)
Dec 29, 2016 12:13:09 PM INFO org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision

Excess workload after pending Spot instances: 1

Dec 29, 2016 12:13:09 PM WARNING org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision

Failed to count the # of live instances on Kubernetes
java.lang.NullPointerException
at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.addProvisionedSlave(KubernetesCloud.java:639)
at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.provision(KubernetesCloud.java:510)
at hudson.slaves.NodeProvisioner$StandardStrategyImpl.apply(NodeProvisioner.java:701)
at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:307)
at hudson.slaves.NodeProvisioner.access$000(NodeProvisioner.java:60)
at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:798)
at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

donshoarma commented Dec 29, 2016

We have the same issue:

When running a build I ran into the following problem:
(Pipeline logging)

/usr/bin/git rev-list 057e306664e9afbb8e2d7bc08cc83b98871fad56 # timeout=10
[Pipeline] podTemplate
[Pipeline] {
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor

(Jenkins system logging)
Dec 29, 2016 12:13:09 PM INFO org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision

Excess workload after pending Spot instances: 1

Dec 29, 2016 12:13:09 PM WARNING org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud provision

Failed to count the # of live instances on Kubernetes
java.lang.NullPointerException
at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.addProvisionedSlave(KubernetesCloud.java:639)
at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.provision(KubernetesCloud.java:510)
at hudson.slaves.NodeProvisioner$StandardStrategyImpl.apply(NodeProvisioner.java:701)
at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:307)
at hudson.slaves.NodeProvisioner.access$000(NodeProvisioner.java:60)
at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:798)
at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

@ambition-consulting

This comment has been minimized.

Show comment
Hide comment
@ambition-consulting

ambition-consulting Dec 30, 2016

Same here, windows host with minikube virtualbox client.

ambition-consulting commented Dec 30, 2016

Same here, windows host with minikube virtualbox client.

@ambition-consulting

This comment has been minimized.

Show comment
Hide comment
@ambition-consulting

ambition-consulting Dec 30, 2016

I think this might be related to a known jenkins kubernetes-plugin bug that got introduced with kubernetes 1.5.1?

ambition-consulting commented Dec 30, 2016

I think this might be related to a known jenkins kubernetes-plugin bug that got introduced with kubernetes 1.5.1?

@ambition-consulting

This comment has been minimized.

Show comment
Hide comment
@ambition-consulting

ambition-consulting Dec 30, 2016

yep, manually updating the plugin (on /pluginManager/) fixed the problem.

ambition-consulting commented Dec 30, 2016

yep, manually updating the plugin (on /pluginManager/) fixed the problem.

@rawlingsj

This comment has been minimized.

Show comment
Hide comment
@rawlingsj

rawlingsj Dec 30, 2016

Contributor

Issues with running on kuberentes >= 1.5.0 should be fixed in the next release which is currently being staged before QA and promotion. Hopefully this will be resolved by the morning.

Contributor

rawlingsj commented Dec 30, 2016

Issues with running on kuberentes >= 1.5.0 should be fixed in the next release which is currently being staged before QA and promotion. Hopefully this will be resolved by the morning.

@ambition-consulting

This comment has been minimized.

Show comment
Hide comment
@ambition-consulting

ambition-consulting Dec 30, 2016

any estimates on when that next release might happen?

ambition-consulting commented Dec 30, 2016

any estimates on when that next release might happen?

@rawlingsj

This comment has been minimized.

Show comment
Hide comment
@rawlingsj

rawlingsj Dec 30, 2016

Contributor

The aim is by the morning. I've successfully tested a java project pipeline on minikube v0.14.0 locally. Everything is pushed and the release train that contains various fixes is chugging away.

Provided there's no more significant issues that are found relating to the kubernetes 1.5.x upgrade fabric8's own release pipelines should finish later tonight / early tomorrow.

Contributor

rawlingsj commented Dec 30, 2016

The aim is by the morning. I've successfully tested a java project pipeline on minikube v0.14.0 locally. Everything is pushed and the release train that contains various fixes is chugging away.

Provided there's no more significant issues that are found relating to the kubernetes 1.5.x upgrade fabric8's own release pipelines should finish later tonight / early tomorrow.

@ambition-consulting

This comment has been minimized.

Show comment
Hide comment
@ambition-consulting

ambition-consulting Dec 30, 2016

nice - great work! :)

ambition-consulting commented Dec 30, 2016

nice - great work! :)

@rawlingsj

This comment has been minimized.

Show comment
Hide comment
@rawlingsj

rawlingsj Dec 30, 2016

Contributor

@amb-it-ion scrap that - the release pipeline is stuck ATM unfortunately. This may get sorted soon but it's difficult to say when as most folks are on holidays for the festive season. To track the current block in the pipeline you can watch fabric8io/fabric8-maven-plugin#749

Contributor

rawlingsj commented Dec 30, 2016

@amb-it-ion scrap that - the release pipeline is stuck ATM unfortunately. This may get sorted soon but it's difficult to say when as most folks are on holidays for the festive season. To track the current block in the pipeline you can watch fabric8io/fabric8-maven-plugin#749

@fabriziocucci

This comment has been minimized.

Show comment
Hide comment
@fabriziocucci

fabriziocucci Dec 31, 2016

For some reason, I can't update the Kubernetes plugin in Jenkins:

Latest version: 0.10
Installed version: 0.10-SNAPSHOT (private-6ae0cf4c-iocanel)

I tried both automatically and manually, but after the Jenkins restart the plugin seems to be still the old one (i.e. the plugin is still visible in the Updates tab of the Plugin Manager).

fabriziocucci commented Dec 31, 2016

For some reason, I can't update the Kubernetes plugin in Jenkins:

Latest version: 0.10
Installed version: 0.10-SNAPSHOT (private-6ae0cf4c-iocanel)

I tried both automatically and manually, but after the Jenkins restart the plugin seems to be still the old one (i.e. the plugin is still visible in the Updates tab of the Plugin Manager).

@rawlingsj

This comment has been minimized.

Show comment
Hide comment
@rawlingsj

rawlingsj Jan 12, 2017

Contributor

BTW this should have been fixed a few releases back sorry, please reopen if there's any problems.

Contributor

rawlingsj commented Jan 12, 2017

BTW this should have been fixed a few releases back sorry, please reopen if there's any problems.

@rawlingsj rawlingsj closed this Jan 12, 2017

@jackjacek

This comment has been minimized.

Show comment
Hide comment
@jackjacek

jackjacek Jan 17, 2017

I'm on kubernetes 1.5.1 and kubernetes-pugin 0.10-SNAPSHOT (private-70e60d4e-jamesrawlings). If I push to 50+ repos simultaneously the pipeline gets stuck within minutes. Any suggestions?

jackjacek commented Jan 17, 2017

I'm on kubernetes 1.5.1 and kubernetes-pugin 0.10-SNAPSHOT (private-70e60d4e-jamesrawlings). If I push to 50+ repos simultaneously the pipeline gets stuck within minutes. Any suggestions?

@ikke44

This comment has been minimized.

Show comment
Hide comment
@ikke44

ikke44 May 1, 2017

I still experience this very issue although I am on the latest version of Fabric8 (as per https://raw.githubusercontent.com/fabric8io/gofabric8/master/version/VERSION) with a recent Minikube:

$ gofabric8 version
gofabric8, version 0.4.121 (branch: 'master', revision: '835aa16')
  build date:       '20170306-10:48:35'
  go version:       '1.7.1'
$ minikube version
minikube version: v0.17.1

You can very easily reproduce this error by creating a 'Pipeline script from SCM' Jenkins job that tries to build the 'Release' Maven sample:
1/ Repository URL = https://github.com/fabric8io/fabric8-jenkinsfile-library.git
2/ Script path = \maven\Release\Jenkinsfile

It results in this 'Console Output' in Jenkins that continues 'forever':

Started by user anonymous
 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url https://github.com/fabric8io/fabric8-jenkinsfile-library.git # timeout=10
Fetching upstream changes from https://github.com/fabric8io/fabric8-jenkinsfile-library.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git fetch --tags --progress https://github.com/fabric8io/fabric8-jenkinsfile-library.git +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision cce86bc9ff7d9bc0c30996d4a4b1c7f4c26924ca (refs/remotes/origin/master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f cce86bc9ff7d9bc0c30996d4a4b1c7f4c26924ca
 > /usr/bin/git rev-list cce86bc9ff7d9bc0c30996d4a4b1c7f4c26924ca # timeout=10
Loading library github.com/fabric8io/fabric8-pipeline-library@master
 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Setting origin to https://github.com/fabric8io/fabric8-pipeline-library.git
 > /usr/bin/git config remote.origin.url https://github.com/fabric8io/fabric8-pipeline-library.git # timeout=10
Fetching origin...
Fetching upstream changes from origin
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse master^{commit} # timeout=10
 > /usr/bin/git rev-parse origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url https://github.com/fabric8io/fabric8-pipeline-library.git # timeout=10
Fetching upstream changes from https://github.com/fabric8io/fabric8-pipeline-library.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git fetch --tags --progress https://github.com/fabric8io/fabric8-pipeline-library.git +refs/heads/*:refs/remotes/origin/*
Checking out Revision fa5faac2a37f695fc43bbdb76e55ab406bc3f121 (master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f fa5faac2a37f695fc43bbdb76e55ab406bc3f121
 > /usr/bin/git rev-list fa5faac2a37f695fc43bbdb76e55ab406bc3f121 # timeout=10
[Pipeline] podTemplate
[Pipeline] {
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor

ikke44 commented May 1, 2017

I still experience this very issue although I am on the latest version of Fabric8 (as per https://raw.githubusercontent.com/fabric8io/gofabric8/master/version/VERSION) with a recent Minikube:

$ gofabric8 version
gofabric8, version 0.4.121 (branch: 'master', revision: '835aa16')
  build date:       '20170306-10:48:35'
  go version:       '1.7.1'
$ minikube version
minikube version: v0.17.1

You can very easily reproduce this error by creating a 'Pipeline script from SCM' Jenkins job that tries to build the 'Release' Maven sample:
1/ Repository URL = https://github.com/fabric8io/fabric8-jenkinsfile-library.git
2/ Script path = \maven\Release\Jenkinsfile

It results in this 'Console Output' in Jenkins that continues 'forever':

Started by user anonymous
 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url https://github.com/fabric8io/fabric8-jenkinsfile-library.git # timeout=10
Fetching upstream changes from https://github.com/fabric8io/fabric8-jenkinsfile-library.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git fetch --tags --progress https://github.com/fabric8io/fabric8-jenkinsfile-library.git +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision cce86bc9ff7d9bc0c30996d4a4b1c7f4c26924ca (refs/remotes/origin/master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f cce86bc9ff7d9bc0c30996d4a4b1c7f4c26924ca
 > /usr/bin/git rev-list cce86bc9ff7d9bc0c30996d4a4b1c7f4c26924ca # timeout=10
Loading library github.com/fabric8io/fabric8-pipeline-library@master
 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Setting origin to https://github.com/fabric8io/fabric8-pipeline-library.git
 > /usr/bin/git config remote.origin.url https://github.com/fabric8io/fabric8-pipeline-library.git # timeout=10
Fetching origin...
Fetching upstream changes from origin
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse master^{commit} # timeout=10
 > /usr/bin/git rev-parse origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url https://github.com/fabric8io/fabric8-pipeline-library.git # timeout=10
Fetching upstream changes from https://github.com/fabric8io/fabric8-pipeline-library.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git fetch --tags --progress https://github.com/fabric8io/fabric8-pipeline-library.git +refs/heads/*:refs/remotes/origin/*
Checking out Revision fa5faac2a37f695fc43bbdb76e55ab406bc3f121 (master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f fa5faac2a37f695fc43bbdb76e55ab406bc3f121
 > /usr/bin/git rev-list fa5faac2a37f695fc43bbdb76e55ab406bc3f121 # timeout=10
[Pipeline] podTemplate
[Pipeline] {
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor
@jwausle

This comment has been minimized.

Show comment
Hide comment
@jwausle

jwausle May 7, 2017

I still experience the issue too.

  • with same versions like @ikke44 above

The jenkins.log show equal exception like @donshoarma had

Failed to count the # of live instances on Kubernetes
io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred.
	at io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(KubernetesClientException.java:57)
	at io.fabric8.kubernetes.client.dsl.base.BaseOperation.list(BaseOperation.java:508)
	at io.fabric8.kubernetes.client.dsl.base.BaseOperation.list(BaseOperation.java:62)
	at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.addProvisionedSlave(KubernetesCloud.java:651)
	at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.provision(KubernetesCloud.java:513)
	at hudson.slaves.NodeProvisioner$StandardStrategyImpl.apply(NodeProvisioner.java:701)
	at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:307)
	at hudson.slaves.NodeProvisioner.access$000(NodeProvisioner.java:60)
	at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:798)
	at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Maybe root cause
The server-certificate of minikube-host 'kubernetes.default' is not part of the jenkins-java-keystore '/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts'.

Server certificate
subject=/O=system:masters/CN=minikube
issuer=/CN=minikubeCA

jwausle commented May 7, 2017

I still experience the issue too.

  • with same versions like @ikke44 above

The jenkins.log show equal exception like @donshoarma had

Failed to count the # of live instances on Kubernetes
io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred.
	at io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(KubernetesClientException.java:57)
	at io.fabric8.kubernetes.client.dsl.base.BaseOperation.list(BaseOperation.java:508)
	at io.fabric8.kubernetes.client.dsl.base.BaseOperation.list(BaseOperation.java:62)
	at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.addProvisionedSlave(KubernetesCloud.java:651)
	at org.csanchez.jenkins.plugins.kubernetes.KubernetesCloud.provision(KubernetesCloud.java:513)
	at hudson.slaves.NodeProvisioner$StandardStrategyImpl.apply(NodeProvisioner.java:701)
	at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:307)
	at hudson.slaves.NodeProvisioner.access$000(NodeProvisioner.java:60)
	at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:798)
	at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Maybe root cause
The server-certificate of minikube-host 'kubernetes.default' is not part of the jenkins-java-keystore '/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts'.

Server certificate
subject=/O=system:masters/CN=minikube
issuer=/CN=minikubeCA
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment