Project

General

Profile

Bug #23789

hammer sc-param setting Type

Added by Stephen Cooke about 2 years ago. Updated 11 months ago.

Status:
Resolved
Priority:
Normal
Category:
Smart variables
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Team Backlog:
Fixed in Releases:
Found in Releases:
In Kanboard:

Description

hammer sc-param info --id 1759
Id: 1759
Parameter: latest
Default Value: false
Override: true
Puppet class: yum::client
Description:
Type: string

I am having trouble getting true/false values set using hammer sc-param

The values are going in as strings with ["true"] and not just "true"

can someone explain where the [" "] is coming from please. as this is causing Boolean validation to fail when updating the class

I need to get hammer to add TYPE=Boolean , how is this done please?

class myclass (
Boolean $myvar = true
) {
....some stuff
}

History

#1 Updated by Tomáš Strachota about 2 years ago

  • Category set to Smart variables

#2 Updated by Martin Bacovsky about 2 years ago

  • Status changed from New to Need more information

Stephen, could you please include version of Foreman and Puppet you are using?

Do I understand it correctly that the smart class parameter was imported with incorrect type? (string instead of boolean)

#3 Updated by Stephen Cooke about 2 years ago

Martin Bacovsky wrote:

Stephen, could you please include version of Foreman and Puppet you are using?

Do I understand it correctly that the smart class parameter was imported with incorrect type? (string instead of boolean)

I have spent a number of hours re-init my whole lab on this to confirm where the issue is. so far i know puppet3 and foreman work great and values stay as true false and you can set either as a default via puppet with inherit being followed.

with puppet3 no casting of values exists and everything is mostly a string, foreman 1.15 thinks its a string and writes true or false
move to puppet5 and we have a new ball game.

Some pain this is causing me! I can not progress an upgrade of a large system until a resolve why puppet5/foreman.1.16 and/above fail to set true or false via HAMMER-CLI interface. If you use the GUI to adjust the values it lets you set them as true false. if u do it via hammer you get ["true"] ["false"] WHY, this is breaking things for me in a big way. so I cant get round it with I am checking in class if $x =~ Boolean , then $my_x = str2bool($x) not found a solution yet. some one elses input needed.

#4 Updated by Stephen Cooke about 2 years ago

How can I send u screen shots of the two different values given from foreman1.15/puppet3.8.7(future parser) and foreman1.16/puppet5.x

I am keen to resolve this and if 1.17 has this fixed please say so and I can re-start testing on that release.

#5 Updated by Stephen Cooke about 2 years ago

Looking a the data a lot, it seems hammer-CLI when datatype is a string actually sends an array! "true" ["true"] this can be fixed vi the webconsole manually, but if u have a few of them then this is a big pain.

can u fix this now i have broken it down to why string type hammer is sending an array not a string.

#6 Updated by Stephen Cooke about 2 years ago

Martin Bacovsky wrote:

Stephen, could you please include version of Foreman and Puppet you are using?

Do I understand it correctly that the smart class parameter was imported with incorrect type? (string instead of boolean)

I am refactoring my lab to use foreman1.17(might as well, 1.16 and hammer-cli got issues)

If a field type is string, hammer-cli will add an extra ["VAR"[ basically an array of one element(not the same as a string), which I understand to mean value is an array(['sdasd','asdasd']

We be re-testing today against 1.17

#7 Updated by Stephen Cooke about 2 years ago

Just installed foreman1.17/hammer_cli_foreman (0.12.0)and ran an import

Checking the value provided in the GUI for a variable(uncast) then was set to false in the puppet class.

example
class my (
$var = false
) {
stuff
}

not surprisingly this has imported as a string of value false.

from the hammer-cli the override values are still going in as arrays of one element ["true"] and just a bare string.
["true"], then can then be editted back to normal in the web GUI. however such a manual workaround is very painful on a large system.

#8 Updated by Martin Bacovsky about 2 years ago

The fix for the situation will land in hammer-cli-foreman 0.13 which will be included in foreman 1.18. You can update your hammer-cli-foreman 0.12 with build of 0.13 from nightlies:

yum install http://koji.katello.org/kojifiles/packages/tfm-rubygem-hammer_cli_foreman/0.13.pre.develop/1.201804131135git0d5ab8c.el7/noarch/tfm-rubygem-hammer_cli_foreman-0.13.pre.develop-1.201804131135git0d5ab8c.el7.noarch.rpm

That fixed the issue for me. The parameter types are still not recognized properly (tracked elsewhere) though hammer does not convert the values to arrays anymore. Worth noting is that sc-param add-override-value was renamed to sc-param add-matcher.

#9 Updated by Stephen Cooke about 2 years ago

Martin Bacovsky wrote:

The fix for the situation will land in hammer-cli-foreman 0.13 which will be included in foreman 1.18. You can update your hammer-cli-foreman 0.12 with build of 0.13 from nightlies:

yum install http://koji.katello.org/kojifiles/packages/tfm-rubygem-hammer_cli_foreman/0.13.pre.develop/1.201804131135git0d5ab8c.el7/noarch/tfm-rubygem-hammer_cli_foreman-0.13.pre.develop-1.201804131135git0d5ab8c.el7.noarch.rpm

That fixed the issue for me. The parameter types are still not recognized properly (tracked elsewhere) though hammer does not convert the values to arrays anymore. Worth noting is that sc-param add-override-value was renamed to sc-param add-matcher.

Thanks for the feedback, I noticed the warnings around add-override-value, that didnt exist in 1.16

As with most I still have to support a puppet3 install for now and the plan is to start to deploy puppet5 instead once this datatype issues are resolved. will hammer 0.13 be getting forward posted into 1.17. As while the issue is fixed am not sure I want to a prod system from nightly builds( my dev version is ok to confirm it fixes it) just any release for prod must come from a stock release.

many thanks for the input.

#10 Updated by Stephen Cooke about 2 years ago

HAM_CLI_RPM="http://koji.katello.org/kojifiles/packages/tfm-rubygem-hammer_cli/0.13.0/1.201805171544gitf2ae97a.el7/noarch/tfm-rubygem-hammer_cli-0.13.0-1.201805171544gitf2ae97a.el7.noarch.rpm"
HAM_RPM="http://koji.katello.org/kojifiles/packages/tfm-rubygem-hammer_cli_foreman/0.13.pre.develop/1.201804131135git0d5ab8c.el7/noarch/tfm-rubygem-hammer_cli_foreman-0.13.pre.develop-1.201804131135git0d5ab8c.el7.noarch.rpm"

yum install $HAM_CLI_RPM
yum install $HAM_RPM

i can confirm that on foreman 1.17 using the above RPM's fixes the issue around hammer-cli writing Arrays instead of strings/Booleans.

Can these be included in the next minor release for 1.17, how do I vote to make this happen?

#11 Updated by Martin Bacovsky about 2 years ago

  • Legacy Backlogs Release (now unused) set to 342
  • Assignee set to Martin Bacovsky
  • Status changed from Need more information to Pending

Thanks for testing this. The fix will be included in hammer-cli-foreman 0.12.1 which will land in the Foreman repos with 1.17.2 at the latest.

#12 Updated by Martin Bacovsky 11 months ago

  • Triaged set to No
  • Status changed from Pending to Resolved

Also available in: Atom PDF