[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OpenShift-v3 Beta3 -- BYO ansible playbook failure (hostname lookup ?)

Still, no luck :(( 

I amended my "/etc/ansible/hosts" to use "openshift_hostname" for all the nodes.  I  even "openshift_public_hostname" for the "master1"  with a permanent Elastic IP (even if, again, this is not intended to be used) .

Here is the gist with the whole log of the playbook run (using "-vvvv")   the content of "/etc/ansible/hosts" and the output of "--list-hosts" and "--list-tasks":   I tried running the playbook from the "master1" node itself, not an external "jumphost" 


(note: I editied out the Elastic IP of the "master1"). 

One question (and here comes out my Ansible ignorance): is it normal that "--list-hosts" lists "localhost" for all plays ? 

Thanks again for trying to help -- after two days wasted on this, this is rather frustrating....


On Tue, May 5, 2015 at 4:25 PM, Jason DeTiberus <jdetiber redhat com> wrote:
On 05/05/15 10:42 +0200, Florian Daniel Otel wrote:

Jason, all,

I have now replicated the issue from a fourth,  "jumpstart" host. The
entire output of the "ansible-playbook -vvvv
for this run is located here:

Thanks again,


On Mon, May 4, 2015 at 9:47 PM, Florian Daniel Otel <florian otel gmail com>

Thanks Jason,

Not sure what "public hostname" you are referring to since this setup is
completely isolated / self-contained:

For cloud environments we try to distinguish between publicly accessible hostnames and IP addresses and internal only hostnames and IP addresses, with the assumption that users will want to access their OpenShift environment publicly (for some value of publicly).  We use the instance metadata within the openshift-facts module to do this.  In this case, we are incorrectly assuming that an instance always has values for the given metadata item associated with public/private hostnames and ip addresses (which is not the case for certain VPC configurations).

I have a set up a  DNS server on the same VPC subnet. It acts as zone
master for my internal domain (in my case "nuage-vpc253.internal") +
forwarder. This is a fourth host, in addition to my (intended...) 1x master
+ 2 x nodes.

The entries in my "nuage-vpc253.internal" zone  for my nodes are the VPC /
subnet-local IP addresses.

(yes, these are DHCP addresses from the VPC subnet. And yes, I know that's
wrong .. :)) .  However, they seem to persist throughout the instance
lifetime and this setup is simply intended as a test environment, isolated
from any outside use)

No issue with this in this case, the only thing is that you can only rely on the auto-detected value of the openshift_hostname value. The value for openshift_public_hostname will need to be overridden to account for the VPC configuration.

To override the detected public_hostname your inventory should look like the following:
/etc/ansible/hosts(trimmed, and each entry should be a single line, in case it gets wrapped in email):
# host group for masters
master1.nuage-vpc253.internal openshift_public_hostname=master1.nuage-vpc253.internal

# host group for nodes
node1.nuage-vpc253.internal openshift_public_hostname=node1.nuage-vpc253.internal
node2.nuage-vpc253.internal openshift_public_hostname=node1.nuage-vpc253.internal

This will override the detected value with the specified value (once the bug has been fixed in openshift-ansible that is causing openshift-facts to choke on aws metadata that does not contain an external or internal hostname).

I verified that both "hostname -s" and "hostname -f" return the correct
entries, and both resolve nicely to internal IP addresses from that DNS
server. This is  from any other host in the VCP  (All hosts in my VPC have
their "/etc/resolv.conf" pointing to the internal DNS server instead of AWS
provided DNS  -- hence all internal names resolve correctly)

LMK if there is any additional information you need.

One last question:

Is  there any issue with trying to deploy that from one of the nodes in
the setup itself (i.e. "master1" node) ? Should I use another "jumpstart"
host -- i.e. a fourth host, in addition to my 1 x master + 2 x nodes  ?

There *shouldn't* be an issue with installing from one of the hosts, however we have had issues crop up from time to time since most testing is done from a separate host.  Anything preventing ansible being run from one of the instances should definitely be considered a bug though.

Thanks for trying to help,


On Mon, May 4, 2015 at 6:33 PM, Jason DeTiberus <jdetiber redhat com>

On 04/05/15 11:54 +0200, Florian Daniel Otel wrote:

Hello all,

I'm trying to set up an OpenShift-v3 Beta3 environment consisting of 3
hosts -- 1 master + 2nodes, as follows (trimmed output of

# host group for masters

# host group for nodes


My problem: When on "master1" node I try to run the BYO Ansible playbook
(as per this GitHub repo -- https://github.com/detiber/openshift-ansible
as follows:

ansible-playbook -vvvv ./openshift-ansible/playbooks/byo/config.yml

The playbook results in an error:


 failed: [master1.nuage-vpc253.internal] => {"failed": true, "parsed":
Traceback (most recent call last):

line 4981, in <module>

line 461, in main
   openshift_facts = OpenShiftFacts(role, fact_file, local_facts)

line 36, in __init__
   self.facts = self.generate_facts(local_facts)

line 44, in generate_facts
   facts = self.apply_provider_facts(defaults, provider_facts, roles)

line 142, in apply_provider_facts
   facts['common'][h_var] =

line 164, in choose_hostname
   ips = [ i for i in hostnames if i is not None and
re.match(r'\A\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\Z', i) ]
 File "/usr/lib64/python2.7/re.py", line 137, in match
   return _compile(pattern, flags).match(string)
TypeError: expected string or buffera


 Now, if I'm reading that correctly, there's due to an error parsing the
hostname (?). Again, here's the output on said host.

You are correct that it is an error in parsing a hostname, though the
hostname I believe it is trying to parse is the AWS public hostname from
the metadata (I'm assuming the VPC you are using is configured to not issue
public hostnames).

I started working on a fix for this here:

I'll pick back up on it this afternoon (as time permits) and verify that
it does what it should do with different combinations of VPC configurations
for hostnames and ip addresses.

One other thing to note is that if you are going to access your
environment from outside of the VPC, then you will also need to provide the
openshift_public_hostname setting for the hosts (as described here:
especially if using the generated self-signed certificates.

Jason DeTiberus

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]