Jira (HI-257) Dynamic hierarchy based on fact/variable
Title: Message Title
Matteo Cerutti created an issue
Hiera / HI-257
Dynamic hierarchy based on fact/variable
Issue Type:
New Feature
Assignee:
Unassigned
Created:
23/May/14 3:25 AM
Priority:
Normal
Reporter:
Matteo Cerutti
Take the following hierarchy example:
hiera/%{::variable}/common
let's say $variable is an array: $variable = ["a", "b", "c"]
Hiera understands that $variable is an array and it would then build an hierarchy as follows:
hiera/a/common
hiera/b/common
hiera/c/common
Both these examples find real work scenarios. Let's say a machine as a number of roles (webserver, dns server etc.). One could have an array containing each role and build the hierarchy based on that. Extremely powerful.
Jira (HI-257) Dynamic hierarchy based on fact/variable
Title: Message Title
Matteo Cerutti commented on an issue
Re: Dynamic hierarchy based on fact/variable
Hey guys,
thanks for commenting on this request.
Since I needed this very urgently, I implemented it for myself.
I've actually opened a pull request for this on Sat, https://github.com/puppetlabs/hiera/pull/193. In reality, the pull request was really to discuss the change.
Look forward to have this feature implemented in Hiera soon!
Add Comment
Hiera / HI-257
Dynamic hierarchy based on fact/variable
Take the following hierarchy example: - hiera/%{::variable}/common let's say $variable is an array: $variable = ["a", "b", "c"] Hiera understands that $variable is an array and it would then build an hierarchy as follows: - hiera/a/common - hiera/b/common - hiera/c/common Both these examples find real work scenarios. Let's say a machine a...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Grou
Jira (PUP-2705) External facts pluginsync not preserving executable bit
Title: Message Title Matteo Cerutti created an issue Puppet / PUP-2705 External facts pluginsync not preserving executable bit Issue Type: Bug Affects Versions: 3.6.1 Assignee: Unassigned Created: 01/Jun/14 10:43 AM Priority: Blocker Reporter: Matteo Cerutti As per the subject, the external facts feature in puppet 3.6.1 is partially broken. I've tried to add a script into the /facts.d path and given it executable permissions too. Once the agent runs, it successfully syncs the plugin across in the external facts directory (/var/lib/puppet/facts.d). However, the script lacks the original permissions. Add Comment
Jira (PUP-2705) External facts pluginsync not preserving executable bit
Title: Message Title Matteo Cerutti commented on an issue Re: External facts pluginsync not preserving executable bit It seems that the source_permissions is set to :ignore in configurer/downloader.rb. Shouldn't it be set to :use? Cheers, Matteo Add Comment Puppet / PUP-2705 External facts pluginsync not preserving executable bit As per the subject, the external facts feature in puppet 3.6.1 is partially broken. I've tried to add a script into the /facts.d path and given it executable permissions too. Once the agent runs, it successfully syncs the plugin across in the external facts directory (/var/lib/puppet/facts.d). However, the script lacks the original permissions. This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/p
Jira (PUP-2705) External facts pluginsync not preserving executable bit
Title: Message Title Matteo Cerutti commented on an issue Re: External facts pluginsync not preserving executable bit Made a pull request @ https://github.com/puppetlabs/puppet/pull/2715 Add Comment Puppet / PUP-2705 External facts pluginsync not preserving executable bit As per the subject, the external facts feature in puppet 3.6.1 is partially broken. I've tried to add a script into the /facts.d path and given it executable permissions too. Once the agent runs, it successfully syncs the plugin across in the external facts directory (/var/lib/puppet/facts.d). However, the script lacks the original permissions. This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2728) zypper should always be the default package provider for Suse osfamily
Title: Message Title Matteo Cerutti created an issue Puppet / PUP-2728 zypper should always be the default package provider for Suse osfamily Issue Type: Improvement Affects Versions: 3.6.1 Assignee: Unassigned Created: 04/Jun/14 11:48 AM Priority: Normal Reporter: Matteo Cerutti zypper package manager should always be the default package provider for Suse osfamily. Additionally, this prevents puppet agent from moaning about the presence of multiple package providers if others are also installed (e.g. Yum) along with zypper. In this case, Puppet will default to the first provider it finds, which does not happen to be the same at every puppet run. Please note that rug is no longer used as zypper fully replaced it. PR @ https://github.com/puppetlabs/puppet/pull/2716 Add Comment
Jira (PUP-2728) zypper should always be the default package provider for Suse osfamily
Title: Message Title Matteo Cerutti commented on an issue Re: zypper should always be the default package provider for Suse osfamily Adrien Thebo, I believe zypper has been available since SLES 10SP1. However, it officially replaced rug in SLES 11. On the desktop side (openSuSE), there I believe it's been available since OpenSuSE 10.2, though officially replaced rug starting from 10.3. HTH, Matteo Add Comment Puppet / PUP-2728 zypper should always be the default package provider for Suse osfamily zypper package manager should always be the default package provider for Suse osfamily. Additionally, this prevents puppet agent from moaning about the presence of multiple package providers if others are also installed (e.g. Yum) along with zypper. In this case, Puppet will default to the first provider it finds, which does not happen to be the same... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to p
Jira (PUP-2728) zypper should always be the default package provider for Suse osfamily
Title: Message Title Matteo Cerutti commented on an issue Re: zypper should always be the default package provider for Suse osfamily Adrien, I believe rug should be default on SLES 10. Zypper will be available most likely. However, rug is the preferred package software manager on SLE 10. HTH. Matteo Add Comment Puppet / PUP-2728 zypper should always be the default package provider for Suse osfamily zypper package manager should always be the default package provider for Suse osfamily. Additionally, this prevents puppet agent from moaning about the presence of multiple package providers if others are also installed (e.g. Yum) along with zypper. In this case, Puppet will default to the first provider it finds, which does not happen to be the same... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@g
Jira (PUP-2728) zypper should always be the default package provider for Suse osfamily
Title: Message Title Matteo Cerutti commented on an issue Re: zypper should always be the default package provider for Suse osfamily Adrien Thebo, you can download yum rpm for OpenSuSE/SLES at http://download.opensuse.org/repositories/system:/packagemanager. HTH, Matteo Add Comment Puppet / PUP-2728 zypper should always be the default package provider for Suse osfamily zypper package manager should always be the default package provider for Suse osfamily. Additionally, this prevents puppet agent from moaning about the presence of multiple package providers if others are also installed (e.g. Yum) along with zypper. In this case, Puppet will default to the first provider it finds, which does not happen to be the same... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://group
Jira (HI-497) Hiera literal broken when used multiple times
Title: Message Title
Matteo Cerutti created an issue
Hiera / HI-497
Hiera literal broken when used multiple times
Issue Type:
Bug
Affects Versions:
HI 3.0.6
Assignee:
Unassigned
Created:
2016/02/03 1:51 AM
Priority:
Blocker
Reporter:
Matteo Cerutti
When literal('%') is used multiple times, it breaks with the following errors:
Error: Evaluation Error: Error while evaluating a Function Call, Detected in [literal('%')] at ..
Also, in the latest hiera release, the %%{} workaround no longer works.
Add Comment
Jira (PUP-7835) undefined method `from' for #
Title: Message Title Matteo Cerutti created an issue Puppet / PUP-7835 undefined method `from' for # Issue Type: Bug Affects Versions: PUP 5.0.1 Assignee: Unassigned Components: Puppet Server Created: 2017/08/11 4:00 AM Priority: Normal Reporter: Matteo Cerutti The problem occurs when including a class that might look like the following: class test ( String $var,
Jira (PUP-7835) undefined method `from' for #
Title: Message Title
Matteo Cerutti updated an issue
Puppet / PUP-7835
undefined method `from' for #
Change By:
Matteo Cerutti
The problem occurs when including a class that might look like the following:{code:puppet}class test ( String $var, Test::Options $opts) {}{code}Let's assume that Test::Options is defined as:{code:puppet}type Test::Options = Struct[{ var => String}]{code}If the 'var' parameter doesn't get passed to the keepalived test class, an evaluation error would be generated as expected. This works indeed.However, one would expected to see the same evaluation error popping up if var is not specified in the 'opts' hash, since it is required. Instead, the following error occurs:{noformat}Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Method call, undefined method `from' for #{noformat}This problem does not occur when using puppet apply (masterless).
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6862) Lookup doesn't interpolate values into hash keys
Title: Message Title Matteo Cerutti commented on PUP-6862 Re: Lookup doesn't interpolate values into hash keys I'm using 4.7, and I see the same issue. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
