Smart class default parameter interpreted as string
How to reproduce this :
- override a puppet class parameter
- set the default value as a Hash (JSON or YAML seem to be impacted too)
- enter a valid YAML containing ERB
- go back to the puppet class and select the parameter
- the parameter is displayed as a string !
It seems to be related to how the backend formats the text field, because when looking at the host parameter (YAML button on host page), the document content is valid (ie. parameter appears as a hash, not a string)
#5 Updated by Adam S over 3 years ago
I'll second this, not working in 1.8.2. I'm finding thought that it's also broken in host group. Only host level works.
Technically you can put your ERB into Puppet classes or Host Group and it does translate in the backend on a client YAML properly, but visually it shows: --- "hostname: <%= @host.name %>" : in the parameter field when viewing on any of Puppet classes, Hostgroup or Host that inherits any of those.
The biggest issue to this is that if we then hit override on a client and either don't modify it at all or, rather than modify it back to proper YAML, just change one value in the stringified YAML, then it breaks it completely and on the Host's YAML it would now just say: true : rather than the actual proper breakdown of separate parameters like we requested in the YAML.
So really, only the Host is able to submit the YAML with ERB in it and have it submit and save visually AND functionally.
The hostgroup and Puppet classes smart parameter can only enter YAML with ERB and have it work functionally to the point of working without supporting overrides.
Really unfortunately broken for any real use where we want to use <%= @host.facts['...'] %> or anything else that would be completely great in Foreman.
#6 Updated by Adam S over 3 years ago
I realized one minor difference actually in Host Group containing YAML with ERB. It does! display properly when submitted unlike how I initially said that it doesn't but it still doesn't show properly in overrides for sub Host Groups or sub Hosts, which, in effect, means that overriding in sub groups and hosts is a PITA because you need to rewrite it all as proper YAML before resubmitting with your change.
#7 Updated by larry campbell over 3 years ago
I'm noticing the similar behavior with non-ERB data. For instance: in my host group I have a puppet parameter override with a YAML list like this:
When i create a new host using that host group, the override then appears as such:
--- ! '--- ! "- 10.35.179.0\r\n"