tickets | 1 Mar 06:40 2012

[Puppet - Bug #4328] modifying user fails if user is logged in

Issue #4328 has been updated by Thomas Sturm.
  • Assignee changed from Thomas Sturm to Nigel Kersten
  • Affected Puppet version changed from 0.25.5 to 2.7.6

We found a workaround now, but the problem still exists in 2.7.6.

Bug #4328: modifying user fails if user is logged in

  • Author: Klavs Klavsen
  • Status: Needs More Information
  • Priority: Normal
  • Assignee: Nigel Kersten
  • Category:
  • Target version:
  • Affected Puppet version: 2.7.6
  • Keywords:
  • Branch:

Just noticed (on Ubuntu 10.04 – probably valid for more OS'es) – that puppet failed to change a users homedir (the nagios user in this case) – and usermod failed to do so, because the user was logged in (the nrpe service was running).

To fix this, one way would be to have a “pre-exec” and “post-exec” hook – which in this case, would be to stop and start the relevant service. or perhaps some “obstruction” parameter – where one could define the Service[“nrpe”] as an obstruction (which would mean puppet would stop it before and start it again after – if it was indeed stopped by puppet beforehand).

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

tickets | 1 Mar 08:35 2012

[Puppet - Bug #12904] (Unreviewed) Deprecation warning about var not being fully qualified, yet it is local to scope of block in ERB

Issue #12904 has been reported by Joe McDonagh.

Bug #12904: Deprecation warning about var not being fully qualified, yet it is local to scope of block in ERB

  • Author: Joe McDonagh
  • Status: Unreviewed
  • Priority: Normal
  • Assignee:
  • Category:
  • Target version:
  • Affected Puppet version:
  • Keywords:
  • Branch:

Take this code example:

` <% scope.function_getinfo(‘Class’, ‘berkleemedia::lpm’, ‘fqdn’).each do |host| –%>

BalancerMember http://<%= host -%> retry=1

<% end –%>

ProxySet lbmethod=byrequests SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1

`

I’m getting deprecations warnings that “host” isn’t fully qualified, which is really weird since its scope is just in that block. Not sure if this matters but here is the custom function getinfo code:

` require ‘puppet/rails’ require ‘puppet/rails/fact_value’

module Puppet::Parser::Functions newfunction(:getinfo, :type => :rvalue, :doc => “This is a function that will return an array of information based on what you ask for. For example this call:

getinfo('Class', 'httpd', 'ec2_public_ipv4')

will return a list of the ec2_public_ipv4 fact values for any node that has the resource Class[‘httpd’]. If you leave off the third argument, fqdn will be assumed. Also note you can pass an environment to this function, but likely you won’t need to because by default it will find the node’s environment and use that. “) do |args|

resource_type = args[0] resource_title = args[1] return_info = args[2] environment = args[3] return_info ||= "fqdn" environment ||= lookupvar("::environment") raise Puppet::ParseError, ("getinfo(): wrong number of arguments (#{args.length}; must be >= 2)") if args.length < 2 info = [ ] info = Puppet::Rails::FactValue.find_by_sql(" SELECT fv.value from fact_values fv, fact_names fn, resources r, hosts h WHERE fn.name = '#{return_info}' AND h.environment = '#{environment}' AND h.id = r.host_id AND r.restype = '#{resource_type}' AND r.title = '#{resource_title}' AND fv.host_id = h.id AND fv.fact_name_id = fn.id; ") info.map! { |i| i.value } info

end end

`

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

tickets | 1 Mar 08:36 2012

[Puppet - Bug #12904] Deprecation warning about var not being fully qualified, yet it is local to scope of block in ERB

Issue #12904 has been updated by Joe McDonagh.

    Sorry for the formatting stuff being screwy, it looked like I did the tags right so IDK

    Bug #12904: Deprecation warning about var not being fully qualified, yet it is local to scope of block in ERB

    • Author: Joe McDonagh
    • Status: Unreviewed
    • Priority: Normal
    • Assignee:
    • Category:
    • Target version:
    • Affected Puppet version:
    • Keywords:
    • Branch:

    Take this code example:

    ` <% scope.function_getinfo(‘Class’, ‘berkleemedia::lpm’, ‘fqdn’).each do |host| –%>

    BalancerMember http://<%= host -%> retry=1

    <% end –%>

    ProxySet lbmethod=byrequests SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1

    `

    I’m getting deprecations warnings that “host” isn’t fully qualified, which is really weird since its scope is just in that block. Not sure if this matters but here is the custom function getinfo code:

    ` require ‘puppet/rails’ require ‘puppet/rails/fact_value’

    module Puppet::Parser::Functions newfunction(:getinfo, :type => :rvalue, :doc => “This is a function that will return an array of information based on what you ask for. For example this call:

    getinfo('Class', 'httpd', 'ec2_public_ipv4')

    will return a list of the ec2_public_ipv4 fact values for any node that has the resource Class[‘httpd’]. If you leave off the third argument, fqdn will be assumed. Also note you can pass an environment to this function, but likely you won’t need to because by default it will find the node’s environment and use that. “) do |args|

    resource_type = args[0] resource_title = args[1] return_info = args[2] environment = args[3] return_info ||= "fqdn" environment ||= lookupvar("::environment") raise Puppet::ParseError, ("getinfo(): wrong number of arguments (#{args.length}; must be >= 2)") if args.length < 2 info = [ ] info = Puppet::Rails::FactValue.find_by_sql(" SELECT fv.value from fact_values fv, fact_names fn, resources r, hosts h WHERE fn.name = '#{return_info}' AND h.environment = '#{environment}' AND h.id = r.host_id AND r.restype = '#{resource_type}' AND r.title = '#{resource_title}' AND fv.host_id = h.id AND fv.fact_name_id = fn.id; ") info.map! { |i| i.value } info

    end end

    `

    You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

    --
    You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
    To post to this group, send email to puppet-bugs <at> googlegroups.com.
    To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

    tickets | 1 Mar 11:59 2012

    'Puppet Ubuntu' wiki page has been updated

    The 'Puppet Ubuntu' wiki page has been updated by Martijn Heemels.
    Changed repo URL's to new repo structure. Using the old one causes lots of delays due to 302 redirects.

    View differences:
    https://projects.puppetlabs.com/projects/puppet/wiki/Puppet_Ubuntu/diff/7

    You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

    --
    You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
    To post to this group, send email to puppet-bugs <at> googlegroups.com.
    To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

    tickets | 1 Mar 13:01 2012

    [Puppet - Feature #11915] Segregate client facts, server facts and ENC params in topscope hashes

    Issue #11915 has been updated by R.I. Pienaar.

      Daniel Pittman wrote:

      Nigel Kersten wrote:

      I haven’t seen use cases for exposing server facts to the manifests, but there are certainly a few cases for the server settings.

      What are those, please? Several people have indicated that they are useful, and nobody can tell us what those cases are. If we can get the story from a user who wants to do that, we can absolutely support it, but without it …

      I’ve never found a use for them either. Here are some I’ve seen in #puppet based on a search through my logs

      • template() doesnt work like source which is what people want. So people hack around this by referencing $settings::modulepath with file()
      • scripts that interact with the exported resources database, someone wrote the config file for that based on $settings::dbpassword etc
      • while generating mcollective facts.yaml they use $settings::dynamicfacts to exclude the variables that changes all the time
      • they want to place files into the puppet config dir when managing puppet master using puppet so $settings::configdir is a good variable to have
      • testing infrastructure that check puppet code might run the manifests in a odd place so people want to find $settings::manifestdir to base checks off. Don’t really get what this guy was doing, suspect its related to the first point
      • someone wanted to know if pluginsync is enabled, presumably to figure out if they can use some custom type.
      • they want to configure the puppet.conf of the master using a template and want to use these variables there…thats just a terrible idea

      And thats every time that variable ever came up in #puppet since its release. Nothing of this sounds like something we cant do without and most of them sounds like people working around other deficiencies or design issues.

      Daniel, can you elaborate on this?

      “facts are dynamic, as they were in earlier versions.” Even with the plans to remove dynamic scoping in Telly?

      Absolutely. I am specifically suggesting that facts and variables are different things, and can have different rules. Facts should have “dynamic” scope – <at> factname – that are available everywhere. Variables should have lexical scope.

      I’m not convinced it makes sense for facts to have a special syntax compared to variables, but I can see the attraction. I’d love to see more people weigh in on that point.

      It is my view that facts should have a special syntax, and special behaviour, because they are the single most commonly accessed data in the system. They are universal things that most every part of the tree – manifests in modules you install, for example – want to reference.

      I agree.

      More though I think special syntax tells you when reading code that what is required is a fact about the system and not someting else. This is important information to know when evaluating code. Having special syntax means thats obvious. It’s important that the syntax we choose is also obvious in templates and not too far from each other. $::foo vs scope.lookupvar(“::foo”) is an example of where the disconnect is too big. $facts[“foo”] vs <at> facts[“foo”] maybe not.

      Having them in a hash aids discovery of information, there are legit reasons to ask “what are all the facts for the node I am compiling” having a hash rather than a series of variables that you cant iterate using something like keys() means that’s something thats doable vs just outright a pain.

      We seem to have a number of special types of variables here:

      • facts
      • settings
      • global variables such as those set in site.pp or provided by a ENC
      • server facts
      • node level variables
      • variables passed in via paramters such as parameters to a define or class

      If we wanted to call more than one of these out in some way to donate their specialness I think we’d be better served by hash dynamics than just something like *variable is a fact while %variable is a server settings. that would be too confusing to new users and too alien for people coming from other systems.

      Hashes are a universal concept even in bash scripts. I think it would be very obvious for any newcomer to know what $facts[“foo”] means once the concept of a fact has been explained, but something like *foo will just forever increase the confusion around the language

      I’d specifically disagree with the statement that hash syntax is “awfully heavy” especially in the context of that very same syntax being something many people already know and would feel comfortable with. A specific example of this is the $settings::foo syntax which is alien to everyone and people are just not remembering how it works. We do have hashes in the language they’re widely used and understood and serves the purpose of storing all facts well.

      Combine with this that data in hiera will be a hash using JSON hash syntax, nested facts will be a hash using ruby hash syntax and retrievable on the command line using something that approximates ‘pp’ or a hash or a simple JSON dump. Mcollective is all about hashes and displays output in JSON representation of a hash, and has tooling around selecting/searching/interacting with hashes. I’d say that hashes are pretty heavily entrenched in our world and will not go away, so rather than add more types of hash like syntax – or finding ways to avoid them where they make sense to people familiar with programming languages – we should just embrace hashes.

      I’d be interested to see a main stream language that went with the conclusion that hash like syntax is too much of a burdon and came up with an alternative approach though. I would not want to see Puppet as the only or one of a very small handful that went down that route though.

      Feature #11915: Segregate client facts, server facts and ENC params in topscope hashes

      • Author: Brice Figureau
      • Status: Needs Decision
      • Priority: Normal
      • Assignee: Randall Hansen
      • Category: language
      • Target version:
      • Affected Puppet version: 2.7.9
      • Keywords: scope facts lookup hash
      • Branch:

      Having to use $operatingsystem (and soon $::operatingsystem) in our manifests is:

      • confusing for new users
      • prone to name-clashing

      Those variables are really specific in Puppet because they come from the exterior.

      My proposal would be to move them to separate Puppet hashes of names:

      • $facts
      • $server_facts
      • $parameters

      So usage would be:

      ... firewall { "http": protocol => "TCP", src => $facts['ipaddress'] } file { "/etc/issue.net": content => "This host is in ${server_facts['environment']} environment" } ...

      We could also have some custom methods in the template wrappers so accessing facts in templates could be even easiers, like facts['ipaddress'].

      Of course to help migrate users, the first release would also put the facts/server facts and parameters in the node top scope (and issue a deprecation warning on lookup).

      You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

      --
      You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
      To post to this group, send email to puppet-bugs <at> googlegroups.com.
      To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
      For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

      tickets | 1 Mar 13:02 2012

      [Puppet - Bug #12835] Cisco device, interface type, ensure => absent won't work properly.... I think

      Issue #12835 has been updated by Gary Richards.
      • File 12835.patch added

      Ok, the fix for this seems surprisingly simple, patch attached.

      I assume the idea in this line of code was to default resources[:ensure] default to :present (which is what the type says).

      So i’ve simply made it take that into account, if resources[:ensure] is nil, then set it to :present, rather than always setting it to :present.

      I’ve still not managed to test against a Cisco device yet. But it solves the problem for my HP code. I’m still trying to get access to a Cisco device to try it against.

      Bug #12835: Cisco device, interface type, ensure => absent won't work properly.... I think

      • Author: Gary Richards
      • Status: Accepted
      • Priority: Normal
      • Assignee:
      • Category: device
      • Target version:
      • Affected Puppet version: 2.7.10
      • Keywords:
      • Branch:

      Hi,

      I’ve been working on modifying the Cisco device code to work with Hp devices.

      I started out fairly simple with just being able to define a vlan and the basic parts of an interface.

      Some real simple testing suggested that defining an interface like so:

      interface { '1': ensure => absent }

      Although I detect (correctly) that the interface is disabled, every time puppet runs it always tries to set the interface as disabled. My code isn’t too much different to the existing cisco code. I can’t test this against a cisco device, but I think it would fail there too for the following reason:

      The parse_interface method in util/network_device/cisco/device.rb:

      def parse_interface(name) resource = {} ... if l =~ /#{name} is (.+), line protocol is / resource[:ensure] = ($1 == 'up' ? :present : :absent); end ... resource end

      So whatever happens it always returns something, even if that’s an empty hash.

      If we look at self.prefetch(resources) in provider/network_device.rb

      def self.prefetch(resources) resources.each do |name, resource| device = Puppet::Util::NetworkDevice.current || device(resource[:device_url]) if result = lookup(device, name) result[:ensure] = :present resource.provider = new(device, result) else resource.provider = new(device, :ensure => :absent) end end end

      The line: ‘if result = lookup(device, name)’ is what (if you follow through the various classes and their methods) ends up calling the parse_interface(name) method I mention above. As parse_interface always returns a hash, result[:ensure] oh that hash always gets set to :present.

      Therefore despite the code detecting whether the port is shutdown or not and then sets resouces[:ensure] to present or absent, the code above simply resets it.

      Once you get into the code that compares should and is, is[:ensure] is always :present because of this.

      This is why, with my code at least, I can’t make an interface absent (and I think that’s the same for Cisco devices too).

      Thanks

      You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

      --
      You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
      To post to this group, send email to puppet-bugs <at> googlegroups.com.
      To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
      For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

      tickets | 1 Mar 13:29 2012

      [Puppet - Feature #11915] Segregate client facts, server facts and ENC params in topscope hashes

      Issue #11915 has been updated by Brice Figureau.

        R.I. Pienaar wrote:

        So many good things

        I’m more than 200% with R.I. on this. We don’t need to reinvent the wheel with new syntax, just exploit what we currently have. It just feels natural to use hash for this. I’d prefer the current status quo than the route with variable decorators (did we really learn the lessons of the spaceship operator?).

        Feature #11915: Segregate client facts, server facts and ENC params in topscope hashes

        • Author: Brice Figureau
        • Status: Needs Decision
        • Priority: Normal
        • Assignee: Randall Hansen
        • Category: language
        • Target version:
        • Affected Puppet version: 2.7.9
        • Keywords: scope facts lookup hash
        • Branch:

        Having to use $operatingsystem (and soon $::operatingsystem) in our manifests is:

        • confusing for new users
        • prone to name-clashing

        Those variables are really specific in Puppet because they come from the exterior.

        My proposal would be to move them to separate Puppet hashes of names:

        • $facts
        • $server_facts
        • $parameters

        So usage would be:

        ... firewall { "http": protocol => "TCP", src => $facts['ipaddress'] } file { "/etc/issue.net": content => "This host is in ${server_facts['environment']} environment" } ...

        We could also have some custom methods in the template wrappers so accessing facts in templates could be even easiers, like facts['ipaddress'].

        Of course to help migrate users, the first release would also put the facts/server facts and parameters in the node top scope (and issue a deprecation warning on lookup).

        You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

        --
        You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
        To post to this group, send email to puppet-bugs <at> googlegroups.com.
        To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
        For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

        tickets | 1 Mar 15:54 2012

        [Puppet - Bug #12905] (Unreviewed) Puppet does not follow dependancy chain in manifest

        Issue #12905 has been reported by Phil Spencer.

        Bug #12905: Puppet does not follow dependancy chain in manifest

        • Author: Phil Spencer
        • Status: Unreviewed
        • Priority: Normal
        • Assignee:
        • Category:
        • Target version:
        • Affected Puppet version:
        • Keywords:
        • Branch:

        Running puppet 2.6.8 I have a simple manifest:

        class puppetmaster { notice (“Running ${module_name}”) include puppetmaster::files include puppetmaster::packages include puppetmaster::services Class[‘puppetmaster::packages’]–>Class[‘puppetmaster::files’]–>Class[‘puppetmaster::services’] }

        class puppetmaster::packages { notice (“Running ${module_name}”)

        # install puppetmaster packages # install gems exec {“install-hiera”:

        command => "/usr/bin/gem install hiera hiera-puppet",

        }

        }

        class puppetmaster::files { notice (“Running ${module_name}”)

        # yaml config data file {“/etc/puppet/hiera.yaml”:

        source => 'puppet:///modules/puppetmaster/hiera.yaml', owner => 'root', group => 'root', mode => '0644',

        }

        # definition files for YAML

        case $domain {

        /^dev|stg\.vibrant\.corp$/: { $file="common.yaml.dev"} default: { $file="common.yaml.prod"}

        } notice (“file ${$file}”)

        file {“/etc/puppet/hieradata/common.yaml” :

        source => "puppet:///modules/puppetmaster/hieradata/${file}", owner => 'root', group => 'root', mode => '0644',

        } # ensure hieradata directory exists file { “/etc/puppet/hieradata/”:

        ensure => "directory",

        }

        }

        class puppetmaster::services { notice (“Running ${module_name}”)

        file {"/tmp/file.txt" : content => hiera('test'),

        } }

        when running a puppet apply, it doesn’t run according to the dependancy chain list in the manifest (package –> files –> services) Output is:

        root <at> puppet-test-agent:/etc/puppet/modules/puppetmaster# puppet apply test/init.pp —verbose —graph info: Loading facts in fedb notice: Scope(Class[Puppetmaster]): Running puppetmaster notice: Scope(Class[Puppetmaster::Files]): Running puppetmaster notice: Scope(Class[Puppetmaster::Files]): file common.yaml.prod notice: Scope(Class[Puppetmaster::Packages]): Running puppetmaster notice: Scope(Class[Puppetmaster::Services]): Running puppetmaster info: Applying configuration version ‘1330612896’ notice: /Stage[main]/Puppetmaster::Packages/Exec[install-hiera]/returns: executed successfully info: FileBucket adding {md5}007b0a49f86874e6396fbe52492d768d info: /Stage[main]/Puppetmaster::Services/File[/tmp/file.txt]: Filebucketed /tmp/file.txt to puppet with sum 007b0a49f86874e6396fbe52492d768d notice: /Stage[main]/Puppetmaster::Services/File[/tmp/file.txt]/content: content changed ‘{md5}007b0a49f86874e6396fbe52492d768d’ to ‘{md5}5eb63bbbe01eeed093cb22bb8f5acdc3’ notice: Finished catalog run in 11.78 seconds

        You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

        --
        You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
        To post to this group, send email to puppet-bugs <at> googlegroups.com.
        To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
        For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

        tickets | 1 Mar 16:03 2012

        [Puppet - Bug #12905] Puppet does not follow dependancy chain in manifest

        Issue #12905 has been updated by Phil Spencer.
        • File init.pp added
        • File expanded_relationships.dot added
        • File relationships.dot added
        • File resources.dot added

        dot files and init.pp, since my copy and paste didn’t seem to work

        Bug #12905: Puppet does not follow dependancy chain in manifest

        • Author: Phil Spencer
        • Status: Unreviewed
        • Priority: Normal
        • Assignee:
        • Category:
        • Target version:
        • Affected Puppet version:
        • Keywords:
        • Branch:

        Running puppet 2.6.8 I have a simple manifest:

        class puppetmaster { notice (“Running ${module_name}”) include puppetmaster::files include puppetmaster::packages include puppetmaster::services Class[‘puppetmaster::packages’]–>Class[‘puppetmaster::files’]–>Class[‘puppetmaster::services’] }

        class puppetmaster::packages { notice (“Running ${module_name}”)

        # install puppetmaster packages # install gems exec {“install-hiera”:

        command => "/usr/bin/gem install hiera hiera-puppet",

        }

        }

        class puppetmaster::files { notice (“Running ${module_name}”)

        # yaml config data file {“/etc/puppet/hiera.yaml”:

        source => 'puppet:///modules/puppetmaster/hiera.yaml', owner => 'root', group => 'root', mode => '0644',

        }

        # definition files for YAML

        case $domain {

        /^dev|stg\.vibrant\.corp$/: { $file="common.yaml.dev"} default: { $file="common.yaml.prod"}

        } notice (“file ${$file}”)

        file {“/etc/puppet/hieradata/common.yaml” :

        source => "puppet:///modules/puppetmaster/hieradata/${file}", owner => 'root', group => 'root', mode => '0644',

        } # ensure hieradata directory exists file { “/etc/puppet/hieradata/”:

        ensure => "directory",

        }

        }

        class puppetmaster::services { notice (“Running ${module_name}”)

        file {"/tmp/file.txt" : content => hiera('test'),

        } }

        when running a puppet apply, it doesn’t run according to the dependancy chain list in the manifest (package –> files –> services) Output is:

        root <at> puppet-test-agent:/etc/puppet/modules/puppetmaster# puppet apply test/init.pp —verbose —graph info: Loading facts in fedb notice: Scope(Class[Puppetmaster]): Running puppetmaster notice: Scope(Class[Puppetmaster::Files]): Running puppetmaster notice: Scope(Class[Puppetmaster::Files]): file common.yaml.prod notice: Scope(Class[Puppetmaster::Packages]): Running puppetmaster notice: Scope(Class[Puppetmaster::Services]): Running puppetmaster info: Applying configuration version ‘1330612896’ notice: /Stage[main]/Puppetmaster::Packages/Exec[install-hiera]/returns: executed successfully info: FileBucket adding {md5}007b0a49f86874e6396fbe52492d768d info: /Stage[main]/Puppetmaster::Services/File[/tmp/file.txt]: Filebucketed /tmp/file.txt to puppet with sum 007b0a49f86874e6396fbe52492d768d notice: /Stage[main]/Puppetmaster::Services/File[/tmp/file.txt]/content: content changed ‘{md5}007b0a49f86874e6396fbe52492d768d’ to ‘{md5}5eb63bbbe01eeed093cb22bb8f5acdc3’ notice: Finished catalog run in 11.78 seconds

        You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

        --
        You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
        To post to this group, send email to puppet-bugs <at> googlegroups.com.
        To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
        For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

        tickets | 1 Mar 16:30 2012

        [Puppet - Feature #11915] Segregate client facts, server facts and ENC params in topscope hashes

        Issue #11915 has been updated by Nigel Kersten.

          Something that may not be obvious to everyone is that the whole requirement of facts to be referred to as $::factname is actually a bug in the deprecation warning system.

          It only occurs in classes that are included via an ENC and not via any other means.

          That may color this discussion somewhat.

          I have no problem with not exposing the server settings to the manifests anymore. I’ve never needed to use it myself, and think Daniel is right in that people use it to work around other limitations.

          Feature #11915: Segregate client facts, server facts and ENC params in topscope hashes

          • Author: Brice Figureau
          • Status: Needs Decision
          • Priority: Normal
          • Assignee: Randall Hansen
          • Category: language
          • Target version:
          • Affected Puppet version: 2.7.9
          • Keywords: scope facts lookup hash
          • Branch:

          Having to use $operatingsystem (and soon $::operatingsystem) in our manifests is:

          • confusing for new users
          • prone to name-clashing

          Those variables are really specific in Puppet because they come from the exterior.

          My proposal would be to move them to separate Puppet hashes of names:

          • $facts
          • $server_facts
          • $parameters

          So usage would be:

          ... firewall { "http": protocol => "TCP", src => $facts['ipaddress'] } file { "/etc/issue.net": content => "This host is in ${server_facts['environment']} environment" } ...

          We could also have some custom methods in the template wrappers so accessing facts in templates could be even easiers, like facts['ipaddress'].

          Of course to help migrate users, the first release would also put the facts/server facts and parameters in the node top scope (and issue a deprecation warning on lookup).

          You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

          --
          You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
          To post to this group, send email to puppet-bugs <at> googlegroups.com.
          To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
          For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.


          Gmane