Project

General

Profile

Actions

Bug #10088

open

Smart class default parameter interpreted as string

Added by Jérôme Vizcaino about 9 years ago. Updated over 8 years ago.

Status:
New
Priority:
High
Assignee:
-
Category:
Parameters
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

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
  • save
  • 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)


Related issues 1 (0 open1 closed)

Related to Foreman - Bug #8052: Smart class parameters with ERB snippets are broken for other that String typesClosedMarek Hulán10/23/2014Actions
Actions #1

Updated by Dominic Cleal about 9 years ago

  • Category changed from Web Interface to Parameters
Actions #2

Updated by Jérôme Vizcaino about 9 years ago

This is a regression : it worked well using Foreman 1.7.1.

Actions #3

Updated by Dominic Cleal about 9 years ago

  • Related to Bug #8052: Smart class parameters with ERB snippets are broken for other that String types added
Actions #4

Updated by Jan Stillings almost 9 years ago

This is not working in version 1.7.5 and 1.8.2. It is only broken in the Puppet class parameter override while an override on host group or host level works fine.

Actions #5

Updated by Adam S over 8 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.

Actions #6

Updated by Adam S over 8 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.

Actions #7

Updated by larry campbell over 8 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:

- 10.35.179.0

When i create a new host using that host group, the override then appears as such:

--- ! '--- ! "- 10.35.179.0\r\n"

'

Actions #8

Updated by Dominic Cleal over 8 years ago

larry campbell wrote:

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:

I'm fixing this under #11375, as it's a problem with the host override page.

Actions

Also available in: Atom PDF