https://www.puppet.com/community logo
Join Slack
Powered by
# puppet
  • w
    within site.pp , do classes have to be assigned underneath a node, or can you do it in reverse where you declare a class and then the nodes it should be installed on?
  • w
    Or set up group-based aliases ?
  • n
    They don’t have to be assigned underneath a node, but it’s strongly recommended to do so.
  • w
    How would I go about grouping nodes/tasks ?
  • w
    E.G. (Webservers)
  • w
    and then have sub tasks for specific subsects
  • w
    Webservers , Webservers_appname
  • n
    With a combination of facts and the “Roles and Profiles” design pattern: https://puppet.com/docs/pe/2019.8/osp/the_roles_and_profiles_method.html
  • n
    Ideally, there would be some way to group all your related nodes together. Some people have good hostnaming conventions and can group everything by hostname…. but that’s not always possible. The other way to group nodes is with facts. Then you can assign Puppet code to groups of nodes with conditional logic in the 
    default
    node definition based on the value of a fact.
  • w
    ah nice, so I could tag them in some manner and then assign classes etc based on that fact?
  • n
    yup, exactly. And a common way to do that in the Puppet community is with facts. In particular, there would be a fact called 
    role
    that you make and add to all of your nodes. This 
    role
    fact just acts a label that you can use in conditional logic to include other classes and modules. (that’s one part of the “roles and profiles” pattern)
  • n
    https://gist.github.com/natemccurdy/07e8f08f0b1811e8cbb8996bd08e5915 Here’s an example that I find works really well…. This uses the 
    node default {}
    definition, and looks at the trusted fact called 
    pp_role
    (but for example’s sake, imagine that’s just 
    role
    ), and includes a class named after the fact’s value.
  • n
    By the way, this thing we’re talking about is called “classification”. The process of determining which classes to assign to a node. That term will help you find other docs and blog posts about the matter.
  • n
    By the way, this thing we’re talking about is called “classification”. The process of determining which classes to assign to a node. That term will help you find other docs and blog posts about the matter.
  • w
    thank you 😃
  • i
    Hi .. I had a question re hiera searching hieradata files - this relates to upgrading from hiera3 to hiera5 … Our previous hiera.yaml included the definitions class_module_files/${calling_class} and class_module_files/${calling_module} - the $calling_* variables do not exist for hiera5 - which is fine we want to consolidate the hieradata files anyway …. as I understand it in hiera3 calling_class is the full class name (eg profile:web server:fred) and the calling_module the top level (using the same eg profile) The question relates to the content of the hieradata files - if we have a profile:web server:fred.yaml file with hieradata does that data within it get read no matter the hieradata variable name ? I’d expect hieradata in these files to be for a specific class or module only - however some existing files have data for other unrelated modules. I think the hieradata will be read /used when the $calling_class or $calling_module result in the yaml files being included in the list to be parsed (when using hiera3) - I just want to be sure !
  • m
    I updated the PR for facter 4 so it passes rubocop https://github.com/puppetlabs/facter/pull/2519 and updated the ticket to Ready for Merge
  • h
    Everything is driven by the hiera.yaml, you can use 
    puppet lookup <key> --node <nodename> --environment <environment>  --explain
    to see the path that puppet consults including the hiera.yaml files consulted. Typically it consults the hiera.yaml on the system (which is also typically empty) and then moves on to the hiera.yaml in the controlrepo. If the hierarchy you defined has fact names in the path to the file, then puppet will load that fact name and construct the path and then look in that yaml file for any key you lookup e.g.
    Copy code
    ---
version: 5
defaults:
  # location of the hiera yaml data directory, relative to this file
  datadir: data
  data_hash: yaml_data

hierarchy:
  - name: "Global override"
    path: "global.yaml"

  - name: "Per-node data (yaml version)"
    path: "nodes/%{::clientcert}.yaml"

  - name: "Per operatingsystem"
    path: "os/%{::operatingsystem}.yaml"

  - name: "common"
    path: "common.yaml"
    this is an old sample hiera.yaml and puppet will consult global.yaml first and then consult the next layers. The second and third layers will be specific to the node that is checking in. The first and fourth will be the same regardless the node. Does that answer your question?
  • d
    ```- took a hit! Ouch. (Karma: -75)
  • s
    This message was deleted.
    i
    • 2
    • 1
  • s
    This message was deleted.
    j
    h
    • 3
    • 6
  • h
    What was the error you got when you removed it?
  • s
    This message was deleted.
    h
    s
    • 3
    • 35
  • j
    Copy code
    sudo /opt/puppetlabs/bin/puppet agent --test --agent_disabled_lockfile=/nonexisting --noop  2>&1 | tee /home/jdratlif/puppet.log
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Function lookup() did not find a value for the name 'classes' on node REDACTED                                                                                                                                       
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
  • s
    one of my team mate agreed with a new node definition abc03 without role:muleserver but also suggested to add somethiing if fqdn!= abc03 then apply vhost config......
  • s
    message has been deleted
  • s
    This message was deleted.
    l
    b
    • 3
    • 3
  • l
    not sure why it's happening given the code in the erb
  • w
    If a puppet module really only has one function (copy and then execute an installer package), is it best practice to have a single manifest for install.pp or should there still be an init.pp that references it?
  • n
    in my opinion, 
    init.pp
    is fine for something that small.
1...183184185...428Latest