Jira (HI-482) String literals should literally be literal
Title: Message Title Kyle Harper commented on HI-482 Re: String literals should literally be literal I understand that YAML and JSON don't treat double or single quotes differently; it's all up to hiera as to how the backend data is being interpreted. It's hiera that chose to look at single-quoted strings as interpretative. A common practice with Puppet features that break current conventions is: create a config option, leave the option default set to the current behavior, and monitor feedback and adoption rates. If the argument was that it would be very time consuming and you don't have resources for it, that's one thing. Otherwise, with all due respect, I feel this should get consideration from more than a single person before being shut down because of potential "incompatibilities" that can be completely avoided with a new option in hiera.yaml. A string-literal form is a very basic tenant of interpretive systems, including Puppet DSL. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (HI-482) String literals should literally be literal
Title: Message Title Kyle Harper commented on HI-482 Re: String literals should literally be literal R.I.Pienaar Thanks for the demonstration. Henrik Lindberg I see what you're saying now, and why hiera can't do what I was originally thinking. It might be worth linking this issue on certain documentation pages which discuss Hiera. There's already a note that values must be quoted, and I know some recent updates helped cover the RewriteRule issue by using % {literal('%')} , but it would help edify others to note: 1. Hiera doesn't parse YAML or JSON, ruby does. Therefore Hiera is subject to whatever ruby returns. (Show the example above from R.I.Pienaar). 2. Hiera's interpretations purposely remain simple, only interpreting %{} blocks. Anyway, thanks for all the feedback. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (HI-482) String literals should literally be literal
Title: Message Title Kyle Harper created an issue Hiera / HI-482 String literals should literally be literal Issue Type: Improvement Assignee: Unassigned Created: 2015/11/23 7:21 PM Priority: Normal Reporter: Kyle Harper Hiera treats any quoted string as a candidate for interpolation. This is in contrast to most languages (including Puppet DSL) wherein single-quotes mean a string should be taken literally. With $::environment == production my_key: "My environment is %{::environment}" ==> My environment is production my_key: 'My environment is %{::environment}' ==> My environment is production The latter should evaluate to: ==> My environment is %{::environment} The limited interference of Hiera on the YAML back-end data has prevented this lack of behavior from being a bigger issue; but as Hiera grows over time it's likely this will help users avoid other problems with unintended expressions in data. A current example problem that has been discussed in other tickets ( HI-127 ) was the Apache rewrite rule/cond string. A few unsupported solutions were presented, but the final official response was to use a function: my_key: "RewriteCond % {literal('%')} {REMOTE_HOST} =host1" ==> RewriteCond %{REMOTE_HOST} =host1 While it works, it seems significantly more complex than is necessary; it also has the expense of an entire function call just to place a percent sign. (Not to mentioned we're further mixing code inside data, but that's another issue entirely...). Thanks for your consideration.