HoustonPutman commented on issue #376: URL: https://github.com/apache/solr-operator/issues/376#issuecomment-981945892
Good catch, this was an intentional decision made by myself when implementing. I definitely should have mentioned it in the Issue or PR though, so thanks for bringing this up. I decided to not recompute this every time, because it seems like a somewhat expensive call (have not tested this, so my fears might be completely unfounded), and if we do support recomputing then we will have to recompute the schedule on every single reconcile loop. So my thought was "at first, just recompute once every time, and don't waste the time". If the backup had sub-resources we could do fun things like store the last used `schedule` as an annotation on the sub-resource, and only recompute the next restart time whenever the `schedule` differs between the SolrBackup spec and the sub-resource annotation. But since the solrbackup resource doesn't manage sub-resources, we would have to store the last used schedule in the annotations of the SolrBackup (which I am not a fan of), or add a field in the SolrBackup.Status, which is an option. Maybe I'm just worrying about nothing and we should always recompute at the start of the reconcile loop. As for your question about how it should be computed, the clear answer in my mind is to ALWAYS compute based off of the last time a backup was started. Given the Kubernetes APIs, we aren't necessarily given the time when a field has been changed, so that is a rabbit hole of using "current time" (except for the first backup of course). -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
