Docs: documentation has invalid config map

Created on 9 Jun 2020  路  11Comments  路  Source: knative/docs

@nicks reports:

/area API
/kind doc

Expected 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.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

Actual Behavior

I would expect examples on the knative documentation site to work out of the box

kinapi kinbug kinsample priorit0 triagneeds-eng-input

All 11 comments

@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 doc

Expected 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.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

Actual 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.

Was this page helpful?
0 / 5 - 0 ratings