gerlowskija commented on issue #650: URL: https://github.com/apache/solr-operator/issues/650#issuecomment-2532280060
> its hard for our automation running in kubernetes cluster to identify whether the patch done in the SolrCloud has been successfully deployed in the actual instance or not I guess this is the bit I'm particularly curious about. The main thing I can think of that wouldn't appear in the status would be pod or statefulset-level settings like env-vars, resources, etc - is that representative of the sort of things you don't have a good way to poll for? Or is there another common example? My worry I guess is that the observedGeneration/lastTransitionTime approach doesn't give enough granularity to be useful in practice. It wouldn't give any way to distinguish between multiple resource changes made in quick succession. Or between a truly substantive "status" update and a (e.g.) pod-readiness blip (which also impacts SolrCloudStatus afaict). Even for a substantive update, many spec changes require multiple steps and update "status" multiple times throughout - so in practice there can be a big gap between "the status changed" and "the user-requested change is complete". It feels like observedGeneration might send a wrong (or at least incomplete?) signal to your provisioner/UI much of the time. Have you thought much about those scenarios? Is there maybe something I'm missing? I'm not against the approach btw - I just want to make sure it'll work before we build. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
