Issue #1266
closed
The upgrade from python-kombu-3.0.24-8 to python-kombu-3.0.24-9 requires manual intervention from users
Status:
CLOSED - CURRENTRELEASE
Description
It looks like the 2.6-testing branch has an upgrade from python-kombu-3.0.24-8 to -9 in it. When using -9 with a default server.conf, Pulp is unable to communicate with the broker:
$ pulp-admin consumer unregister --consumer-id beav-mine-has-been-great-thanks-for-asking.os1.phx2.redhat.com
An internal error occurred on the Pulp server:
RequestException: DELETE request
on
/pulp/api/v2/consumers/beav-mine-has-been-great-thanks-for-asking.os1.phx2.redha
t.com/ failed with 500 - Username configured but no password. SASL PLAIN
requires a password when using a username.
We should do whatever is necessary to make it so users don't have to adjust their config when upgrading, especially since it is a z release.
- Priority changed from Normal to High
- Triaged changed from No to Yes
It is correct that the 3.0.24-9 release of kombu does require the server.conf broker string to be adjusted. We can revert the upgrade of kombu to the 3.0.24-9 from the 2.6.X release stream and leave the requirement to update the server.conf to a 2.7.0 upgrade. The downside is that 2.6.X will have a known deadlock because the broker string default in 2.6.X isn't safe and causes deadlock with SASL PLAIN low-level libraries prompting on stdin. Given that, do you think we should have the user modify their server.conf with 2.7.0 or 2.6.4? I'm ok with it either way.
Pulp wrote:
It is correct that the 3.0.24-9 release of kombu does require the
server.conf broker string to be adjusted. We can revert the upgrade of
kombu to the 3.0.24-9 from the 2.6.X release stream and leave the
requirement to update the server.conf to a 2.7.0 upgrade. The downside
is that 2.6.X will have a known deadlock because the broker string
default in 2.6.X isn't safe and causes deadlock with SASL PLAIN
low-level libraries prompting on stdin. Given that, do you think we
should have the user modify their server.conf with 2.7.0 or 2.6.4? I'm
ok with it either way.
Can we not simply adjust the default in config.py (and also in the
server.conf template) so that upgrading users do not need to do anything?
The broker string default in server.conf and config.py are both made with commit d73f4753d9c9a6a2867e12928b214d489081713a That commit is on 2.6-testing+ (2.6.5). I perceived the "manual step" that the user may need to merge the new server.conf.rpm and their server.conf file if their modified server.conf in some other way. That merging could be unexpected on a Z release.
Did you not receive that change, and that caused you to experience the issue? What do you think should be done for 2.6.5 in this regard?
Pulp wrote:
The broker string default in server.conf and config.py are both made
with commit d73f4753d9c9a6a2867e12928b214d489081713a
<https://github.com/pulp/pulp/commit/d73f4753d9c9a6a2867e12928b214d489081713a#diff-131aac993b7a876f5b36ffba3ef6c9be>
That commit is on 2.6-testing+ (2.6.5). I perceived the "manual step"
that the user may need to merge the new server.conf.rpm and their
server.conf file if their modified server.conf in some other way. That
merging could be unexpected on a Z release.
Did you not receive that change, and that caused you to experience the
issue? What do you think should be done for 2.6.5 in this regard?
Given the above, I think you have assuaged my fears as I can probably
explain what happened to my dev box. I installed my dependencies using
the beta repository which would have given me this new Kombu, but I was
developing pulp-docker against Pulp 2.6-release. Thus, I had the new
Kombu but not the commit you linked above.
My only ask at this point is that someone tests to make sure that users
with a commented broker setting can update from 2.6.4 to 2.6.5 without
any action. Can we keep this ticket open to track that testing?
Unfortunately, I will not be available this week to help, but if 2.6.5
is still not released by next week I can help then.
Thanks for the explanation!
rbarlow wrote:
My only ask at this point is that someone tests to make sure that users
with a commented broker setting can update from 2.6.4 to 2.6.5 without
any action. Can we keep this ticket open to track that testing?
+1 for testing it the 2.6.4 -> 2.6.5 upgrade with a commented broker setting
- Status changed from NEW to 5
- Status changed from 5 to CLOSED - CURRENTRELEASE
Also available in: Atom
PDF
.