Description of problem: host=localhost in /etc/nova/nova.conf and /etc/neutron/neutron.conf on the compute nodes and needs to be manually changed to the proper hostname Version-Release number of selected component (if applicable): How reproducible: In this deployment Steps to Reproduce: 1. Scale-up a new compute 2. 3. Actual results: grep ^host /etc/nova/nova.conf grep ^host /etc/neutron/neutron.conf Expected results: Should have the proper hostname Additional info: We're using predictable IPs without a hostnamemap (just it case we should be)
Can you please explain how to reproduce this? BTW.: The compute nodes have to have a name, just the IP will not work. It doesn't have to be dns resolvable, but there must be a name set. So that could be actually the problem.
Hello sir, I do not really know how this happens. We're deploying the computes and instead of having "host" commented out so it uses the hostname of the compute, it is uncommented and set to localhost. We have to manually login the computes and controllers in order to simply comment out those values in nova and neutron. I tried finding where "host" is set in the puppet manifests but I couldn't find where. Thank you very much, David Hill
(In reply to David Hill from comment #2) > Hello sir, > > I do not really know how this happens. We're deploying the computes and > instead of having "host" commented out so it uses the hostname of the > compute, it is uncommented and set to localhost. We have to manually login > the computes and controllers in order to simply comment out those values in > nova and neutron. I tried finding where "host" is set in the puppet > manifests but I couldn't find where. It's set right here (at least in the current version): https://github.com/openstack/puppet-nova/blob/master/manifests/init.pp#L655 So it is either commented out, or it comes from outside (THT) as the $host parameter. So probably TripleO-Heat-Templates are setting it to localhost, because there is no hostnamemap, as you said. Can you check to set a hostnamemap?
Closing, because there is not enough info to reproduce the issue here. Please feel free to reopen, if more info becomes available.
Hello, I see this same issue. Everything is working fine. Customer does scale up deploy and all compute nodes service fails. host=localhost. Also same issue in neutron.conf changing to the correct host fixes. What can we check to see if templates are setting host=localhost? Thanks,
The title is "host=localhost in /etc/nova/nova.conf..." Yet the description states: Actual results: grep ^host /etc/nova/nova.conf i.e host isn't set in nova.conf at all. So which is correct? I'll assume grep is correct as we do not set host in nova.conf via puppet. This suggests the hostname isn't configured correctly due to an invalid hostnamemap e.g the index has incremented due to a deleted node or a failed scale out but the hostnamemap has not been incremented to match.
(In reply to Ollie Walsh from comment #8) > .. as we do not set host in nova.conf via puppet. Actually we do e.g this is the hieradata:: "neutron::host": "%{::fqdn}", "nova::host": "%{::fqdn}", Which still suggests that the hostname has not been configured correctly.
Closed due to insufficent data or not a bug
We're able to reproduce this with another customer ...
David: please describe what "this" is? And also link to the customer case with reproducer If you mean bug #1499398, the root cause for host=localhost in these configuration files was: 1. The host name assigned via DHCP and presumably in DNS is osrz110023 2. The host name in the template files, including the host map, is osrtpz11023 3. The 'hostname' command on this host returns 'osrz110023.localdomain' 4. Because /etc/hosts only contains osrtpz11023.localdomain, the 'hostname -f' command returns 'localhost' 5. The value returned from 'hostname -f' is what goes into these config files In this case - there is no software error. The hostname should be resolvable to a FQDN using 'hostname -f'. The /etc/hosts config just needs to be fixed to match the assigned hostname.
I messed up my example, let me try again If you mean bug #1499398, the root cause for host=localhost in these configuration files was: 1. The host name assigned via DHCP and presumably in DNS is foo0023 2. The host name in the template files, including the host map, is foo023 3. The 'hostname' command on this host returns 'foo0023.localdomain' 4. Because /etc/hosts only contains foo023.localdomain, the 'hostname -f' command returns 'localhost' 5. The value returned from 'hostname -f' is what goes into these config files
I verified that this appears to no longer be an issue in 11. We'll have to look as to why this is occurring in 9.0.
So in general changing host or domain names after the initial deployment is a bad idea. Even if you don't hit this localhost problem (which seems to be a result of manual edits of /etc/hosts), any networks or instances that were created before the name change will be inaccessible afterward. At least this has been my experience. I'm not sure we document that and we should. An RFE to disallow hostname or domain changes might also be appropriate, although I'm not entirely sure how we would do that.
As Alex said, this bug no longer appears in 11, also all related 3 cases are now closed, therefore we'll close the bug unless there is anything you want us to do, then please re-open.