Gathering facts about servers newly created using the rax modules and dynamic inventory

[Dan Rough]

Hi there,

I'd like to understand how I can access a set of newly created rackspace servers using the group names that I specified at the point of creation.

At the moment, parts of my playbook are being ignored because the groups the new servers are added to at the point of creation are not being retrieved, even when I explicitly force a gather_facts.

If I run the play book a second time, the inventory correctly returns the group information for the servers that were previously created. I can see because of this that there is no error in the way they're being created. Note: we're using pyrax to give us a dynamic inventory.

This gist shows the playbook file, and also the infrastructure role which is called: https://gist.github.com/danrough/e0c8627dbc7b2153d983

In playbook.yml, the infrastructure role (the other file included in the Gist) is called and the servers are created. When they're created, the servers are added to host groups using a defined naming pattern, so that they can be referred to later.

After the servers have been created, a post-creation role is run against them which essentially adds some users and locks down SSH. All is well up until this point.

At line 14 in the playbook.yml file, I want to be able to access the servers using the group information I specified when the servers were created. This doesn't work. On subsequent runs of the playbook, it does. I assume that this is because the facts for the servers haven't been re-cached.

If I split the playbook into two separate files, the facts are gathered and I can access the servers. However, I need to keep this playbook as one complete file, as there as some plays (lines 103 onwards in playbook.yml) that I only want to run if the relevant servers have been created.

I've tried adding in a play which explicitly forces ansible to gather facts after the current line 12, by doing the following:

- hosts: "{{ target_environment }}"

  gather_facts: true

but this still isn't helping. What am I missing here?

Thanks!

[Tom Bamford]

Hi Dan

I see when you are invoking the add_host module from line 132 onwards in roles/infrastructure/tasks/main.yml, you add them to differently named groups than you otherwise reference from dynamic inventory. What happens if you add them to the same group names with add_host?

Regards

Tom

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/e6aa32fd-c7a7-484a-9c7f-1c0cc4e50584%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Rough]

I had literally just come to that same realisation Tom - it's god that you spotted it too. I'll make some changes and report back. Thanks!

[Dan Rough]

Hi,

Thanks for your response Tom, it got me further down the path but I'm running into problems elsewhere.

Though adding the hosts to the in memory inventory using add_host, when I want to refer to certain facts about the machines later, I can't seem to get some of the rax facts that would otherwise be present.

I've put in an additional play, the sole responsibility of which is to gather facts for the servers in inventory.

This is still returning an error, because a attribute doesn't exist within a dictionary object - interestingly though for a variable I'm not attempting to use.

Has anyone else come across this issue themselves?

I'm more or less hitting the point that I'll have to revert my approach to this, and go with separate playbooks.

Dan.

You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/mvLHsE2lLCE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/5e538f6c-688b-4e7f-95f6-ca4f53dedf7e%40googlegroups.com.

[Matt Martz]

To get facts about new machines that you would otherwise have from the rax.py inventory, you can use the 'rax_facts' module in your next play targeting your in memory group.

There are a few examples in http://docs.ansible.com/guide_rax.html

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CALWgV5ZwXmcO%2BBQV4m0z_u9uZr6UggsV8NeirH38Unju_nz3UA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Matt Martz
@sivel
sivel.net

[Dan Rough]

Hi Matt,

Thanks for your response. I should have mentioned above, I have experimented with using rax_facts.

The specific error I am getting is this, if it's any help:

"fatal: [dan-LON-app-01] => {'msg': "AnsibleUndefinedVariable: One or more undefined variables: 'dict object' has no attribute u'network-dan'", 'failed': True}"

"network-dan" being the name of the network I have created and added the server to. It's also not a variable that I am requiring access to at the point I am experiencing the problem which is why I assume this is a problem with the inventory, rather than the actual non-existence of the variable.

Dan.

To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAD8N0v93JGDPkW8-apXAOfUG9TtYS5WPtNnH70LytZZacy21Tg%40mail.gmail.com.

[Matt Martz]

I'd need to see more information about how it is being used.  That error alone just indicates you are trying to access a key that doesn't seem to exist, but without more context, I cannot really guess as to what the issue is.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CALWgV5Y9XYBo__v7uK2ABrqA5g2UpAETNJDT3HxUnXEWnsnXGQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.