Hi James,
I like option 2 but I think there is a problem with it. I don't
think the hacluster charm sets any data down the relation with the
principle until it has first received data from the principle. As I
understand it option 2 would change this behaviour so that hacluster
immediately sets
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
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}]
This is a hard requirement in the JSON spec:
https://tools.ietf.org/html/rfc7159#section-4
"An
Hi Team
Whilst working on migrating to using Python 3 as the default charm
execution environment, I've hit upon a snag with presentation of data from
principle charms to the hacluster subordinate charm.
Specifically the data presented on the relation is simple str
representation of python dicts
