The title is misleading but you're encountering https://github.com/kennethreitz/requests/issues/2568

This is a bug in urllib3 which we believe has been fixed in the following pull requests:

• urllib3/urllib3#599
• urllib3/urllib3#605

Requests 2.7.0 should be out soon fixing this issue.

from rpc-maas.

We're now installing requests 2.7.0, which resolves this issue. Closing.

from rpc-maas.

@mattt416 @sigmavirus24 Does this effect Juno at all?

from rpc-maas.

@claco shouldn't: https://github.com/stackforge/os-ansible-deployment/blob/juno/requirements.txt#L8

from rpc-maas.

@mattt416 @sigmavirus24 @claco Yes it does affect juno. You guys were looking at the wrong requirements.txt, the rpc-maas in juno is hosed and does not limit the version https://github.com/rcbops/rpc-maas/blob/juno/requirements.txt#L2

from rpc-maas.

@BjoernT We do use that requirements.txt file but it will be used after pip.conf is configured w/ the RPC mirror, and that should have built the version of requests specified in os-a-d's requirements.txt. Are you actively seeing broken juno deploys here?

/cc @sigmavirus24 @claco

from rpc-maas.

Yes I had one deployment having 2.6.0 installed and I did manually downgrade to 2.4.1. They used MAAS 10.1.3 version

from rpc-maas.

@BjoernT was the pip.conf not in place? The only way to get 2.6.0 would have been from PyPI because http://mirror.rackspace.com/rackspaceprivatecloud/python_packages/10.1.3/ has 2.4.1

from rpc-maas.

The pip.conf was in place but I did not look into it because I did upgrade to 10.1.4 and that repository had 2.6.0 in, along with 2.4.1. Now it appears that we have remove 2.6.0 so it would not happen again

from rpc-maas.

@mattt416 @sigmavirus24 @claco
This check is still failing on a new 10.1.5 build:

status error module>\n main(args)\n File "./horizon_check.py", line 100, in main\n check(args)\n File "./horizon_check.py", line 29, in check\n requests.packages.urllib3.disable_warnings()\nAttributeError: 'module' object has no attribute 'disable_warnings'\n
Traceback (most recent call last):
File "./horizon_check.py", line 109, in
main(args)
File "./horizon_check.py", line 100, in main
check(args)
File "./horizon_check.py", line 29, in check
requests.packages.urllib3.disable_warnings()
AttributeError: 'module' object has no attribute 'disable_warnings'

Installed libs:
requests==2.2.1
urllib3==1.10.4

from rpc-maas.

Hi @BjoernT,

I've confirmed this is a problem. @cloudnull or @sigmavirus24, do either of you know why we're now building requests 2.2.1 in juno/10.1.5? I can see that we no longer pin to requests 2.4.1 however I don't see why we'd end up building such an old version of requests.

--Matt

from rpc-maas.

@cloudnull @sigmavirus24 @mattt416 Can we get this resolved ? I don't want to hand over environments with failed horizon checks....

from rpc-maas.

Sorry, I missed this while I was at the summit. I have no clue why 2.2.1 is being built for 10.1.5, that said, a conditional check before calling disable_warnings would work (like the one I had sent in a PR earlier) because 2.2.1 does not in fact issue warnings so there's nothing to disable.

from rpc-maas.

This issue is present since 10.1.4 (maybe even 10.1.3). I'm not eager to remove the disable_warnings from the maas checks since we still have the problem that the maas checks do not update properly during upgrade (See https://github.com/rcbops/rpc-extras/issues/95) So we would most likely run outdated and/or modified checks after upgrades. Since we had requests 2.4.1 before I don't know why we downgraded to that version just recently

from rpc-maas.

@BjoernT "conditional check before calling disable_warnings" means we would only call disable_warnings if it is present to be called. This means that if some ancient version of requests is installed by some evil magic, then we don't stacktrace. If a new version is installed, then in fact it will be called.

from rpc-maas.

I was digging around to see why we have a lower version of requests in 10.1.5 onwards and the version we now build does align with https://github.com/openstack/requirements/blob/stable/juno/global-requirements.txt:

requests>=2.1.0,!=2.4.0,<=2.2.1

This then raises the question as to how we were getting a newer version in previous tags, but at least we are now building requests correctly.

from rpc-maas.

This then raises the question as to how we were getting a newer version in previous tags, but at least we are now building requests correctly.

One of the OpenStack client releases broke the gate along the way and some people went through and applied upper caps on all the dependencies based off of (what I still insist) was a fault list of dependency versions being tested at the gate.

from rpc-maas.

@sigmavirus24 @mattt416
This issue is still present on new builds with 10.1.8, can we get this reopened

#python /usr/lib/rackspace-monitoring-agent/plugins/horizon_check.py 172.29.237.146
status error orizon_check.py", line 100, in main\n check(args)\n File "/usr/lib/rackspace-monitoring-agent/plugins/horizon_check.py", line 29, in check\n requests.packages.urllib3.disable_warnings()\nAttributeError: 'module' object has no attribute 'packages'\n
Traceback (most recent call last):
File "/usr/lib/rackspace-monitoring-agent/plugins/horizon_check.py", line 109, in
main(args)
File "/usr/lib/rackspace-monitoring-agent/plugins/horizon_check.py", line 100, in main
check(args)
File "/usr/lib/rackspace-monitoring-agent/plugins/horizon_check.py", line 29, in check
requests.packages.urllib3.disable_warnings()
AttributeError: 'module' object has no attribute 'packages'

pip list | egrep 'requests|urllib3'

requests (2.2.1)
urllib3 (1.7.1)

from rpc-maas.

@sigmavirus24 @mattt416 BUMP

from rpc-maas.

Bumps aren't how this is supported to work. :-) Please bring this to the rpc bug triage meeting tomorrow.

from rpc-maas.

I try every channel possible. We still have the problem and I can't understand that this bug is closed

from rpc-maas.

Hi @BjoernT, we've had #211 open for quite some time. I've already 👍 it but I'll make sure someone else reviews this morning so it gets merged.

@nrb @claco can you guys please make sure the above commit is included when we cut the next 10.x tag?

from rpc-maas.

Yeah @mattt416 the #211 never made it into the Juno branch, until 5 hours ago, so we missed it for 10.1.9.

from rpc-maas.

@mattt416 @BjoernT This will get into 10.1.10.

from rpc-maas.