Bug 1789005

Summary: Candlepin fails to talk to qpidd listening on ::1 when connecting by hostname "localhost"
Product: Red Hat Satellite Reporter: Adam Ruzicka <aruzicka>
Component: CandlepinAssignee: Barnaby Court <bcourt>
Status: CLOSED NEXTRELEASE QA Contact: jcallaha
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.7.0CC: csnyder, jturel
Target Milestone: 6.8.0Keywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-01-13 15:07:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Adam Ruzicka 2020-01-08 14:59:40 UTC
Description of problem:

We have an environment where Satellite has 127.0.0.1 and ::1 on lo interface and something along the lines of fd::/64 on eth0. In this environment, qpidd listens on ::1 only.

In /etc/hosts we have
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

If we set candlepin.amqp.connect to localhost[1] in /etc/candlepin/candlepin.conf, candlepin goes into suspended mode.


Version-Release number of selected component (if applicable):
candlepin-2.9.14-1.el7.noarch


How reproducible:
Always


Steps to Reproduce:
1. Make qpidd listen on ::1 only
2. Set candlepin.amqp.connect to tcp://localhost:5671?ssl='true'&ssl_cert_alias='amqp-client'
3. Restart tomcat
4. watch /var/log/candlepin/candlepin.log

Actual results:
After a while these lines appear in the log

org.candlepin.audit.QpidConnection - Connection to Qpid was lost! Cleaning up current connection!
org.candlepin.controller.ModeManagerImpl - Entering new mode SUSPEND for the following reasons: [QPID_DOWN]
org.candlepin.controller.ModeManagerImpl - Candlepin is entering suspend mode for the following reasons: [QPID_DOWN]

Expected results:
Candlepin can talk to qpidd, these lines appear in log

org.candlepin.audit.QpidConnection - Attempting to connect to QPID due to status change: UNKNOWN --> CONNECTED
org.candlepin.audit.QpidConnection - AMQP connection factory created.
org.candlepin.audit.QpidConnection - AMQP session created successfully...

Additional info:

If I drop "localhost" from the line starting with 127.0.0.1, it suddenly starts working.

It seems as if candlepin resolves the name to 127.0.0.1 and doesn't retry with ::1 on failure.

[1] - The exact line is: tcp://localhost:5671?ssl='true'&ssl_cert_alias='amqp-client'

Comment 3 Adam Ruzicka 2020-01-08 15:17:04 UTC
Created redmine issue https://projects.theforeman.org/issues/28693 from this bug

Comment 5 Barnaby Court 2020-01-08 20:19:15 UTC
From IRC, to duplicate: 

"interface=::1" into /etc/qpidd.conf and restarting qpidd should work
[01/08 10:30] <aruzicka> eh, /etc/qpid/qpidd.conf

Comment 8 Jonathon Turel 2020-01-10 18:23:41 UTC
IMO this can be closed due to the reasons mentioned by Chris. Also, Artemis is not external to Candlepin like QPid is, so I don't think the same problem would be present.

Comment 9 Chris Snyder 2020-01-13 15:07:38 UTC
The version of Candlepin (3.1) to be included in Satellite 6.8 will no longer require Qpidd but instead rely on an internal Artemis instance. For this reason, this bug will no longer be an issue. As such closing as nextrelease.

If there is any disagreement with this decision please reopen this bug providing additional details so we may continue the discussion.

Thank you for your use of Satellite!