Open Stack

On 11/28/2017 01:50 PM, Dmitrii Shcherbakov wrote:
> Hi James,
>
> The side effect of using JSON is that we will lose type information:
>
> In [0]: json.loads(json.dumps([{1: 2}]))
> Out[0]: [{'1': 2}]
>
> In [1]: ast.literal_eval(repr([{1: 2}]))
> Out[1]: [{1: 2}]

I'm not sure this is really an issue for the hacluster interface. To my 
knowledge, all of the keys used for resources today are strings defining 
the pacemaker resource options (clones, groups, colocation options etc). 
The hacluster charm simply formats crm commands with the name/value 
pairs anyways [0]. It is true that type information is lost, but I don't 
think its an issue for this interface.

[0] - 
https://github.com/openstack/charm-hacluster/blob/master/hooks/hooks.py#L314

>
> This is a hard requirement in the JSON spec:
>
> https://tools.ietf.org/html/rfc7159#section-4
> "An object structure is represented as a pair of curly brackets
> surrounding zero or more name/value pairs (or members).  A name is
> a string. "
>
> I wonder if we could use some type-aware serialization format but I do
> not have any suggestions without trade-offs because we need to keep in
> mind that, in general, charms may not be python charms, may run on
> hosts with different protocol parsing libraries etc.
>
> If we only cared about python I would suggest using "pickle" but this
> is not universal and not human-readable:
>
> https://docs.python.org/3/library/pickle.html#comparison-with-json
> "JSON, by default, can only represent a subset of the Python built-in
> types, and no custom classes; pickle can represent an extremely large
> number of Python types"
>
> JSON has an advantage of being readable as opposed to a binary protocol
> so we can explore what's available in relation data by doing relation-
> get without additional tools. It is also ubiquitous so we don't have to
> worry about spec changes, parsing bugs and other potential problems.
>
> Thanks for bringing this topic up.
>
> Dmitrii Shcherbakov
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev