ConfigMap "catalog-letschat" is invalid: metadata.annotations: Too long: must have at most 262144 characters about funktion

[dabdine-r7]

This issue was filed in January. It's now April 9th. So about 3 months later and there has been no fix. I was evaluating funktion for some use cases. However, I hit this, and then I had to search to find this bug, then dig around more to find that there is no workaround, nor should I care for one. So, I ignored that, but hit another issue, so as of now, I'm choosing to move on.

I believe there's a classic case of broken windows theory going on here. If the initial setup phase has issues that have gone unaddressed for months, the probability of folks adopting funktion for production use cases tends to trend down.

FWIW i'm an on-and-off camel contributor and Java programmer of of 10-12 years. I love what funktion is trying to do, but I have reasonable reservations due to issues I hit on first use.

[bbrowning]

I've investigated this error a bit and it's happening because Kubernetes tries to save the entire catalog-letschat ConfigMap as an Annotation (in case of 3-way merges of the ConfigMap definition in the future) and this ConfigMap is HUGE. So, catalog-letschat either needs to be excluded from the platform or its overall size reduced substantially.

[xetys]

+1 for the option to disable unnecessary config maps. there comes a lot from and for fabric8...while I one doesn't need fabric8 related stuff (as this letschat config map), when running pure funktion

[tobias]

Related to #35.

[rhuss]

@tobias I think its related but still different as it is a limit of the size of the annotation not the configmap's value itself. But I agree, it all about what should be saved in ConfigMaps and where are the limitation of ConfigMaps w.r.t to size.

[jimmidyson]

@rhuss You're right, size restriction is on annotations, not configmap size (although there is a planned feature to put quotas on configmao size apparently). However, to be good citizens, we should try to keep configmap sizes down to reasonable sizes as far as we can.

[rhuss]

@jimmidyson completely agreed, and my gut feeling is that this applies to every (obscure) use case which could be mapped to Kubernetes objects but which was never designated by their inventors. This mostly always hit untested corner cases, limitations and non-functional issues like degraded performance.

[jstrachan]

apologies for the delay. I've finally got around to making a lean & mean distro of funktion that works on kubernetes/minikube, the latest minishift, openshift & openshift online without any of these issues

[jstrachan]

it was actually the fabric8 release that held back this fix - but I should have moved the function related distro to a separate git repo early BTW - my bad - its now independent so funktion no longer needs to be blocked on a fabric8 release: https://github.com/funktionio/funktion-platform