https://www.puppet.com/community logo
Join Slack
Powered by
# puppet
  • w
    would it be considered best practice, or optional?
  • n
    It’s a best practice to not make confusing code. And I think that having an overly complicated manifest structure just for a couple of resources would be confusing.
  • w
    Here's what I tossed together
    install.pp
  • w
    Do you have any reccomendations on things I should change so that I get in good habits from the get-go?
  • w
    structure wise anyway
  • s
    This message was deleted.
    w
    n
    • 3
    • 10
  • w
    Init.pp would be the sole manifest in that case?
  • n
    Correct. In the case of my first sentence there.
  • w
    Could you give me a rough example of what the restructuring of those sub classes would like?
  • v
    Copy code
    case $facts['os']['family'] {
    'RedHat': {
      case $facts['os']['architecture'] {
        'aarch64': {
          contain splunk::platform::redhat_aarch64_package
        }
        default  : {
          contain splunk::platform::redhat_package
        }
      }
    }
    'Solaris' : { contain splunk::platform::solaris_package }
    'Windows' : { contain splunk::platform::windows_package }
    default   : { fail('unsupported OS') }
  }
  • w
    Is that in the manifest or the site.pp
  • n
    Module structure would look something like this:
    Copy code
    desktopcentral_agent/
└── manifests/
    ├── init.pp
    ├── linux.pp
    └── windows.pp
    And yeah, 
    init.pp
    would contain some kind of case statement like what vchepkov said.
  • w
    Ah, so init.pp would load a sub manifest in that case?
    ✔️ 1
  • w
    That allows me to break things apart a bit more, I like it.
  • h
    puppet will load the referenced things; classes, functions etc. from where they are defined, so you want to organize your code so that both puppet autoloader and humans can find where the logic is
  • h
    The 
    init.pp
    is named 
    init
    for historical reasons, it is the file that is loaded when referencing a class having the same name as the module - in your case 
    desktopcentral_agent
    . The 
    init.pp
    is also loaded if a reference is made to a name in the module’s namespace and there is no corresponding file.
  • w
    As for the vars, is it fine to include them in their OS-specific manifest or should they be kept in a general "vars" manifest?
  • v
    I would have them as attributes to the class
  • v
    and set default values in hiera
  • r
    I'd also move most of the data into in-module hiera. Maybe make the Linux values default and Windows the exception for simplicity.
    👍 1
  • h
    The 
    init.pp
    is named 
    init
    for historical reasons, it is the file that is loaded when referencing a class having the same name as the module - in your case 
    desktopcentral_agent
    . The 
    init.pp
    is also loaded if a reference is made to a name in the module’s namespace and there is no corresponding file.
  • w
    Could you please link to an example/reference for doing that? I've not had much interaction with Hiera as of yet
  • v
  • v
  • v
  • v
  • w
    something like this?
    Copy code
    class desktopcentral_agent::linux {
  $source_file = 'puppet:///modules/desktopcentral_agent/UEMSLinuxAgent.zip'
}
  • s
    This message was deleted.
    r
    • 2
    • 1
  • r
    Example of a fairly simple module. Generally I prefer to having the init.pp ingest all the data the module may need when possible.
    Copy code
    puppetagent $ tree
├── data
│   └── os
│       ├── Linux.yaml
│       └── windows.yaml
├── files
│   ├── puppet.conf
│   └── sysconfig
├── hiera.yaml
├── manifests
│   ├── config.pp
│   ├── init.pp
│   ├── install.pp
│   ├── service
│   │   └── disable.pp
│   └── service.pp
    local hiera.yaml looks like
    Copy code
    hiera.yaml 
---
version: 5

defaults:  # Used for any hierarchy level that omits these keys.
  datadir: data         # This path is relative to hiera.yaml's directory.
  data_hash: yaml_data  # Use the built-in YAML backend.

hierarchy:
  - name: "osfamily/major release"
    paths:
      - "os/%{facts.os.family}/%{facts.os.release.major}.yaml"
        # Used for Solaris
      - "os/%{facts.os.family}/%{facts.kernelrelease}.yaml"
        # Used to distinguish between Debian and Ubuntu
      - "os/%{facts.os.name}/%{facts.os.release.major}.yaml"
  - name: "osfamily"
    paths:
      - "os/%{facts.os.family}.yaml"
      - "os/%{facts.os.name}.yaml"
      - "os/%{facts.kernel}.yaml"
  - name: 'common'
    path: 'common.yaml'
    And data
    Copy code
    ## data/os/windows.yaml 
---
puppetagent::config:
  main:
    autoflush: true
    manage_internal_file_permissions: false

puppetagent::config_dir: 'C:/ProgramData/PuppetLabs/puppet/etc'
puppetagent::install_dir: 'C:/Program Files/Puppet Labs/Puppet/puppet'

## data/os/Linux.yaml   
---
puppetagent::config_owner: 'root'
puppetagent::config_group: 'root'
puppetagent::config_mode: '0644'
    and init.pp
    Copy code
    manifests/init.pp  
# manages puppet agent install and config.
class puppetagent(
  Stdlib::Fqdn         $server,
  Optional[Hash]       $config = undef,
  Stdlib::Absolutepath $config_dir = '/etc/puppetlabs/puppet',
  Optional[String[1]]  $config_owner = undef,
  Optional[String[1]]  $config_group = undef,
  Optional[String[1]]  $config_mode = undef,
  Optional[Hash]       $gemrc = undef,
  Stdlib::Absolutepath $install_dir = '/opt/puppetlabs/puppet',
  String[1]            $version = 'installed',
) {
  • s
    This message was deleted.
    n
    d
    z
    • 4
    • 13
1...184185186...428Latest