DO Ideas 2

If a droplet is already powered off at snapshot creation, it should not be restarted automatically

Currently, the source droplet of a snapshot is restarted automatically regardless of its initial state. This is somewhat surprising/unwanted behavior.

  • Cedric
  • Sep 11 2018
  • Shipped
  • Sep 11, 2018

    Admin Response

    Hey All, We fixed this behavior about a month ago and Droplets no longer power on after taking a snapshot.
  • Attach files
  • Neil Hooey commented
    September 11, 2018 19:02

    Automatically starting a node after "resize" or "snapshot" may be convenient, but can wreck a node's state because of a single-execution bootstrap script on the first boot that permanently changes the node.

    Not restarting after "resize" or "snapshot" may be inconvenient, but it will leave the node in exactly the same state as before it was resized or snapshotted.

    Having an checkbox to specify which action you prefer is the best of both worlds, but have it stored in a cookie or session storage, per-user, as a global default, so I can have it always off.

    An example of when auto-starting after resize causes problems:
    Our nodes permanently change their `/etc/network/interfaces` file on the first boot, because the first boot should be when a node starts for the first time from a snapshot. If a resize starts up a node automatically, trying to dynamically resize a node to the smallest size so any VMs derived from its snapshots can be of any size, those nodes will have their IP addresses set to that of the snapshot parent, which will break networking.

  • qmarlats commented
    September 11, 2018 19:02

    +1 for a checkbox to choose if we want to restart droplet or not

  • Stanley commented
    September 11, 2018 19:02

    An even better solution would be to have a checkbox during the snapshot creation process, for choosing whether or not the droplet should be powered back on when the snapshot is completed.

  • Per-Olov Sj√∂holm commented
    September 11, 2018 19:02

    I just tested to do a test snapshot of a droplet. I did a shutdown in the OS and could then see in the graphic user interface that the snapshop option a few minutes now were available. Then I did a snapshot that seemed to have worked as expected.

    However... Why do you autostart my droplet after the snapshot? I really think that you should not autostart this for the customer, at least not without very clear info about it. But... I can however understand that many customers wants the opposite and Do want it auto started.

    Feature suggestion:
    Add an "autostart droplet after snapshot" = "yes/No" config option in your customer management GUI so the customer can see and choose.

  • Doug commented
    September 11, 2018 19:02

    it is also a time waster. I want to take my snapshot, destory my droplet, and go get a beer or something. instead i have to relog in then shutdown then destroy, adds about 2 min to my life... would be nicer not to have to wait for the restart and shutdown.

  • Remik Pi commented
    September 11, 2018 19:02

    Alternatively there could be an option of droplet autostart after a snapshot in user profile for even better customization.

  • Chris commented
    September 11, 2018 19:02

    +1

  • Jeff Reifman commented
    September 11, 2018 19:02

    Trying to create multiple snapshots is extra time-consuming because of this behavior.

  • Corey commented
    September 11, 2018 19:02

    This was annoying... I have an interesting setup that I shutdown in a specific order and took snapshots, only to find that they were automatically started after the snapshot.

  • Moisey Uretsky commented
    September 11, 2018 19:02

    Hi Cedric,

    Great point, however we now require the server to be powered off to snapshot it, it may be a good idea to separate out the boot process but we will wait to see if this gets up-voted further before switching the flow which has been around for a while and may cause more confusion to more customers.