Is your feature request related to a problem? Please describe.
When a new plugin version is released, adoption is roughly logarithmic:
This ends up with a very long (potentially infinite) tail of users who remain in older versions, leading to potential failures when updates are attempted (see #203).
From a print farm owner's POV, updates must be manually run on every printer in their cluster. This seems like busywork.
Describe the solution you'd like
Add an auto-update process, with enough configurability to allow for safe and measured rollouts in their fleet. Some potential config options:
Enable auto-update (checkbox)
Restart after update when idle (checkbox)
If not checked, updates are applied but only take effect on the next restart of OctoPrint
Delay update after release (duration)
Allows for basic fractional rollouts, e.g. update one host immediately but delay all others by 3 days
I'd probably apply a random offset here so that whole clusters don't flap
Gate update on request (string/url)
Put a URL here (potentially customized per printer) that must return a 200 OK response before updates are attempted
This could point to a health-check page on one of the earliest updated printers to ensure it came back online after updating, or a central server that manages the rollout
Gate update on queue (string/queue name)
For LAN queue users, block updating if the queue appears unhealthy (e.g. 10 printers initially drop to 7 after updates begin).
Describe alternatives you've considered
Direct users towards an enterprise fleet management service. This seems heavy for most users and would drastically lower adoption.
Release auto-updates as a separate plugin. This would end up with extensive integration with peerprint, and
Additional context
FR created after initial conversation with folks from Protosthetics on safe rollouts to a printer fleet.
Is your feature request related to a problem? Please describe.
When a new plugin version is released, adoption is roughly logarithmic:
This ends up with a very long (potentially infinite) tail of users who remain in older versions, leading to potential failures when updates are attempted (see #203).
From a print farm owner's POV, updates must be manually run on every printer in their cluster. This seems like busywork.
Describe the solution you'd like
Add an auto-update process, with enough configurability to allow for safe and measured rollouts in their fleet. Some potential config options:
Describe alternatives you've considered
Additional context
FR created after initial conversation with folks from Protosthetics on safe rollouts to a printer fleet.