Add truncation to status reporting
Opened this issue · 1 comments
similar to solo-io/solo-kit#523
we should protect etcd from gloo mesh as a potentially buggy or erroneous client. if resources get too large, we can take down their k8s cluster itself and put GM into a state where it cannot start.
the proposed solution:
- try to truncate status before writing
- if that fails and still too large, don't write the status
cc @Sodman @ilackarms @EItanya (I'm told this may not be an issue for GM, but not sure why we are so confident)
@nrjpoddar as part of stability effort
The design for Gloo Mesh statuses was that the entire status would be written to and held in redis, but the status written back to the actual CRs in k8s would be truncated/trimmed to a reasonable size, eg max 10 entities. For large statuses, users can get more information via the UI, and we also plan to add tooling to meshctl to help with this.
Looking at the code however, I'm not sure this has been implemented yet, at least I'm not seeing the truncation logic where I'd expect it.