Commit graph

26 commits

Author SHA1 Message Date
Rene Moser
0e5d5ad65b digital_ocean: added requirements in DOCUMENTATION 2014-01-21 14:09:21 +01:00
Michael DeHaan
50c600c361 Pass scrub_data by default, see response from DO here: https://www.digitalocean.com/blog 2013-12-30 20:21:15 -05:00
Michael DeHaan
3fd2e55619 User report of DO not taking underscores so tweaking docs 2013-12-25 13:51:56 -05:00
James Tanner
4f9aadcc07 Addresses #5023 Fix import comments 2013-12-02 15:13:49 -05:00
James Tanner
38edad70ac Fixes #5023 Convert all modules to use new snippet import pattern 2013-12-02 15:11:23 -05:00
Michael DeHaan
05251f2745 Merge pull request #4346 from dmkoch/digitalocean-droplet-options
Add "virtio" and "private_networking" options for DigitalOcean droplets
2013-10-14 17:05:06 -07:00
Michael DeHaan
beae21dd40 Remove examples of module antipattern of setting the choices array for boolean types. 2013-10-11 08:45:13 -04:00
Daniel Koch
5d02fb6ca1 Add check to make sure dopy is at least version 0.2.2 for digital_ocean module 2013-10-02 20:29:35 -04:00
Daniel Koch
a650b899c6 Add "virtio" and "private_networking" options for DigitalOcean droplets
The dopy manager defaults to False for virtio, but the DigitalOcean web interface defaults to True, which is a pretty safe default and sensible considering the performance gains.

Private networks are a new feature currently available only in the NYC2 region as of Oct 2, 2013.

NOTE: dopy >= 0.2.2 is required for these options to work.
2013-10-02 18:06:35 -04:00
James Cammarata
8ba5ed4d68 Added a version_added string to the new digital_ocean module param 2013-09-25 16:49:48 -05:00
Ralph Bean
1d0a7baaa1 Add a new unique_name param to the digital_ocean module for idempotence.
As it stands now, it is difficult to write idempotent tasks for digital
ocean droplets.  Digital ocean assigns new nodes a random id when they
are provisioned and that id is the only key that can be used to identify
it in subsequent runs of that play.

The workflow previously involved manual intervention:

- write a play defining a new node with no specified id
- run it, collect the randomly assigned id by hand
- modify the play to add the id by hand so future runs don't create
  duplicate nodes
- perform future re-runs that check if the node exists (by its id)
  - if it does exist then do nothing.
  - if it does not exist, then create it and return a *new random id*
  - collect the new random id by hand, modify the playbook file, and
    start all over.

Its a huge pain.

The modifications in this commit allow you to use the 'hostname' as a
primary key for idempotence with digital ocean.  By default, digital
ocean will let you create as many hosts with the same hostname as you
like.  Here, we provide an option to constrain the user to using only
unique hostnames.

The workflow will now look like:

- write a play defining a new node with a specified hostname and
  "unique_name: true""
- run it, create the new node and move on.
- re-run it, notice that a node with that hostname is already created
  and move on.
2013-09-18 16:07:22 -04:00
Ralph Bean
277a918e12 Fix an example with a yaml syntax error. 2013-09-18 15:49:41 -04:00
Ralph Bean
a1738163a8 Fix some "make pep8" errors in the digital_ocean module. 2013-09-18 15:41:55 -04:00
Ralph Bean
06edce08f6 Remove trailing whitespace in digital ocean module. 2013-09-18 11:06:32 -04:00
Ralph Bean
46c18d44f0 Remove duplicate docs in digital ocean module.
The EXAMPLES block here has two copies of the same docs,
one nicely formatted, the other less so.

It looks like a pass was made to clean up the docs but the old
cruftier ones were never removed.
2013-09-18 11:05:06 -04:00
Bryan Larsen
f440b5b46a update_attr should wait for the full wait timeout before checking for a missing IP addres 2013-07-11 14:05:26 -04:00
Bryan Larsen
3fe9756281 digital_ocean doc update 2013-07-11 13:33:42 -04:00
Bryan Larsen
69ff43d253 digital_ocean: don't run update_attr if wait=no
Sometimes when using digital_ocean with wait=no I get the error "No ip is found".  But with wait=no I wouldn't expect there to be any IP, that gets allocated later.   However, looking at the code, it turns out that with even with wait=no it waits up to 10 seconds for an IP to be allocated.  We could wait longer, but with wait=no that seems like the wrong choice; it's easy enough to grab an IP later with a wait=yes command.

To make this change I removed the call to update_attr in @classmethod add.  An add is always followed by an ensure_powered_on which will do the update_attr if wait=yes.   It would be possible to instead do a call to update_attr with no retries and ignore the errors but I figured it would be better to be consistently not return an IP than to sometimes return it and sometimes not.   Inconsistent behaviour makes debugging deployment scripts very difficult.
2013-07-11 13:30:42 -04:00
Benjamin Schwarze
7cc00f9a03 fix wrong argument_spec in digital_ocean module
as 'required' and 'default' are mutually exclusive removed 'required' in preference of 'default'
2013-06-22 14:48:25 +02:00
Michael DeHaan
0ed5d18d60 Fixup versions of newly added modules. 2013-06-19 22:39:08 -04:00
Michael DeHaan
997bf64f3f Fix up some module docs formatting errors. 2013-06-19 22:37:09 -04:00
Michael DeHaan
e6bc5ce124 YAML fix 2013-06-19 22:33:19 -04:00
Michael DeHaan
f986665c5d Merge branch 'ocean' into devel
Conflicts:
	library/cloud/digital_ocean
2013-06-19 21:53:33 -04:00
Michael DeHaan
a85c97edfb Reformat examples 2013-06-19 21:52:59 -04:00
Vincent Viallet
a8e6e7c312 Rename digital ocean module to digital_ocean, add documentation. 2013-06-19 21:49:05 -04:00
Vincent Viallet
fe7fcf2d15 Rename digital ocean module to digital_ocean, add documentation. 2013-06-18 10:45:45 +08:00
Renamed from cloud/do (Browse further)