Hammer CLI

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.

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.

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.

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

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.

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.

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.

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?