jaeger-operator: Too long CRD definition

Error from server (Invalid): error when creating “STDIN”: CustomResourceDefinition.apiextensions.k8s.io “jaegers.jaegertracing.io” is invalid: metadata.annotations: Too long: must have at most 262144 characters

From master, right now. Onto docker-desktop macOS

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.6", GitCommit:"96fac5cd13a5dc064f7d9f4f23030a6aeface6cc", GitTreeState:"clean", BuildDate:"2019-08-19T11:13:49Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.5", GitCommit:"20c265fef0741dd71a66480e35bd69f18351daea", GitTreeState:"clean", BuildDate:"2019-10-15T19:07:57Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}

repro

curl --silent -L https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/crds/jaegertracing.io_jaegers_crd.yaml \
                > k8s/base/jaegertracing.io_jaegers_crd.yaml
kubectl apply -f k8s/base/jaegertracing.io_jaegers_crd.yaml

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 4
Comments: 25 (13 by maintainers)

Most upvoted comments

See #854. In short, use kubectl create -f ..., or remove the validation node if you absolutely have to use kubectl apply.

jpkrohling on Jan 27, 2020

The issue has been reported a few times in different channels, but everyone else seems to be happy with kubectl create being an alternative to kubectl apply.

kubectl create and kubectl apply are not the same. I only use kubectl apply and now my workflow is broken because of the CRD.

nouney on Jan 29, 2020

Another related issue: https://github.com/kubernetes/kubernetes/issues/82292

Given the amount of people that seems affected by this one, I’ll try to apply the suggested workaround, by disabling the description fields.

jpkrohling on Feb 28, 2020

This is not a good enough solution, if kustomize uses apply and if I’m expected to continuously re-run apply from a scheduled job (as I am). Can you at least ship a CRD definition without the validation node, so that the kubectl tooling works as expected?

haf on Jan 27, 2020

@jpkrohling thanks for this! i’ve tested the updated CRD and it works fine with kustomize + apply.

adamhosier on Feb 28, 2020

We’ve worked around this by removing all “description” fields from the provided CRDs, based on a suggestion by the upstream Kubebuilder issue: kubernetes-sigs/kubebuilder#1140

Would you consider publishing the CRDs without the description fields to allow them to be compatible with kubectl apply out of the box?

adamhosier on Feb 23, 2020

The issue has been reported a few times in different channels, but everyone else seems to be happy with kubectl create being an alternative to kubectl apply.

In any case, could you provide the kustomize commands you are using?

jpkrohling on Jan 28, 2020

Repeatability
Documentation requirements
Reproducibility; jq is not a default tool on Windows which is part of the use-case for developer environments for us, and even less yq or python which are commonly used to transform yaml to json and then filter. Your expectations of our environment don’t match the real-world; it has to run on Linux, Windows and macOS.
Resilience to change; if I customise here, you’ll break me in the future for sure. This is an anti-pattern; I’ve worked in places where most things boiled down to “just add a button for ops to click” — it could be everything from clearing a cache to triggering a fetch of some external resource, and in the end everyone ended up afraid of changing the system — there’s a lot of work on this done under resilience engineering
Expectations for people unfamiliar with this limitation
Expectations; it wouldn’t make sense to include validation in the schema if it’s so utterly useless that you make it sound like
Expectations; as such I don’t know what I’m missing out on; does this mean that the validation hooks don’t validate the jaeger schema as stringently? This is not explained in the issue that you link to, so I have no foundation to make a decision to cut out what seems to me to be a critical bit of config.
Expectations; if you want me to customise the crd declaration; why doesn’t everyone? it’s not only in Jaeger that I’ve seen PVC/volume support — why doesn’t e.g. ECK/Elastic’s operator have the same limitation?

Anecdotally: I’m storing modified versions of tooling output e.g. for the Istio mesh that we got configured because they have a bug; https://github.com/istio/istio/issues/20082 which seems to be extra problematic when its output is applied to already applied k8s state; triggering a much worse bug — grey failure — https://github.com/istio/istio/issues/20454 . Every bug report in that repo is preceeded by a 1-3 week triage phase where they ensure it’s not “operator error”; which it is sometimes, but like in the above bugs, it also makes the DX suck.

But why am I stupid enough to apply the output of the tooling (istioctl) straight to the cluster? Because the documentation says that’s how it’s done and it doesn’t explain the link; that the Helm chart is inlined in the tool and can actually be used to generate k8s manifests; as such they’ve made what was previously explicit, implicit, and this makes people make mistakes. Your suggestion is exactly this; let’s work around a bug in an upstream project with a hack, and it will bite someone in the ass sooner or later 😉

haf on Jan 28, 2020