I'm having a struggle with Smart Class Parameters in Foreman 1.9.2. I have
a Puppet class with many subclasses, the main class has two Array
Parameters which are used to whitelist and blacklist the inclusion of the
subclasses. In Foreman, I found that we needed to override this parameter
to be of an array structure or else Puppet always saw it as a string. So I
used the smart variables to override the parameter type and set a default.
In two different host groups, I override the blacklist parameter, I can
enter the text in the form of an array like so:
Puppet runs fine, things are good. Sometime later, if I happen to click on
host’s edit button, and look at parameters this shows up:
“”[\“foo::bar\”, \“foo::bas\”, \“foo::bat\”,]""
Then looking back at the yaml for the host this is what shows:
classes:
foo:
blacklist: true
With that, the validate_array() call I make in puppet fails. My only
recourse is to wipe the parameter out (in the hostgroup) and type it all
back in. Does anyone have an idea what’s going on here? I’ve poked
through the issues going back to 1.9.0 and am not seeing any relevant issue
subjects.
I'm having similar issues, so you're not alone in this. I override it at
the class level, but if I override any other parameter, it then 'escapes'
the value field as well. I usually have to edit the array ones last to
make them stick.
Hope that helps!
/Mike
···
On Friday, October 2, 2015 at 10:11:42 AM UTC-4, Sean Alderman wrote:
>
> Good morning!
>
> I'm having a struggle with Smart Class Parameters in Foreman 1.9.2. I have
> a Puppet class with many subclasses, the main class has two Array
> Parameters which are used to whitelist and blacklist the inclusion of the
> subclasses. In Foreman, I found that we needed to override this parameter
> to be of an array structure or else Puppet always saw it as a string. So I
> used the smart variables to override the parameter type and set a default.
>
> In two different host groups, I override the blacklist parameter, I can
> enter the text in the form of an array like so:
>
> Hostgroup1:
> [ "foo::bar", "foo::bas", "foo::bat", ]
> Hostgroup2:
> [ "foo::bar", "foo::bat", "foo::bau", ]
>
> Looks good, I click submit, go look at a host in one of those groups and
> see that the yaml looks good...
>
> host1:
> ---
> classes:
> foo:
> blacklist:
> - foo::bar
> - foo::bas
> - foo::bat
>
> Puppet runs fine, things are good. Sometime later, if I happen to click
> on host's edit button, and look at parameters this shows up:
>
> "\"[\\\"foo::bar\\\", \\\"foo::bas\\\", \\\"foo::bat\\\",]\""
>
> Then looking back at the yaml for the host this is what shows:
> ---
> classes:
> foo:
> blacklist: true
>
> With that, the validate_array() call I make in puppet fails. My only
> recourse is to wipe the parameter out (in the hostgroup) and type it all
> back in. Does anyone have an idea what's going on here? I've poked
> through the issues going back to 1.9.0 and am not seeing any relevant issue
> subjects.
>
> Thanks you kindly!
>
>
>
>
>
>
>
>
>
So what are your thoughts here… is this a bug? I can't see making use of
Smart Variables long term if this is "normal" behavior. If there's a
redmine issue on this already, I'd like to upvote it.
···
On Friday, October 2, 2015 at 3:09:26 PM UTC-4, mkb...@solutionsathand.ca wrote:
>
> I'm having similar issues, so you're not alone in this. I override it at
> the class level, but if I override any other parameter, it then 'escapes'
> the value field as well. I usually have to edit the array ones last to
> make them stick.
>
> Hope that helps!
>
> /Mike
>
> On Friday, October 2, 2015 at 10:11:42 AM UTC-4, Sean Alderman wrote:
>>
>> Good morning!
>>
>> I'm having a struggle with Smart Class Parameters in Foreman 1.9.2. I
>> have a Puppet class with many subclasses, the main class has two Array
>> Parameters which are used to whitelist and blacklist the inclusion of the
>> subclasses. In Foreman, I found that we needed to override this parameter
>> to be of an array structure or else Puppet always saw it as a string. So I
>> used the smart variables to override the parameter type and set a default.
>>
>> In two different host groups, I override the blacklist parameter, I can
>> enter the text in the form of an array like so:
>>
>> Hostgroup1:
>> [ "foo::bar", "foo::bas", "foo::bat", ]
>> Hostgroup2:
>> [ "foo::bar", "foo::bat", "foo::bau", ]
>>
>> Looks good, I click submit, go look at a host in one of those groups and
>> see that the yaml looks good...
>>
>> host1:
>> ---
>> classes:
>> foo:
>> blacklist:
>> - foo::bar
>> - foo::bas
>> - foo::bat
>>
>> Puppet runs fine, things are good. Sometime later, if I happen to click
>> on host's edit button, and look at parameters this shows up:
>>
>> "\"[\\\"foo::bar\\\", \\\"foo::bas\\\", \\\"foo::bat\\\",]\""
>>
>> Then looking back at the yaml for the host this is what shows:
>> ---
>> classes:
>> foo:
>> blacklist: true
>>
>> With that, the validate_array() call I make in puppet fails. My only
>> recourse is to wipe the parameter out (in the hostgroup) and type it all
>> back in. Does anyone have an idea what's going on here? I've poked
>> through the issues going back to 1.9.0 and am not seeing any relevant issue
>> subjects.
>>
>> Thanks you kindly!
>>
>>
>>
>>
>>
>>
>>
>>
>>
This is definitely a bug. I'm experiencing it in 1.9.2 as well. In my case,
I found that it occurs on the class level when using erb template values,
but could not replicate it on the host level or in a second-level hostgroup
(e.g. foo/bar)
Enter code here…
[<%=@host.name %>]
This gets quotes added repeatedly each time I edit and then click submit on
the class (without changing anything). It will then resolve as true when
passed to puppet instead of an array.
Yes, the problems all sound like they come from this bug which has just
been fixed in nightlies.
As per my latest comment on the ticket, I'm not sure if it can be
backported easily to 1.9, and whether it fixes the issue there or adds
new ones. I'll try and look if I get the opportunity.
···
On 06/10/15 00:34, Alyssa wrote:
> This is definitely a bug. I'm experiencing it in 1.9.2 as well. In my
> case, I found that it occurs on the class level when using erb template
> values, but could not replicate it on the host level or in a
> second-level hostgroup (e.g. foo/bar)
>
> >
> Entercode here...
> [<%=@host.name %>]
> >
>
>
> This gets quotes added repeatedly each time I edit and then click submit
> on the class (without changing anything). It will then resolve as true
> when passed to puppet instead of an array.
>
> It looks fairly similar to http://projects.theforeman.org/issues/11375
Thanks for taking a look, Dominic. I was ready to push out the upgrade from
our lab to production when I noticed this, but the upgrade is on hold for
now, as it doesn't seem like something I can realistically have users take
into consideration when modifying classes.
···
On Tuesday, October 6, 2015 at 2:30:24 AM UTC-7, Dominic Cleal wrote:
>
> On 06/10/15 00:34, Alyssa wrote:
> > This is definitely a bug. I'm experiencing it in 1.9.2 as well. In my
> > case, I found that it occurs on the class level when using erb template
> > values, but could not replicate it on the host level or in a
> > second-level hostgroup (e.g. foo/bar)
> >
> > >
> > Entercode here...
> > [<%=@host.name %>]
> > >
> >
> >
> > This gets quotes added repeatedly each time I edit and then click submit
> > on the class (without changing anything). It will then resolve as true
> > when passed to puppet instead of an array.
> >
> > It looks fairly similar to http://projects.theforeman.org/issues/11375
>
> Yes, the problems all sound like they come from this bug which has just
> been fixed in nightlies.
>
> As per my latest comment on the ticket, I'm not sure if it can be
> backported easily to 1.9, and whether it fixes the issue there or adds
> new ones. I'll try and look if I get the opportunity.
>
> --
> Dominic Cleal
> dom...@cleal.org
>
Oh, I perhaps didn't follow your issue description fully. I'm not sure
that my change will affect editing of classes, only editing of overrides
through hosts and host groups - it's possible that the issue you're
seeing is different to Sean's.
Could you give it a try on a nightly build and file a new bug if
present? I'm not able to reproduce it with an array parameter.
···
On 06/10/15 22:26, Alyssa wrote:
> Thanks for taking a look, Dominic. I was ready to push out the upgrade
> from our lab to production when I noticed this, but the upgrade is on
> hold for now, as it doesn't seem like something I can realistically have
> users take into consideration when modifying classes.
Thanks for the follow-up, Dominic. I installed the nightly with a default
foreman-installer setup, and the problem behavior still shows up. I've
filed a bug with screenshots at: Bug #12095: Smart Class Parameters mangle erb interpolated variables - Foreman
Let me know if I can be of any assistance! I'm very eager to get this
upgrade pushed out.
···
On Wednesday, October 7, 2015 at 1:03:26 AM UTC-7, Dominic Cleal wrote:
>
> On 06/10/15 22:26, Alyssa wrote:
> > Thanks for taking a look, Dominic. I was ready to push out the upgrade
> > from our lab to production when I noticed this, but the upgrade is on
> > hold for now, as it doesn't seem like something I can realistically have
> > users take into consideration when modifying classes.
>
> Oh, I perhaps didn't follow your issue description fully. I'm not sure
> that my change will affect editing of classes, only editing of overrides
> through hosts and host groups - it's possible that the issue you're
> seeing is different to Sean's.
>
> Could you give it a try on a nightly build and file a new bug if
> present? I'm not able to reproduce it with an array parameter.
>
> --
> Dominic Cleal
> dom...@cleal.org
>
