Summarizing some issues with the DO module, would like some feedback on
how best to go about the implementation, especially from some other DO
users.
1.) Library use. I'm currently using the Skiff library,
https://github.com/Shrugs/skiff. It's still a young library. The author
is actively working on this and has been extremely responsive in terms of
fixes. There's good opportunity for some parallel development, but it's
worth assessing whether this is the right library to use or if it's worth
waiting for the dopy library to update to v2, or potentially abandon both
and work directly with the API.
Directly with the API might be reasonable. I don't know the relative
complexity of what we need to do, but I'm a little scared because this is
so new and you've listed some problems with it.
2.) v2 API maturity. The current API is still in beta and is lacking in a
couple areas that would be convenient.
Ok this is interesting and makes me think we can hold off a bit maybe.
There are two issues I've encountered so far. You can only refer to public
images by slug, so if you've created a private image/snapshot, the API
requires you to refer to it by ID which is not convenient for the user.
I think the most common request right now is just public slugs, but it
might be they don't plan to do this at all - and that maybe ok. It might
be worth asking DO to weigh in on this issue.
I've addressed this by querying for all images available to an account and
looping through until I find the image with the given name. The same issue
applies to SSH keys. You have to refer to keys either by ID or fingerprint,
neither of which is convenient. I handle this in a similar way by querying
for all keys and looping through. In the case of both images and SSH keys,
my implementation allows for you to use ID, name, slug, and fingerprint for
keys--it will return whatever it finds. Is the Ansible module a good place
to implement this extra level of usability? Could the performance hit
resulting from these queries be an issue? Should these features be pushed
back in to the Skiff library as contributions there?
Seems fine for Ansible to do this and not out of the ordinary relative to
things we might do in other modules.
Not concerned with performance as we are talking about a very small number
of lookups.
3.) v1 backwards compatibility. The current digital_ocean module has some
unusual functionality. You can call it either using "command=SSH" or
"command=droplet". If you run in SSH mode, it behaves exactly like the
digital_ocean_sshkey module. When setting up SSH keys for a new droplet,
from what I can tell there's no functional difference between running the
digital_ocean module twice using each mode, or running the
digital_ocean_sshkey module before running the digital_ocean module.
Thanks for highlighting this. In this case I'm fine with dropping the
command parameter by undocumenting it and making it raise an error when
used with the value "ssh" about how to fix it. The command=droplet should
continue to work.
We don't like verbs in ansible modules, so this needs to go.
Additionally, backwards compatibility won't be entirely possible because
of the use of a single token for authentication vs. the client_id and
api_key in the previous API.
My solution is to create a totally new digital_ocean_droplet module and
leave the current digital_ocean module as-is.
Ideally, we need to go with one module.
Are you saying they changed the API auth system so the old auth system
doesn't work with the new API? That's kind of crap ... but we'll have to
deal with it. We should make it so each DO module takes both if we can -
but if we can't, seeing the level at which this has been executed I am ok
with perhaps deprecating the old module and putting a scary note in the
docs after all.
And we can delete that old module after 2-3 releases.
This is also in better alignment with the way the DO v2 API is organized.
Would like to hear thoughts on how best to migrate to the v2 API, whether
to implement separately as digital_ocean_droplet, and whether to leave out
the "command" argument in favor of exclusively using the
digital_ocean_sshkey module for working with keys.
Sounds like I'm ok with the above, but I'd like all the modules to accept
the new auth mechanisms.
4.) New v2 API features. The v2 API has several more features. In
particular, it supports actions. There are image actions and droplet
actions. These are pretty useful, such as rebooting or powering off a
droplet. I'm imagining these being implemented using an "action" parameter
in the module. This is low-priority, but something to consider going
forward. If the v2 module implements the "command" argument, will it be
confusing to also have the "action" argument?
This maybe needs to be a digital_ocean_action module to keep it from
polluting the provisioning modules too much. We should also make sure
common DO code lives in a common module snippet, like we have for ec2, to
avoid repeats.
I know there is a lot going on here, do you feel ok with taking all of this
and kind of consolidating it either into one PR, or emailing when all the
related PRs are done so we can review/execute together?
I think the worst would be if it were half-done and unclear when to use
which, or when auth was different between different module types.
Has DO said they plan to retire v1 on any particular date?
