I feel like I've seen questions like this on the list before, but I'm
having a hard time finding one now; apologies if this is old ground.
I've got a playbook that provisions a new Rackspace Cloud host, and then
includes a role specific to that type of host. In that role, there are
some templates that need to know what groups the host is in. Because the
host didn't exist when our dynamic inventory script was run, it wasn't in
any groups then; but if the dynamic inventory script were run again, it
would be in some new groups now, including some that the script comes up
with -- wait for it -- dynamically.
So: Is there a way to force Ansible to refresh the inventory in the middle
of a playbook?
-Josh (jbs@care.com)
This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.
No, but you can add the machine to the necessary groups when you use
add_host after its created.
Hi
I feel like I've seen questions like this on the list before, but I'm
having a hard time finding one now; apologies if this is old ground.
I've got a playbook that provisions a new Rackspace Cloud host, and then
includes a role specific to that type of host. In that role, there are
some templates that need to know what groups the host is in. Because the
host didn't exist when our dynamic inventory script was run, it wasn't in
any groups then; but if the dynamic inventory script were run again, it
would be in some new groups now, including some that the script comes up
with -- wait for it -- dynamically.
http://docs.ansible.com/add_host_module.html may be useful for you.
So: Is there a way to force Ansible to refresh the inventory in the middle
of a playbook?
Not that I know of.
This email is intended for the person(s) to whom it is addressed and
may contain information that is PRIVILEGED or CONFIDENTIAL. Any
unauthorized use, distribution, copying, or disclosure by any person
other than the addressee(s) is strictly prohibited. If you have
received this email in error, please notify the sender immediately
by return email and delete the message and any attachments from your
system.
(sigh). Really??? Really?? Surely nobody uses that legalese rubbish
noise anymore?
I am now guilty of something that was prohibited - after all, this was
not addressed to me. I re-distributed and copied and disclosed your
possibly PRIVILEGED and CONFIDENTIAL email! Quick! Tell everybody to
delete it! (and then delete the emails about deleting it. Deny
everything!!). Perhaps I should turn myself in?
But I'm such a law breaker. Sometimes I press the button for the 3RD
FLOOR on the lift, even when only goin to the 2ND FLOOR! I'm not even
going to return the original mail to you! Hah! Take that! You'll
have to get NEW ones and zeros for your next email! That'll teach you!
bwhahahahaha!
No, but you can add the machine to the necessary groups when you use
add_host after its created.
Yeah, I can mostly do this; the tricky thing is that there are some
derived groups that the host gets added to based on logic in the dynamic
inventory script. I could in theory duplicate that logic in my playbook,
but it'd be hard to be sure to get right.
Another workaround would be to have a wrapper script that calls Ansible
twice, once to launch and then a second time to configure; the tricky
thing there is that we're using exact_count, and registering the new
instances, so that we know which ones are new. I'm not sure how we'd
preserve that across Ansible runs.
-Josh (jbs@care.com)
This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.
This email is intended for the person(s) to whom it is addressed and
may contain information that is PRIVILEGED or CONFIDENTIAL.
(sigh). Really??? Really?? Surely nobody uses that legalese rubbish
noise anymore?
Surely not. I can't explain where that text came from. Probably nobody
wrote it.
I am now guilty of something that was prohibited - after all, this
was not addressed to me. I re-distributed and copied and disclosed
your possibly PRIVILEGED and CONFIDENTIAL email! Quick! Tell
everybody to delete it! (and then delete the emails about deleting
it. Deny everything!!). Perhaps I should turn myself in?
But I'm such a law breaker. Sometimes I press the button for the 3RD
FLOOR on the lift, even when only goin to the 2ND FLOOR! I'm not even
going to return the original mail to you! Hah! Take that! You'll have
to get NEW ones and zeros for your next email! That'll teach you!
bwhahahahaha!
You are very funny and clever.
-Josh (jbs@care.com)
This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.
You could try abstracting out the logic into a separate script that
both your inventory and your provisioning playbook could call to
determine which groups to put it in. I agree that it's a bit of a
pain. I'd really like to have this be possible as well since it would
really simplify some workflows.
It should be possible to write something like that as an action plugin. The only problem I see would be: what to do with group_vars?
Michael Peters michael00peters@gmail.com napisał:
Bleah, so the latest snag I've run into is that our dynamic inventory
script sets some host variables, including some that are based on the
derived groups that it comes up with, and of course *those* aren't
available even after adding the host to a group during a run, because
they're not "group variables" per se. There's not a way to have a dynamic
inventory script create group variables, is there? It's all just host
variables?
It seems like the best approach here might be to just do it in two passes,
one run to provision the systems and a second one to configure them,
perhaps setting some metadata at Rackspace (in this case, or the analogous
thing for EC2 or whoever) so that the second pass can find hosts that need
post-provisioning configuration. (Which I also have a question about...
Stay tuned. :^)
-Josh (jbs@care.com)
This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.
There's not a way to have a dynamic inventory script create group
variables, is there? It's all just host variables?
That is certainly possible:
http://docs.ansible.com/developing_inventory.html#script-conventions
Oooh, that is super, and after modifying our custom dynamic inventory
script, it works great. Thanks!
One best-practices type question about this: A side effect of the change
to our script is that before, for each group, we were iterating over the
hosts in that group, and turning the variables associated with the group
into hostvars for the hosts; now, putting the variables into the groups
section, those variables don't show up as hostvars any more. We could, of
course, *also* put them into hostvars, but my intuition is that this would
be less correct: That if a variable is set as a group variable, you
wouldn't expect to see it in hostvars. True?
Thanks again for the tip!
-Josh (jbs@care.com)
This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.