Invalid line in /etc/hosts (two IP addresses) on AIO
Bug #1274263 reported by
Mark T. Voelker
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cisco Openstack |
Fix Released
|
Medium
|
Mark T. Voelker | ||
Havana |
Fix Released
|
Medium
|
Mark T. Voelker |
Bug Description
An h.1 AIO buildout leaves me with an /etc/hosts file that contains a line with two IP Addresses like this:
192.168.255.134 192.168.255.134
While this doesn't seem to impact functionality, I suspect it might cause some trouble with Ceph if were ever to add it to AIO and clearly just isn't correct anyway. I've also noticed a line like this:
192.168.255.134 compute01 compute01.
In which the short and long hostnames are reversed. Again, doesn't seem to really impact anything functionally but is wrong.
Changed in openstack-cisco: | |
status: | In Progress → Fix Committed |
To post a comment you must log in.
I think this may the issue causing the two-IP- addresses- in-one- line problem:
The coe::base class has a parameter for $controller_ hostname:
https:/ /github. com/CiscoSystem s/puppet- coe/blob/ h.1/manifests/ base.pp# L10
Which gets used to create an /etc/hosts entry:
https:/ /github. com/CiscoSystem s/puppet- coe/blob/ h.1/manifests/ base.pp# L164-L167
But the data mappings in data/data_ mappings/ common. yaml that actually feed that class look questionable in that they map the controller_hostname parameter to controller_ internal_ address:
https:/ /github. com/CiscoSystem s/puppet_ openstack_ builder/ blob/h. 1/data/ data_mappings/ common. yaml#L108 /github. com/CiscoSystem s/puppet_ openstack_ builder/ blob/h. 1/data/ data_mappings/ common. yaml#L60
https:/
That's problematic because controller_ internal_ address is, as the name implies, an IP address:
https:/ /github. com/CiscoSystem s/puppet_ openstack_ builder/ blob/h. 1/data/ hiera_data/ user.common. yaml#L64- L68
That results in the line with duplicate IP addresses. To fix it, we should eliminate that mapping and map it to something more sensible (or don't map it to anything and set it explicitly in yaml). Note that this wouldn't affect HA builds since user.full_ha.yaml has an explicit override:
https:/ /github. com/CiscoSystem s/puppet_ openstack_ builder/ blob/h. 1/data/ hiera_data/ user.full_ ha.yaml# L11
Doing similar in the non-ha yamls would be a simple workaround for the issue.