Add commands to freeze and thaw a droplet

[behrica]

The use case is described here: http://blog.burkeware.com/2014/04/freezing-and-thawing-droplets-in-a-digitalocean/

It allows to use digitalocean droplets like having a physical hardrive, which you can switch off (= freeze) and switch-on (=thawn or unfreeze) with a SINGLE command and it keeps the "state of the harddrive" in a snapshot.

I have done something like this in Clojure and use it daily. It helps to keep the costs of a digitalcean droplet very low, as switch-on and switch-of is so easy.

All low-level calls to do so are implemented already here.

The clojure code for reference is here: https://gist.github.com/behrica/b09d159734a48bff3c7d

[sckott]

Sure, I don't see why we can't wrap together a series of functions to make this use case more convenient. any objections @hadley

[hadley]

@sckott Sounds good to me. They should be pretty simple - I have a start on droplet_freeze() in one of the examples:

d %>% 
  droplet_power_off() %>%
  droplet_snapshot() %>%
  droplet_delete() %>% 
  action_wait()

[sckott]

@behrica i added 1st draft of the freeze and thaw functions, see what you think

[behrica]

@sckott I tried it and it works well. The methods I was doing in Clojure (and the guy did in Ruby, I believe) , worked a bit different: With the current methods I need to type each time(everyday..) something like:

droplet_freeze(2809155)
droplet_thaw("core-1412760225")
droplet_freeze(2810313)
droplet_thaw("promodernistic-1412760521")
droplet_freeze(2810355)

With this approach I needed to look up constantly the "right" droplet Id and the right image name.

Ideally I would like to type:

freeze("test")
thaw("test")
freeze("test")
thaw("test")
...

Like this I think about "test" to be a kind of "persistent droplet". It´s like my PC. I switch it on and of, always the same PC. I could even make two icons on my desktop, which by clicking execute the above R code. (as the parameters are fixed. Always "test")

This makes a higher abstraction then the droplet, the digital ocean api deals with. So we would have methods like: pdroplet_freeze(name) pdroplet_unfreeze(name)

"p" for persistent.

For doing this with digital ocean API I made the naming convention, to automatically name the snapshot like the image.

The code gets more complex doing this as it needs to handle (eventually) things like:

• deleting snapshots (as the DO API let you create the same snapshot name several times) Alternative: create a new snapshot (with timestamp) each time "freeze" is called and "thaw" detects the "latest" and uses it by default.
• assuring, that at any given time only the droplet with name "test" OR the snapshot with name "test" exists
• error handling is more complex

[behrica]

I thought about it again. The deletion of snapshots is a bit tricky...It works , but might come to a situation where everything gets deleted.

So maybe the following change to the methods could be a compromise: For "freeze":

• it should take the "name" of the droplet, so I do not need to lookup the ID.
• maybe it should fail, if there are two droplets with same name ... (which is possible)
• it creates eachtime a snapshot called: "name-timestamp"

For "thaw":

• it takes as well the name
• it looks up the latest snapshot of this name
• creates a new droplet for this snapshot
• (it deletes all snapshots named "name-xxxx" ???)

this would allow to call the sequence of:

freeze("test")
thaw("test")
freeze("test")
thaw("test")

It would "left over" all the old snapshots over time, which in reality are not needed (assuming that we take the home PC as a metaphor. It has only one disk.)

In any case I would not call the methods "droplet_xxx" any more then. They deal with a different concept.

[hadley]

I think droplet_freeze() and droplet_thaw() are fine as names, even though droplet_thaw() actually takes an image as input.

@behrica I don't think these functions need special handling for droplet/image names - they should just call as.droplet()/as.image() to be consistent with every other function.

[behrica]

The functions as such are fine, but I cannot use them to implement the original use case, which is to be able to call:

thaw("test")   # in tehe morning
freeze("test")  # in the evening

# next day

thaw("test")  # in the morning
freeze("test") # in the evening

# next day

If I would have those, I could even do a scheduled job on my PC, which automatically starts my droplet before each working day, and closes it at teh end of teh working day.

This is not possible right now, as I need to know (so need to lookup manually) the exact name of the "latest snapshot".

ok, I could do a function myself, which does this lookup. Maybe better. So we keep the "simple" freeze and thaw behaviour here, and I do my "special cases" on top.

[hadley]

@behrica huh? as.image() and as.droplet() both look up by name, so your original use case would be support.

[sckott]

@behrica okay, changed the fxns, try again.

freeze accepts a droplet as first argument, and returns an image. thaw accepts an image as first argument, and returns a droplet.

[behrica]

Ok, it's better.

I can now call sequences like:

droplet_freeze("test1")
droplet_thaw("test1",name="test1")
...
droplet_freeze("test1")
droplet_thaw("test1",name="test1")
....

which is fine, but the second "thaw" will do the wrong thing. At the moment of the second thaw I will have two snapshots with the same name ("test1"), each created by a call two "freeze". And the "thaw" should now restore from the "latest" snapshot ("latest" by the "created_at" property of the image), but it will take the "first" from the list of images() (which is typically not the "latest")

I am not sure, if we want to have the logic of finding the "latest snapshot" here or outside of this package, so in users own code.

But somebody using "freeze" and "thaw" and not be very careful in manually naming/deleting the snapshots has a high chance to get a wrong result from a call to thaw (restoring from the wrong snapshot, if there are several of the same name)

[hadley]

I remained unconvinced that using the same name for different droplets is likely to be a problem in practice - I think if you want to create confusingly named droplets, then it's your responsibility to handle the problem.