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
Conversation
…upport for additional manipulations based on TYPE
Refer to this link for build results (access rights to CI server needed): |
What would be the before and after for those using xml? |
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 |
What I meant was, when you said this...
How would the change in output manifest? I assume like this...
|
yes. something like that; except for the false example; which would now be |
😖 Pan false → Written JSON "false" →Read as JSON true Therefore false == true. |
last SWITCH; | ||
}; | ||
|
||
# Default clause | ||
# Default clause, should never be reached |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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."
There was a problem hiding this comment.
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.
…P4::CCM::Element support
Refer to this link for build results (access rights to CI server needed): |
requires quattor/CAF#87 |
@jrha depends, if you use |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
…type information from within TT files
…/double/long types
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
the new |
@jrha this PR got a bit out of hand, but it's a huge improvement: correct data representation in |
retest this please |
Refer to this link for build results (access rights to CI server needed): |
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. |
@ned21 this is not only "in theory", we have services that require correct YAML; correct JSON will be useful for |
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. |
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. 😄 |
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 |
Refer to this link for build results (access rights to CI server needed): |
Ok, waiting for signoff from @gombasg. |
Refer to this link for build results (access rights to CI server needed): |
Support Element getTree convert functions for each TYPE
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.