Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Element getTree convert functions for each TYPE #51

Merged
merged 16 commits into from May 3, 2015

Conversation

stdweird
Copy link
Member

@stdweird stdweird commented Apr 3, 2015

Simplifies generation of configfiles by allowing to convert e.g. all booleans to the strings 'YES' / 'NO', or add quotes around the strings; when the values are retrieved via getTree.
It also allows to e.g. create JSON output corresponding with the original types (e.g. the original JSON profile from the database) when json_typed is enabled.

@stdweird stdweird changed the title Support Elment getTree convert functions for each TYPE Support Element getTree convert functions for each TYPE Apr 3, 2015
@hpcugentbot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/CCM-pr-builder/105/
Test PASSed.

@stdweird
Copy link
Member Author

stdweird commented Apr 3, 2015

This PR modifies the default internal representation, so anyone using typed_json or xml and e.g. metaconfig with json or yaml module will endup with different (but more "correct") output.
@ned21 @gombasg since MS is using xml, care to comment on the impact of this?

@jrha
Copy link
Member

jrha commented Apr 7, 2015

What would be the before and after for those using xml?

@stdweird
Copy link
Member Author

stdweird commented Apr 7, 2015

xml already has typed data, and with this PR long and double are actually long and double (instead of string) when using e.g. metaconfig json and yaml (because of the ::XS bits).

@jrha
Copy link
Member

jrha commented Apr 7, 2015

What I meant was, when you said this...

anyone using typed_json or xml and e.g. metaconfig with json or yaml module will endup with different (but more "correct") output.

How would the change in output manifest? I assume like this...

Before After
"dave" : "false" "dave" : false
"spam" : "42" "spam" : 42
"eggs" : "tasty" "eggs" : "tasty"
"tau" : "6.283185" "tau" : 6.283185

@jrha jrha added this to the 15.4 milestone Apr 7, 2015
@stdweird
Copy link
Member Author

stdweird commented Apr 7, 2015

yes. something like that; except for the false example; which would now be 0, which is sometimes is false, sometimes a parse error 😄 "false" is always true in yaml or json. now the pan boolean false can be yaml false or JSON False if you used typed CCM (like xml or typed json).
one of the unittests generates the original JSON profile from the CCM DB as a fun exercise, but we have secrives like cassandra or elasticssearch that use yaml as config file format and do not like quoted strings for integers.
and this is only for YAML::XS and JSON::XS afaik, none of our other components care about the perl internal representation when generating output.

@jrha
Copy link
Member

jrha commented Apr 7, 2015

😖

Pan false → Written JSON "false" →Read as JSON true

Therefore false == true.

last SWITCH;
};

# Default clause
# Default clause, should never be reached
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Famous last words.

If it should never be reached, why not log an error?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because there's no logger here, only throw_error. i don't mind throwing it, but others might disagree
@ned21 toughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Throwing an error is generally good but it means that if PAN ever introduces a new data type then data type cannot be used until the node's CCM library is updated to know about it. That's not too unreasonable except that it looks like the current code would handle new types that mapped to Perl scalars just fine anyway, so is the error actually adding any value?

I would be inclined to update the comment instead of throwing an error, e.g. "Default clause: should only be reached if PAN adds a new type which is not explicitly checked above."

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, updating the comment would be a good idea.

@hpcugentbot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/CCM-pr-builder/107/
Test FAILed.

@stdweird
Copy link
Member Author

requires quattor/CAF#87

@stdweird
Copy link
Member Author

@jrha depends, if you use getTree like ncm-metaconfig does, pan false -> JSON false -> 0 (even without JSON typed support) (but then pan 0 -> json 0 -> possibly "0" (which is true); and also for xml)
anyway, we need a plan to switch to typed json as default, and then merge some more PRs and all is fine again. easy peasy 😄

@hpcugentbot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/CCM-pr-builder/108/
Test FAILed.

@hpcugentbot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/CCM-pr-builder/109/
Test FAILed.

@hpcugentbot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/CCM-pr-builder/110/
Test FAILed.

@hpcugentbot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/CCM-pr-builder/111/
Test FAILed.

@hpcugentbot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/CCM-pr-builder/112/
Test FAILed.

@hpcugentbot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/CCM-pr-builder/113/
Test FAILed.

@stdweird
Copy link
Member Author

the new is_long and is_double vmethods only work with typed json and xml; is_boolean works with regular json.

@stdweird
Copy link
Member Author

@jrha this PR got a bit out of hand, but it's a huge improvement: correct data representation in XS modules like YAML and JSON; and type checking in TT (no more static lists in the TT files of what is a boolean and what not).
what is currently missing is path support; but i don't know why you'd want that yet.
i'll document the new features in the tutorial.

@jrha
Copy link
Member

jrha commented Apr 27, 2015

retest this please

@hpcugentbot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/CCM-pr-builder/114/
Test PASSed.

@jrha
Copy link
Member

jrha commented Apr 27, 2015

Ok, I'm happy with this.
Does anyone from MS (@ned21, @gombasg) have any comments?

@ned21
Copy link
Contributor

ned21 commented Apr 28, 2015

I agree that in theory this is an improvement, and cannot think of any practical concerns/challenges off hand. Let's give @gombasg chance to reply too. Since this has potentially unknown impact please make sure this is called out in the release notes as a major change so people are aware and can test for problems.

@stdweird
Copy link
Member Author

@ned21 this is not only "in theory", we have services that require correct YAML; correct JSON will be useful for ncm-query --format json, but other non-XS/pure-perl output should indeed not be affected.
if you are in doubt, we could enable it via one of the convert methods (and not do anything by default as it was before). it's easy now since there's support for multiple convert methods per type.
then this casting is all moved to usage of CCM::TextRender; and will only affect metaconfig (and even there, only limited to eg yaml or json module).

@ned21
Copy link
Contributor

ned21 commented Apr 29, 2015

This seems to offer a benefit to being default, so it would be nice to be enable it as the default--how confident are we that it won't break anything? We can't be afraid to make major changes just because they carry some small risk, but effective communication especially via the release notes can mitigate that risk.

@jrha
Copy link
Member

jrha commented Apr 29, 2015

Yes this should be the default. I don't see why it should be optional, the current behaviour is effectively a bug, if it causes problems with configuration then those problems should be fixed rather than the current behaviour being preserved.

I will make sure that this change is in big bold text in the release notes. 😄

@stdweird
Copy link
Member Author

i'm working on some patches that gives the benefits without changing the defaults. then we don't have to take risks and keep the benefits (the default will shift to usage of CCM::TextRender)

@hpcugentbot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/CCM-pr-builder/115/
Test PASSed.

@stdweird
Copy link
Member Author

@jrha @ned21 the old defaults are back, no loss of functionality

@jrha
Copy link
Member

jrha commented Apr 29, 2015

Ok, waiting for signoff from @gombasg.

@hpcugentbot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/CCM-pr-builder/116/
Test PASSed.

ned21 added a commit that referenced this pull request May 3, 2015
Support Element getTree convert functions for each TYPE
@ned21 ned21 merged commit 50767a6 into quattor:master May 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants