[RavinaChidambaram]

Implemented #650

Have added observed generation to the status of the solrcloud CR to track the transition of the solrcloud.

[gerlowskija]

I left one in-line question, but otherwise this LGTM. It seems to bring out status a little closer into line with best practices.

I'm ambivalent on the "lastUpdated" timestamp field that was described in the issue description. It seems like there's less strong of a precedent around that field, and it's maybe more subject to some of the "false-signal" concerns I expressed in #650. But I'm not against it - if others think it's worthwhile and are willing to add it, I'll hold off merging for a bit. But otherwise I'll add a Chart.yaml change-entry and merge this sometime in the next few days!

Thanks @RavinaChidambaram !

[gerlowskija]

[Q] Are there any edge-cases where there won't be an observedGeneration, say, immediately after creating a SolrCloud but before the operator has created any of the resources backing it?

Assuming that case exists, I guess the 'observedGeneration' would just be '0' in that case, and that's probably fine unless it'd be better to make the field an optional *int64?

[RavinaChidambaram]

Thanks for the feedback and approval. I’m currently working on considering other scenarios as well around observedGeneration, and I’ll address that within this PR. Please hold off on merging for a bit while I make these adjustments.

Also lets just address observedGeneration in this PR and then add lastTransitionTime in another PR

[github-actions]

This PR has had no activity for 60 days and is now labeled as stale. Any new activity will remove the stale label. To attract more reviewers, please tag people who might be familiar with the code area and/or notify the dev@solr.apache.org mailing list. To exempt this PR from being marked as stale, make it a draft PR or add the label "exempt-stale". If left unattended, this PR will be closed after another 60 days of inactivity. Thank you for your contribution!