[GitHub] [solr-operator] HoustonPutman commented on pull request #359: Add ability to schedule recurring incremental backups

[GitBox <gi...@apache.org>]

HoustonPutman commented on pull request #359:
URL: https://github.com/apache/solr-operator/pull/359#issuecomment-954922376


   I never really considered a separate CRD. Generally CRDs are a necessary evil, and therefore the less the better IMO. The reason why this fits really well into a single CRD, in my opinion, is that the options would be identical between the two, except the recurring backup has an additional setting for `recurrence`. Because of this, it makes a ton of since to have them share the CRD. Otherwise every option we add to the SolrBackup CRD, we would also have to add to the RecurringSolrBackup CRD.
   
   Think of a kubernetes Headless Service / regular Service (with clusterIP). They are pretty different in usage, much further apart than SolrBackup and RecurringSolrBackup would be. However they share a single resource type, because they share almost every option, and are used for the same reasons. Users can distinguish them easily enough by looking at the options. (described more below)
   
   A CRD & controller pair is complex, the less complexity we add to the project, the better.
   
   > A user might be surprised that some solrbackup resources represent one-offs that will never impact the cluster again, and others represent ongoing periodic work that'll continue indefinitely.
   
   We can fix this quite easily. When you run `kubectl get solrbackups`, the data it returns is not random, it is selected by us [here](https://github.com/apache/solr-operator/blob/v0.4.0/api/v1beta1/solrbackup_types.go#L289). We can add a column(s) here to make it much more clear to the user what the solrbackup resource is doing. Maybe we add "Schedule" and/or "Next Backup Time". That way when you run `kubectl get solrbackups`, it is very easy to tell which ones are one-off, and which ones are recurring.
   
   I also really like the idea of someone taking a backup and then realizing they need it to be done on a schedule. They wouldn't need to delete the SolrBackup resource or create something else. All they would have to do is edit their SolrBackup resource, adding the `recurrence` section. At that point, the controller would work fine and treat it as a recurring backup that has been taken once already.


-- 
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-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org