Not sure if anyone else has already done this. But I needed to start up an instance, get back the instance id cleanly so I could then setup the instance.
tasks:
- name: spin it up
local_action: ec2_run_instance keypair=skvidal image=emi-3F1C4010 type=m1.large
register: inst_res
- name: assign it a special ip
local_action: shell euca-associate-address -i ${inst_res.instances[0].id} 210.121.212.112
- name: wait for the reassignation
local_action: wait_for host=210.121.212.112 port=22 delay=20
- name: give it a better hostname:
action: command hostname ec2_ansibled
my eventual goal is to use this from my admin host to keep certain cloud instances always up and to make sure they get a specific ip, volumes attached, etc.
it does not implement everything that euca-run-instance implements but I got all of the functionality I care about at this very moment. If anyone wants to add things on - patches welcome.
Very very cool. If the host already existed in inventory (and we do
need to think about dynamic inventory, REST API is going to help), you
could easily pass in some parameters with --extra-vars and have a
pretty tight solution for deploying it
and then starting to manage it, probably including some very nice
wrapper scripts.
Assuming the "euca-associate-address" stuff is Eucalyptus specific, so
not entirely sure of how that looks in ec2, but very interested in
exploring.
(BTW, I still am going to make Contrib modules move from a README.md
to part of the docs project so everybody finds it -- and that can
include a short blurb about my people should explore
ansible-provisioning)
There are some assumptions about ansible-provisioning that I think we
still need to change, such as the usage of 'cmdb' variables. Not
everyone is going to have a 'cmdb', so we should probably just rename
those to something simple.
What we may do in the near short-term, I don't know, is make library
modules be able to live in subfolders, so we can namespace them. So
you could do things like "provisioning_blarg"
Perhaps pedantic, but I think the "ec2_run_instance" is a bit long,
maybe "ec2_launch" ?
Very very cool. If the host already existed in inventory (and we do
need to think about dynamic inventory, REST API is going to help), you
could easily pass in some parameters with --extra-vars and have a
pretty tight solution for deploying it
and then starting to manage it, probably including some very nice
wrapper scripts.
Which is exactly what I'm gonna do.
Assuming the "euca-associate-address" stuff is Eucalyptus specific, so
not entirely sure of how that looks in ec2, but very interested in
exploring.
No - that's an ec2-generic. It's not euca-special.
(BTW, I still am going to make Contrib modules move from a README.md
to part of the docs project so everybody finds it -- and that can
include a short blurb about my people should explore
ansible-provisioning)
There are some assumptions about ansible-provisioning that I think we
still need to change, such as the usage of 'cmdb' variables. Not
everyone is going to have a 'cmdb', so we should probably just rename
those to something simple.
understood - I didn't really get what the cmdb was when I read through the code for the first time so it was kinda blurry to me.
I was planning on just storing the variables I need in host_vars of my inventory.
What we may do in the near short-term, I don't know, is make library
modules be able to live in subfolders, so we can namespace them. So
you could do things like "provisioning_blarg"
not a problem. one nice thing about how ansible fits together is I can just keep this is my local library dir and have it all work w/o a headache
Perhaps pedantic, but I think the "ec2_run_instance" is a bit long,
maybe "ec2_launch" ?
fine - renaming it doesn't bother me. I just chose run_instance b/c it's the same name as the script in ec2/euca.
There are some assumptions about ansible-provisioning that I think we
still need to change, such as the usage of 'cmdb' variables. Not
everyone is going to have a 'cmdb', so we should probably just rename
those to something simple.
The cmdb variables are examples, they might come from your host_vars or group_vars, it really does not matter. The modules are not tight to this at all.
But I cannot give you an example for provisioning HP iLO, VMware and KVM with a single playbook, without having some clue what each hostname is. Which is where in this case the cmdb_ variables are used for, as an example.
What we may do in the near short-term, I don't know, is make library
modules be able to live in subfolders, so we can namespace them. So
you could do things like "provisioning_blarg"
I don't think anything needs to be done. The ansible-provisioning rpm just drops the modules in the normal place for those that want to use them.
