@nicks reports:
/area API
/kind doc
This doc
https://knative.dev/docs/serving/tag-resolution/
has this ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: config-deployment
namespace: knative-serving
data:
# List of repositories for which tag to digest resolving should be skipped
registriesSkippingTagResolving: registry.example.com
When I apply this config map to my cluster, I get this error:
admission webhook "config.webhook.serving.knative.dev" denied the request: validation failed: queueSidecarImage cannot be empty or unset
: exit status 1
I would expect examples on the knative documentation site to work out of the box
@vagababov: The label(s) area/api, kind/doc cannot be applied, because the repository doesn't have them
In response to this:
@nicks reports:
/area API
/kind docExpected Behavior
This doc
https://knative.dev/docs/serving/tag-resolution/has this ConfigMap
apiVersion: v1 kind: ConfigMap metadata: name: config-deployment namespace: knative-serving data: # List of repositories for which tag to digest resolving should be skipped registriesSkippingTagResolving: registry.example.comWhen I apply this config map to my cluster, I get this error:
admission webhook "config.webhook.serving.knative.dev" denied the request: validation failed: queueSidecarImage cannot be empty or unset : exit status 1Actual Behavior
I would expect examples on the knative documentation site to work out of the box
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
/cc @nicks
@vagababov can you provide information about what this should be updated to to make it correct?
There must be queueSidecarImage value.
In the release we actually point to a real one (e./g. for 0.16 queueSidecarImage: gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:ab38418f2e13dfc21d48c64af0589f4eae5c40fc34a5e02f48b24b7156391d22). But probably we just need to specify that the value must be set.
Either by downloading and modifying existing CM (kubectl get cm -n knative-serving config-deployment) rather than just applying a new one./
/assign
I think it's just misleading, it's specifying which field you should edit/change, this isn't a full configmap that should be applied.
@mpetason are the other examples on this page fully working configmaps?
If they are, maybe let's make this a full one that can be applied as well to keep consistency.
If not, maybe we should update examples where we can to make sure they are, or else start adding notes/warnings to samples that only contain excerpts that can't be used directly?
The others are Deployments. I can get this to work if I edit the example section and remove it + add the value under data. I think the issue is that the queueSideCarImage is going to be different, so you can't exactly specify what the end user will have?
I think @vagababov was actually talking about that with "But probably we just need to specify that the value must be set." I thought he was referencing queueSideCarImage, but maybe he just meant we need to specify that the value (registriesSkippingTagResolving) needs to be set.
After @vagababov updates I can make the changes needed. I think we just need to specify that "this isn't a full configmap" and that we are recommending that they edit a section of the configmap if it is already in place. I'll make the updates after we figure out what we want.
Yeah some kind of snippet ?
Sounds good, I can do this as a snippet instead of it looking like a complete config + maybe make a comment about it so that users know what's up.