https://www.puppet.com/community logo
Join Slack
Powered by
# puppet
  • n
    Copy code
    Type[title] {
  timeout => 900,
}
  • n
    What’s the title of the exec?
  • c
    Copy code
    nodejs::npm { 'pm2':
    ensure          => '4.5.4',
    package         => 'pm2',
    target          => '/usr/lib',
#   user            => $serviceuser,
    install_options => ['-g'],
#   require         => File['/opt/packages']
  }
  nodejs::npm { 'pm2-intercom':
    ensure          => '1.0.0',
    package         => 'pm2-intercom',
    target          => '/usr/lib',
    install_options => ['-g'],
#   require         => File['/opt/packages']
  }
  • n
    You’ll have to look inside 
    nodejs::npm
    to find the title of the 
    exec
    that it generates.
  • n
    that exec is what you need to override
  • c
  • c
  • b
    you could also submit a patch to the module and I merge it
  • c
    so npm_install_pm2 and npm_install_pm2-intercom i would guess
  • b
    puts that on the list of things were we should do some shell escaping
  • s
    This message was deleted.
    c
    • 2
    • 1
  • n
    But yeah… definitely also submit a patch to make the timeout configurable if you have the time
  • n
    But yeah… definitely also submit a patch to make the timeout configurable if you have the time
  • c
    @bastelfreak I don't think its all npm modules... these 2 are really old I'm just guessing that maybe something it pulls in as a dependency might have updated an grabbed more dependencies now?
  • c
    ah in the nodejs module make it so you can override on a per install basis
  • c
    got it
  • b
    possible. or your mirror is slow or your disk IO is bad
  • c
    yeah it doesn't seem to be doing it with any other NPM modules... and after this is cached in our JFrog Cloud it shouldn't be "slow" anymore
  • c
    thanks for the help @natemccurdy ... yeah @bastelfreak understood... think parameter override for the defined type would be useful... don't have the moment to submit the patch but if I get it later I will try
    👍 1
  • d
    goodnews 🧑‍🏫Puppet Forge is about to start up in #CFD8Z9A4T
  • s
    This message was deleted.
    r
    • 2
    • 1
  • d
    fry dancing 🧑‍🏫PE Console is about to start up in #CFD8Z9A4T
  • y
    I'm using pdk daily as my main validation and unit test runner. Then using vim/macvim for mainly single new file development. Then using vscode with vim plugin for refactoring/understanding the legacy codebase (I have it here a lot). Was using the same for SaltStack on my previous job (except pdk) 😬
  • s
    This message was deleted.
    t
    v
    h
    • 4
    • 27
  • h
  • s
    This message was deleted.
    t
    a
    d
    • 4
    • 6
  • s
    This message was deleted.
    b
    j
    • 3
    • 10
  • s
    This message was deleted.
    y
    b
    h
    • 4
    • 24
  • s
    This message was deleted.
    b
    b
    +5
    • 8
    • 23
  • b
    I would like some advice/comments on technique/style design decisions that I'm facing with implementing Puppet. I'm using the roles/profiles methodology and I've got a hiera hierarchy that is: - nodes/%{trusted.certname}.yaml - applications/${application}.yaml - os/%{facts.os.family} - common.yaml I'm using the heck out of the hiera hierarchy and it's working well. For example, in the common.yaml file I have all of the RPM GPG keys that are needed for each server (such as my company's internal RPM GPG signing key) but in data/os/os.family I have two files, 'RedHat.yaml' and 'OracleLinux.yaml' that contain needed keys for the respective OS. Of course, I don't need Oracle GPG keys in the Red Hat servers and vice-versa. My design conundrum is with the application hierarchy. I have an in-house application called, 'Brooklyn' that requires additional parameters passed to the SSH, logrotate, file, etc. Those parameters are already in a data/application/brooklyn.yaml and are being applied as desired. The Brooklyn application requires that files and directories get created based on other facts. The files and directories need to be upper-cased versions of those facts such as /mnt/brooklyn/TOYOTA/111. Since there's not a way to apply 'upcase' to hiera values in the yaml files (or is there?) do I keep all non-edge case hiera parameters in the data/application/brooklyn.yaml file or do I move everything into a new module called 'puppet-brooklyn'? In addition, I've created some custom facts that will uppercase the customer (in this case 'toyota') so that I don't have to write a file resource: 
    $customer = $my_customer.upcase
    file {"/mnt/${customer}":  ensure => directory}
    vs: that upper-cases the customer name. That seems like I'm obfuscating things even more, however it does solve all of my issues. I keep going back and forth on the design of this module. About 95% of what's already in the data/application/brooklyn hierarchy works fine. It seems silly to me to move all of that stuff into the puppet-brooklyn module just to take care of the edge case (ie: upper-case naming) but it also seems silly to have my 'brooklyn' data in two places. Every time I start moving my hiera stuff to my brooklyn application I question why I'm doing so because 95% of the existing hierarchy is already working perfectly. Any comments or suggestions are highly appreciated!
1...145146147...428Latest