Great news! Thanks :)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
I feel silly for asking, but with no release since 1.3.4 for some time now
and this wonderful new feature
- https://tickets.puppetlabs.com/browse/HI-183 .. I thought I'd wager a
post.
Surely I'm not the only person excited about a new release?
--
You received this message because you are
I've always found that when creating modules I'd focus on creating class
parameters out of the most important configuration options of whatever I'm
managing. After that I'd add a similar approach as yours for everything
else. This is a good approach because your module becomes usable for all
For more dynamic hiera hierarchy behaviors, take a look here and add your
vote / any relevant links: https://tickets.puppetlabs.com/browse/HI-257
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving
This should help:
https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/puppet/parser/functions/delete_undef_values.rb
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it,
Great stuff, thanks for this. Would be nice to get this kind of
troubleshooting in the official docs somewhere.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Hi,
The accepted standard for sharing code seems to be modules, which doesn't
seem a nice fit if you simply want to share a single custom Puppet function.
Having an easy way to look for Puppet functions would likely greatly help
the development of such, providing a nice set of examples and
Wouldn't it be easier to turn:
file{download apache-tomcat-$version ...}
into an Exec (curl/wget) with an unless parameter?
or more like your original design, but limited: turn define download into
a class that installs only a single version (maybe a separate class per
major version, and just
On Thursday, April 24, 2014 10:36:13 PM UTC+9, jcbollinger wrote:
On Thursday, April 24, 2014 2:45:21 AM UTC-5, William Leese wrote:
The accepted standard for sharing code seems to be modules, which doesn't
seem a nice fit if you simply want to share a single custom Puppet function.
Why
What does the actual yaml containing the encrypted value look like? I've
had some trouble simply copy pasting eyaml output into yaml files. I
found using something like this works best:
mysql::server::root_password:
Thanks for all the work on this - much appreciated.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this
Created a function that generates a collector. Will use a different
function to remove all undef-ed values from a hash and feed that to the
fuction:
https://github.com/wleese/puppet-create_collector
--
You received this message because you are subscribed to the Google Groups
Puppet Users
Hi,
I had a nice setup where I'd load a hash of from hiera as virtual
resources. These would be considered defaults that could be overridden
through a defined type. The defined type would allow things like homedir
and such to be overridden and the rest of the params would use the defaults
as
makes perfect sense.
Attacking my problem from a different angle, without completely redesigning
the module, how would one go about checking to see if multiple variables
are defined and using only those that are defined as parameter overrides
for a collector?
--
William Leese
--
You received
On Friday, December 13, 2013 5:30:26 AM UTC+9, Trevor Vaughan wrote:
Does anyone know of a way to add a file-centric backtrace to the validate
functions in the Stdlib?
If you use a validator in a defined type, you end up not having any idea
what actually threw the error.
Annoying indeed
I would like to set to noop some classes (not all) for some server
groups. (For example, we can have 2 types of modules, IT and Middleware,
IT must be in no-noop and Middleware must be in noop)
So you would like to sometimes apply a nodes assigned classes and sometimes
not? That sounds
On Thursday, December 12, 2013 7:33:26 AM UTC+9, Paul Archer wrote:
*# this is a typical facter output for filesystems*
root@puppetmaster:/etc/puppet/hieradata# facter filesystems
ext4,iso9660
*# my hiera.yaml, to show the first entry in my hierarchy is for the
filesystems fact*
Seems to me more like:
After a year we still haven't found time for this. Let's keep our bug
database manageable but only keeping the stuff we can do within a
reasonable time or the bug reports that contain some troubleshooting effort
we don't want to redo.
Quite a reasonable approach I'd say.
The data in LDAP is really more like database data, not so much as system
information
I guess the question really evolves around this: despite the system
configuration being stored in a datastore that provides infinitely amount
of flexibility, do you continue to consider your system
Hi,
I'm faced with the question if we should be doing user management directly
using freeipa (an integrated LDAP, Kerberos, CA, etc) or by manipulating
freeipa using Puppet.
Installation and configuration of the service is already performed through
Puppet so this only concerns the data stored
On Wednesday, October 30, 2013 10:08:14 PM UTC+9, jcbollinger wrote:
Per the docs, the :merge_behavior setting affects how hashes are merged in
a hash merge lookup. Not every hiera lookup is a hash merge lookup, and
whether a query is of that kind does not depend on the type of the data
Hi,
To my surprise hashes passed to class parameters pulled from hiera with
:merge_behavior: deeper, are not merged as expected, where as hiera_hash
does work as expected.
Or to rephrase: they behave differently, despite merge_behavior being set.
I found a snippet documenting this here:
Sounds to me that your hierarchy needs some rethinking.
What makes this node special?
Is it common to other nodes now or in the future?
Does an existing fact exist that can be used in the Hiera hierarchy?
If the serverlist is moved from common.yaml up the hierarchy, you'd be able
to solve your
accidentally just replied to author?
again:
so changed everything as suggested, but still no luck.
site.pp:
---
node /mag-lab04/ inherits mag-lab {
include os_common
Os_common::Users::Virtualuser | tag == 'ops' |
realize Os_common::Users::Virtualuser['tjones']
}
...realize works, collector
class os_common::users ( ) {
$users = loadyaml('/etc/puppet/resources/users.yaml')
define virtualuser ( ) {
tag $users[$title]['tag']
basic::add_user { $title:
email = $users[$title]['email'],
uid = $users[$title]['uid'],
role = $users[$title]['role'],
}
25 matches
Mail list logo
