On Kubernetes 1.7, I am trying to create an ExternalAdmissionHookConfiguration. I have tried to set the failurePolicy: Fail, however, I get the following error:
The ExternalAdmissionHookConfiguration "policy-agent" is invalid: externalAdmissionHooks[0].failurePolicy: Unsupported value: "Fail": supported values: Ignore
The documentation suggests that Fail is a valid option.
https://kubernetes.io/docs/admin/extensible-admission-controllers/
It is valid as of 1.9
I'd recommend building on 1.9 admission webhooks. The pre-1.9 versions were discontinued at alpha level and redone as validating and mutating versions in 1.9
Related
I have incorporated the solutionConfig as part of HPO in AWS personlaize service.
solutionConfig = {
"optimizationObjective": {
"itemAttribute": "ITEM_WEIGHT",
"objectiveSensitivity": "HIGH"
},
I am getting the following error
Unknown parameter in solutionConfig: "optimizationObjective", must be one of: eventValueThreshold, hpoConfig, algorithmHyperParameters, featureTransformationParameters, autoMLConfig]
It looks like you may be using a version of the AWS SDK that does not include support for the optimizationObjective parameter of the solution config. Check to make sure that you're using the latest version of the AWS SDK.
I'm confused when to use reuse-values option while upgrading a helm chart
As I know that reuse-values: reuse the last release's values and merge in any overrides from the command line via --set and -f, but when I use it when upgrading chart, for example, "stable/elasticsearch-curator" the upgrade fails due to UPGRADE FAILED Error: CronJob.batch "es-curator-elasticsearch-curator" is invalid: spec.jobTemplate.spec.template.spec.restartPolicy: Unsupported value: "Always": supported values: "OnFailure", "Never" Error: UPGRADE FAILED: CronJob.batch "es-curator-elasticsearch-curator" is invalid: spec.jobTemplate.spec.template.spec.restartPolicy: Unsupported value: "Always": supported values: "OnFailure", "Never"
So, when do I use it and when should I don't? and what is the effect of not using it while upgrading?
In Chart.yaml
I have kubeVersion: ">=1.10.1"
Cluster nodes have below version
v1.18.0-rc.1
and helm installation fails with error
Error: chart requires kubeVersion: >=1.10.1 which is incompatible with Kubernetes v1.18.0-rc.1
I tried changing kubeVersion to 1.10.1-rc.1 but some new error
error unmarshaling JSON: while decoding JSON: json: cannot unmarshal bool into Go value of type releaseutil.SimpleHead
# helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}
To allow prereleases (such as rc), at least in Helm, the constraints suffix needs to be -0. For example, >=1.20.0-0 will allow versions greater or equal to 1.20.0, including any prereleases.
I do not manage to make cinder plugin work with kubernetes 1.7.
It worked well with 1.6. With the same configuration, I got the following error with 1.7:
E1011 16:13:44.309318 5 openstack_volumes.go:320] Failed to create a 3 GB volume: Invalid request due to incorrect syntax or missing required parameters.
I1011 16:13:44.309411 5 cinder_util.go:207] Error creating cinder volume: Invalid request due to incorrect syntax or missing required parameters.
I1011 16:13:44.309458 5 pv_controller.go:1331] failed to provision volume for claim "default/my-persistent-volume-claim" with StorageClass "standard": Invalid request due to incorrect syntax or missing required parameters.
Thanks for your help
We are using some community custom resource types (https://github.com/ljfranklin/terraform-resource and https://github.com/cloudfoundry/bosh-deployment-resource). After upgrading to concourse 3.3.0, we've begun consistently seeing the following error on a few of our jobs at the same step: json: unsupported type: map[interface {}]interface {}.
This is fairly hard to debug as there is no other log output other than that. We are unsure what is incompatible between those resources and Concourse.
Notes about our pipeline:
We originally had substituted all of our usages of {{}} to (()), but reverting that did not lead to the error going away.
We upgraded concourse from v3.0.1.
The failing step can be found here: https://github.com/cloudfoundry/capi-ci/blob/6a73764d09f544820ce39f16dca166d6d6861996/ci/pipeline.yml#L731-L739
We are using a resource called elsa-aws-storage-terraform, found here: https://github.com/cloudfoundry/capi-ci/blob/6a73764d09f544820ce39f16dca166d6d6861996/ci/pipeline.yml#L731-L739
That resource is of a custom resource-type terraform found here: https://github.com/cloudfoundry/capi-ci/blob/6a73764d09f544820ce39f16dca166d6d6861996/ci/pipeline.yml#L45-L48
A similar failing step can be found here: https://github.com/cloudfoundry/capi-ci/blob/6a73764d09f544820ce39f16dca166d6d6861996/ci/pipeline.yml#L871-L886
This is related to issue of not being able to define nested maps in resource configuration https://github.com/concourse/concourse/issues/1345