Implementing "freeze" and "thaw" of droplets

[behrica]

As described here: http://blog.burkeware.com/2014/04/freezing-and-thawing-droplets-in-a-digitalocean/

This allows to have a single method which does the "freeze" of a droplet (including snapshotting) and "unfreeze" from a snapshot (including waiting)

I could eventually contribute this.

I would then have some questions to you:

1.) Would you agree to add this functionality to this project ?. In a certain sense it is a "higher level" API, as implementing "thaw" and "freeze" would be calling several low level methods.

2.) If 1. is yes, how would you suggest to make it work with "v1" and "v2" version of the API ? Or should we forget "V1" ?

3.) If 1. is "no" (which could be justified), we needed then to add one or two low-level API calls at least. I did not check in details, but we might need look at the "Actions" API call to find out if a Snapshot is going on already. Eventually "waiting" for a state to arrive might need to be added as well. This is because I thought to implement "freeze" and "thaw" as synchronous methods, so they only come back if the action has finished, which can take minutes. (or is this a very bad idea ? I am a Clojure newbie ...)

[behrica]

Maybe some more context information. At the end I will make a little command line application in Clojure, which can be used to use "freeze" and "thaw" my droplets. So the question is which part of functionality to put in the app itself versus put it in this API.

[owainlewis]

Although this feels like code that isn't really part of the API itself I would have no objection in having it in a separate namespace as a utility function. If you want to drop I PR I'll be happy to merge.

[behrica]

I have some working code which implements the freeze and unfreeze:

(defn destroy-all-images [client-id api-key image-name]
  (let [imgs (filter #(= (:name %) image-name) (all-images client-id api-key))]
    (println (doseq [img imgs] (destroy-image client-id api-key (:id img))))))

(defn freeze
  [client-id api-key droplet-id image-name]
  (destroy-all-images client-id api-key image-name)
  (wait-for-event-finish client-id api-key (:event_id (shutdown-droplet client-id api-key droplet-id)))
  (wait-for-event-finish client-id api-key (:event_id (snapshot-droplet client-id api-key droplet-id image-name)))
  (wait-for-event-finish client-id api-key (:event_id (destroy-droplet client-id api-key droplet-id))))

(defn unfreeze
  [client-id api-key droplet-name image-id]
  (wait-for-event-finish client-id api-key (:event_id (:droplet (new-droplet client-id api-key {:name droplet-name :size_id "66" :image_id image-id :region_id "5" :ssh_key_ids "42550"})))))

I am more thinking to NOT have it as part of this library. The reason is that the code makes assumptions what the user wants, which are not true for everybody.

It assumes that it should delete always old snapshots with the same name, it starts and stop droplets automatically and so on.

This is because it wants to maintain a one-to-one relationship between a droplet and "its single snapshot". So the snapshot becomes "the persistent hard drive" of the droplet.

I will think about this a bit longer. Let me know, what you think, if you have any comment.

[behrica]

I though about it again.

The code does not fit in here. The reason is, that the freezing and thawing of droplets manages a new "entity" which is no a droplet in the sense of digital ocean.

This is because by freezing and unfreezing a the droplet the droplet id will change over time, so in reality we do not manipulate a droplet any more but "something" else.

I still need to find a name for this entity, but sumething such as "e-droplet", so "eternal droplet" or similar.

I started a repo for this here: https://github.com/behrica/e-droplet.