This is all necessary to bump the lower-constraint on msgpack so we
can support msgpack 1.0 without version-specific logic in our code.
The reasons for the changes are as follows:
* greenlet and PyYAML bumped because the previous lower-constraints
for those didn't install on python 3.7, which is a supported Python
version.
* msgpack-python is removed. It was replaced by msgpack and there is
no new enough release of it to satisfy the needed minimum version bump.
* oslo.serialization is bumped because the old version was pulling in
msgpack-python, which overwrote our new needed version of msgpack.
* I went ahead and included the msgpack bump to 0.6.0 so we can move
forward in the subsequent patch with supporting msgpack 1.0.0.
It could be argued that this should be included in the msgpack 1.0.0
change, but it ended up being complex enough that I thought it was
worth it to split it out.
Change-Id: I69dae65d3e0a40bb2304d74de078ab84fc778d58
[1] added futures as a requirement for Python 2, but did not include
it as part of the requirements.txt and lower-requirements.txt files.
[1]- https://review.openstack.org/593556
Change-Id: I741f406ac348a09dc0ea08396a1f7242652fde6f
Fix the lower constraints values to match the expected values.
We will manage the eventlet version using constraints now. See the
thread starting at
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129096.html
for more details.
Update msgpack to >=0.5.0 because 0.4.0 is no longer available on PyPI
and we need the lower bound to match the lower constraint.
Change-Id: Ic692cc024bc60b1913fb9eac60be92f7dd353a89
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This change switches from JSON to msgpack for encoding messages on the
privileged channel. The binary encoding is faster(*) and msgpack's
primitives are a better fit for Python's. In particular, bytes and
non-string dict keys are supported without an additional layer of
encoding.
Note that lists are now converted to tuples across
serialization/deserialization, and this is the opposite of the previous
behaviour. There is no point modifying arguments to privsep
entrypoints, and this makes the values hashable (if desired) without an
additional conversion step.
(*) Since you asked: For a trivial arg/return value, this version is
about 1.5x faster than the previous json version - and many times faster
for non-trivial cases. Please focus on the "better fit for python's
datatypes" aspect however.
Change-Id: I4299c2fc059807610f83e12a2d470e020930c64c
The _fd_logger function works around a regular Unix pipe, with a python
file object wrapped around both pipe file descriptors. This would be
stupidly simple and obvious, except eventlet.
We need to use the fdopen from io.open(), and not os.fdopen() (on py2;
on py3 they're the same), because the older python file objects have
broken behaviour regarding blocking reads. Eventlet doesn't monkey
patch os.pipe, nor anything in io.* - so none of the existing eventlet
monkey_patching will "just work" for our case.
This change adds a custom `fdopen` function that explicitly uses
greenio.GreenPipe or io.open as appropriate - and uses this to always
return an eventlet-safe file object.
Change-Id: I4a6c0d4247aca17536316fb0ab163241ad545b20