Bug 1335847

Summary: Smart Class Variable not being honored
Product: Red Hat Satellite Reporter: Jim Lyle <jlyle>
Component: ProvisioningAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED DUPLICATE QA Contact: Katello QA List <katello-qa-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: UnspecifiedCC: bbuckingham, bkearney, orabin
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-29 17:59:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jim Lyle 2016-05-13 11:34:13 UTC 
Description of problem:
Overriding a puppet class with a smart class variable based on a boolean validation fails.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
Expect to see the smart class variable be honored for boolean = false to not run a specific puppet configuration change to the resolv.conf file based on the matcher value name ~ ls* however the client data json shows that it is being set to true still for that specific host even thought the Name value is correct in the json.


system.pp:
   if $enable_resolv_conf {
     file { '/etc/resolv.conf':
      ensure  => file,
      mode    => '0640',
      owner   => 'root',
      group   => 'root',
      content  => template('c2s/resolv.conf.erb'),
      }
 }


init.pp:
  $enable_resolv_conf                     = $c2s::params::enable_resolv_conf,
  validate_bool($enable_resolv_conf)

params.pp:
   $enable_resolv_conf = true


Smart Variable set to boolean, default value true using puppet default, and matcher name ~ ls* set to false.
Actual results:


Expected results:
Wildcard to be honored
Comment 3 Bryan Kearney 2016-05-29 17:59:50 UTC 

*** This bug has been marked as a duplicate of bug 1132453 ***