You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support timeframes or datetime frames scheduled cluster updates.
(opposed to automatically triggered cluster updates)
Changes would pile-up and automatically executed all at once in the specified hours, could be cron syntax or something else.
This might be useful for ensuring scheduling cluster updates are run out of high peak usage, specific dates (e.g. Black Friday), outside of office hours, etc...
The text was updated successfully, but these errors were encountered:
@elgalu what if the cluster update takes >24h?
You defined that we can specify a start time using cron syntax, but there is no "end". Cluster updates can be stuck and as Ops we can pause them and we are able to let it continue. The question is what do you expect as user to happen?
For example you can have a cluster which has a split version with new and old versions that might interfere.
Maybe it'S not likely enough to implement it but it would be nice to get user feedback for this.
Good point. This should only apply to cluster start datetime. What happens after a cluster update that's another story, if it takes 24hs then it takes 24hs but this is probably an edge case.
Feature request
Support timeframes or datetime frames scheduled cluster updates.
(opposed to automatically triggered cluster updates)
Changes would pile-up and automatically executed all at once in the specified hours, could be cron syntax or something else.
This might be useful for ensuring scheduling cluster updates are run out of high peak usage, specific dates (e.g. Black Friday), outside of office hours, etc...
The text was updated successfully, but these errors were encountered: