[Puppet Users] PuppetDB 2.2 and pg_trgm extension
Hello, Bumping my installation up to Postgres 9.3.5 and PuppetDB 2.2 I noticed in the release notes about the pg_trgm extension (hence the Postgres update) However on installing them and setting up the extension (seemingly correctly):- $ psql psql (9.3.5) Type help for help. postgres=# \dx List of installed extensions Name | Version | Schema |Description -+-++--- pg_trgm | 1.1 | public | text similarity measurement and index searching based on trigrams plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language (2 rows) postgres-# \q I still get this on startup of PuppetDB2.2:- 2014-08-30 08:05:56,029 WARN [c.p.p.s.migrate] Missing PostgreSQL extension `pg_trgm` We are unable to create the recommended pg_trgm indexes due to the extension not being installed correctly. Run the command: CREATE EXTENSION pg_trgm; as the database super user on the PuppetDB database to correct this, then restart PuppetDB. Which is odd. My Postgres install is non-standard as I need to move the paths around for my environment but that shouldn't matter. Any ideas. These are on RHEL6.5. Cheers Paul -- 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 https://groups.google.com/d/msgid/puppet-users/1a58e32d-7255-4cb8-a13e-e134414f30a0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB 2.2 and pg_trgm extension
Ignore me didn't add the extension to the PuppetDB database. Added it to the puppetdb DB and hey presto:- 2014-08-30 08:40:27,935 INFO [c.p.p.s.migrate] Creating additional index `fact_paths_path_trgm` Too early in the morning for this sh.. Cheers Paul -- 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 https://groups.google.com/d/msgid/puppet-users/98eabcde-4935-40a8-865f-8b37f543e92e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Hierarchy and Structured Facts
Hi,
I've go a fact cfn_roles that is an array
Is it possible to use it in hierarchy ?
For exemple :
* my fact :
cfn_roles:
- apache
- mysql
And my hierarchy
|:hierarchy:
- %{::roles}|
hiera will try each entry of cfn_roles ?
Best regards,
--
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
https://groups.google.com/d/msgid/puppet-users/5401A6DB.4090406%40quake.fr.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Announce: Facter 2.2.0
Hi, I don't mind even changing that stuff in .Z releases but I think .Y is more appropriate indeed. Releasing a new major version of Facter every time a fact is bug fixed seems madness and not something you should get into. As long as the release notes are in order I think most people have come to expect at least some 'breakage' on .Y releases, regardless of wat semver says (that's not anything personal towards Puppet Labs, it happens on a lot of projects). -- Daniele Sluijters -- 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 https://groups.google.com/d/msgid/puppet-users/c57d48fe-0f12-4846-84cc-c6193cfca405%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Style - hiera/params/puppet/template
Greetings all,
In the pre-hiera days, it was commonly recommended to write classes with
params like this:
class my_class::params {
$config_param = 'default value'
}
class my_class (
$config_param = $myclass:params::config_param
) inherits myclass::params {
...
}
However, now that much overriding, customising etc has moved into Hiera,
this ends up being very verbose, redundant and error-prone, especially
if there are a lot of parameters (to go into a config template, for
example). The same parameter name may end up in four different places in
common cases: hiera, params, class decl and the config template.
So I would like to know if people are still doing this as much as
possible. What is the remaining benefit in declaring defaults in params
rather than in the class declaration directly? Is there a more up to
date style guide that does away with the verbosity and duplication, or
is the old params class style still widely recommended?
Thanks for any suggestions,
-Taj.
--
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
https://groups.google.com/d/msgid/puppet-users/5401FA70.9010101%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Style - hiera/params/puppet/template
Hi,
//I use params_lookup (lib from puppi)
https://github.com/example42/puppi/blob/master/lib/puppet/parser/functions/params_lookup.rb
it lookup in this order (first match is returned)
- Hiera backend (if present) for modulename_varname
- Hiera backend (if present) for varname (if second argument is 'global')
- Top Scope Variable ::modulename_varname
- Top Scope Variable ::varname (if second argument is 'global')
- Module default: ::modulename::params::varname
So all my classes are based on this tpl :
class my_class::params {
$config_param = 'default value'
}
class my_class (
$config_param = params_lookup('config_param'),
$global_param = params_lookup('global_param','global')
) inherits my_class::params {
...
}
Best regards,
Le 30/08/2014 18:23, Sirtaj Singh Kang a écrit :
Greetings all,
In the pre-hiera days, it was commonly recommended to write classes
with params like this:
class my_class::params {
$config_param = 'default value'
}
class my_class (
$config_param = $myclass:params::config_param
) inherits myclass::params {
...
}
However, now that much overriding, customising etc has moved into
Hiera, this ends up being very verbose, redundant and error-prone,
especially if there are a lot of parameters (to go into a config
template, for example). The same parameter name may end up in four
different places in common cases: hiera, params, class decl and the
config template.
So I would like to know if people are still doing this as much as
possible. What is the remaining benefit in declaring defaults in
params rather than in the class declaration directly? Is there a more
up to date style guide that does away with the verbosity and
duplication, or is the old params class style still widely recommended?
Thanks for any suggestions,
-Taj.
--
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
https://groups.google.com/d/msgid/puppet-users/54021880.3090505%40quake.fr.
For more options, visit https://groups.google.com/d/optout.
