This commit is part of a series to retire the Packaging Deb
project. Step 2 is to remove all content from the project
repos, replacing it with a README notification where to find
ongoing work, and how to recover the repo if needed at some
future point (as in
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project).
Change-Id: I3db6f86082fca5d5a42479ce8a7be4a06537a759
The doc-migration spec requires all projects to treat warnings
as errors during sphinx build. This patches turns that function
on.
Change-Id: I3b57177cc1dfa34dea57e62bbc93fafa40899899
As part of the docs migration work[0] for Pike we need to switch to use
the openstackdocstheme.
[0]https://review.openstack.org/#/c/472275/
Change-Id: I47d858fafd5d57f00cab9d7a4b87950320febf70
html_last_updated_fmt option is interpreted as a
byte string in python3, causing Sphinx build to break.
This patch makes it utf-8 string.
Change-Id: I896d6d962e4c7f932bc7e0a566a3b47205be61fb
Closes-Bug:#1693670
pyldap's start_tls_s function calls ldap_start_tls_s[1] which, if called
twice, returns LDAP_LOCAL_ERROR which causes a LDAP queries to fail with
the traceback:
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ldappool/__init__.py", line 258, in _create_connector
self._bind(conn, bind, passwd)
File "/usr/lib/python2.7/site-packages/ldappool/__init__.py", line 227, in _bind
conn.start_tls_s()
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 1095, in start_tls_s
res = self._apply_method_s(SimpleLDAPObject.start_tls_s,*args,**kwargs)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 1071, in _apply_method_s
return func(self,*args,**kwargs)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 780, in start_tls_s
return self._ldap_call(self._l.start_tls_s)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 263, in _ldap_call
result = func(*args,**kwargs)
LOCAL_ERROR: {'desc': u'Local error'}
This means that currently keystone's [ldap]/use_pool and [ldap]/use_tls
options are incompatible. This patch fixes the problem by removing the
unnecessary call.
[1] https://linux.die.net/man/3/ldap_start_tls_s
Change-Id: I6baff12bcbd3b110e62f4bcdfb97c561d7ee5fe9
Since pbr already landed and the old version of hacking seems not
work very well with pbr>=2, we should update it to match global
requirement.
Partial-Bug: #1668848
Change-Id: I2ff5ed75751f3448ff47c4f598d91f65b21ac84d
Adding constraints support to libraries is slightly more complex than
services as the libraries themselves are listed in upper-constraints.txt
which leads to errors that you can't install a specific version and a
constrained version.
This change adds constraints support by also adding a helper script to
edit the constraints to remove .
Change-Id: I41c6b3a2c4875128679b2dd8177425dd9f515ebc
Without this change, ldappool might fail to bind to an LDAP server for
any number of reasons, but eats most of them and instead raises its own
not-very-descriptive error. A network failure or the LDAP server being
down is useful information that a user might be able to do something
with (see this related patch[1]) so let's add that to the list of
exceptions ldappool raises directly.
[1] https://review.openstack.org/#/c/390948
Change-Id: Iebb58f9046707a044ed86d8ce940e4c230ffd2aa
* properly utf8 encode password
* switch to pyldap, the drop in replacement for python-ldap
Change-Id: Ic0fc838b8e015d90c946c3d161d096afe0bb7a21
Depends-On: I9cf13a5be63a0abc964c5a6e29c92d16365d89d8
Depends-On: I330b9b8fd3b53a588f0a1ae0c7de16cf03adb3cd
This is a port of a pull request from the old ldappool repo [1]
ldappool frequently catches and ignores transient errors.
There's nothing generally wrong with this -- but if the user
chooses to give the ldappool module a DEBUG priority level,
they really ought to be able to see these. This change makes it
so (and logs final connection errors with the higher ERROR level).
[1] https://github.com/mozilla-services/ldappool/pull/9
Change-Id: I223584393e6010845a5e7eb6aa619a77f6aba84f
This change is a port of an existing pull request for ldappool [1]
It simply raises a more appropriate error / stacktrace if unable
to bind.
[1] https://github.com/mozilla-services/ldappool/pull/3
Change-Id: I3a17160a76122a1e4d05112fc86e346dea5dd88b
Sometimes the main thread starts before the spawned thread, which means
that the thread that is supposed to hold open a connection starts after
the main thread has already successfully made a connection. This means
that the test for a successful connection attempt[1] was nearly useless
since the main thread would get the connection first and activate it[2]
no matter how long the spawned thread waited, and the test for a failed
connection attempt[3] would intermittently fail since is sometimes able
to get the connection before the busy-waiting worker thread does.
Adding a short sleep in the main thread ensures that the main thread
yields to the worker thread and it can grab the connection first so we
can actually test what happens in the main thread.
[1] http://git.openstack.org/cgit/openstack/ldappool/tree/ldappool/tests/test_ldappool.py#n183
[2] http://git.openstack.org/cgit/openstack/ldappool/tree/ldappool/__init__.py#n167
[3] http://git.openstack.org/cgit/openstack/ldappool/tree/ldappool/tests/test_ldappool.py#n193
Change-Id: Ic32ef931cd672907dd14d5ec6339a6d7d9a2018d
While the ldappool project is MPL and the license info is appropriately
associated with Tarek, setup.py is actually not a file written by him -
it is an exact copy of the boilerplate OpenStack setup.py file which is
Apache licensed. There should be no license issues with the project with
the OpenStack setup.py file being in use, as neither license are
incompatible with each other.
Change-Id: I0d334e624afe62a53b3324ee45ca9bc454ae1d4a