[OpenStack-Infra] [gear] Making Gear easier to consume ( less .encode() and .decode() )

Morgan Fainberg morgan.fainberg at gmail.com
Mon Jun 20 19:03:08 UTC 2016


As I have been converting Zuul and NodePool to python3, I have had to do a
bunch of changes around encode() and decode() of strings since gear is
(properly) an implementation of a protocol that requires binary data
(rather than text_strings).

What this has highlighted is that gear should be made a bit more friendly
to use in the python world. We already explicitly assume a utf-8 encoding
for when things are turned into "binary" when crafting the job object in
certain cases [1].  I have discussed this with Jim Blair, and we both agree
that the ability to still reference attributes such as "job.name" (in a
simple manner that is straight forward), is important.

Here is the outline of the change I'm proposing:

* The main consumable part of gear (public classes) will convert the
"string" data we assign ( name[2], unique[3]) into utf-8-encoded bytes via
@property, @property.setter, and @property.getter for public consumption.

* Arguments are explicitly supposed to be a binary_blob [4]. I am unsure if
this should also be automatically converted *or* if it should be the
inverse, .arguments and .arguments_string ?

* Internally gear will reference the encoded bits via the underlying
<name>_binary form, which will allow direct access to a non-"string" form
of the data itself in the case that there is interesting things that need
to be handled via binary packing (for example) instead of "stringified"
versions.

* For compatibility the main @property.setter will handle either
binary_type or string_type (so we don't break everyone).

* The "<name>_binary" will enforce that the data with be a binary_type
only.


I think this can be done in a single release of gear with minimal impact to
those using it. For what it is worth, it is unlikely that anyone has used
gear extensively in python3 as of yet because of recent bug fixes that
addressed py2->py3 compat issues around dict.values() and similar list() ->
iter() changes.

See the one question in the above proposal for "arguments".

[1]
https://github.com/openstack-infra/gear/blob/59d29104cb9c370e49b44f313e568bd43b172e1b/gear/__init__.py#L86
[2]
https://github.com/openstack-infra/gear/blob/59d29104cb9c370e49b44f313e568bd43b172e1b/gear/__init__.py#L2054
[3]
https://github.com/openstack-infra/gear/blob/59d29104cb9c370e49b44f313e568bd43b172e1b/gear/__init__.py#L2058
[4]
https://github.com/openstack-infra/gear/blob/59d29104cb9c370e49b44f313e568bd43b172e1b/gear/__init__.py#L2056

Thanks,
--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160620/417c1b05/attachment.html>


More information about the OpenStack-Infra mailing list