Would this mean that this code would change from printing 'hello' to
printing ''?
class foo ($x='hello') { notify { $x: }}
class { 'foo': x => undef }
And I guess the former behaviour would be achieved by changing it to:
class foo ($x='hello') { notify { $x: }}
class { 'foo': x => default }
I t
Thanks Lindsey
On Saturday, 14 September 2013 09:11:05 UTC+10, Lindsey Smith wrote:
>
> Steven,
>
> That feature request refers to the OSS Dashboard, which Puppet Labs is not
> maintaining and could be addressed by the community.
>
> Today the PE dashboard doesn't have support for environments. F
On 13 September 2013 18:52, Henrik Lindberg
wrote:
> Hi,
> Ideas regarding a potential performance boost that can be gained by
> performing batch processing of package installs/operations has been
> floating around in the Puppet echo system for quite some time.
>
> There is a discussion (and a som
On 16 September 2013 06:42, Henrik Lindberg
wrote:
> On 2013-16-09 6:22, Luke Kanies wrote:
>
>> On Sep 15, 2013, at 8:55 PM, Henrik Lindberg > **com > wrote:
>>
>> On 2013-16-09 5:41, Luke Kanies wrote:
>>>
Hi Henrik,
I know we have some users who just batch all package installs u
On 2013-16-09 6:22, Luke Kanies wrote:
On Sep 15, 2013, at 8:55 PM, Henrik Lindberg
wrote:
On 2013-16-09 5:41, Luke Kanies wrote:
Hi Henrik,
I know we have some users who just batch all package installs up front. It'd
be interesting to see if that was a feasible solution. it would by pas
Hi Spencer,
On 2013-16-09 3:39, Spencer Krum wrote:
Hello,
I am trying to follow ARM-9 and use the data in modules features
introduced in the 3.3 release. I am struggling to get many of the
features mentioned in ARM-9 working. I have a basic module here
https://github.com/pro-puppet/puppet-modu
On Sep 15, 2013, at 8:55 PM, Henrik Lindberg
wrote:
> On 2013-16-09 5:41, Luke Kanies wrote:
>> Hi Henrik,
>>
>> I know we have some users who just batch all package installs up front.
>> It'd be interesting to see if that was a feasible solution. it would by
>> pass the graph entirely, whi
On 2013-16-09 5:41, Luke Kanies wrote:
Hi Henrik,
I know we have some users who just batch all package installs up front. It'd
be interesting to see if that was a feasible solution. it would by pass the
graph entirely, which I'm sure could have problems, but it would, at least, be
easy to b
Hi Henrik,
I know we have some users who just batch all package installs up front. It'd
be interesting to see if that was a feasible solution. it would by pass the
graph entirely, which I'm sure could have problems, but it would, at least, be
easy to build and understand. Would that suffice
Hello,
I am trying to follow ARM-9 and use the data in modules features introduced
in the 3.3 release. I am struggling to get many of the features mentioned
in ARM-9 working. I have a basic module here
https://github.com/pro-puppet/puppet-module-startrek, but when trying to
add an element to t
Turns out I had a typo:
Puppet::Type.type(:bmc).provide(:ipmitool) do
was
Puppet::Type.type(:bmc).provider(:ipmitool) do
Seems to work.
Now how do I mock things like:
1. command :ipmitool
2. confine :is_virtual => "false"
3. confine :true => File.exists?('/dev/ipmi0') ||
File.exists?('/dev/i
Hi,
I am been trying really hard to test my custom type/provider. Every
example seems to not fit my case though. Most of the examples only cover
the providers or puppet code.
My case is a type and provider combined.
The puppet_labs_spec_helper has at least helped me out. I have been
fo
I am looking at all sorts of things for puppet 4 - one of them is how to
exorcise the special cases for puppet's undef and treating it like
nil/null in other languages.
There is really just one special case (as noted earlier in issues) and
that is when assignment of undef takes place to a reso
On Sat, Sep 14, 2013 at 8:17 PM, badgerious wrote:
> Re: the yard docs, I think they are generally pretty good for API docs,
> and it looks like most of the stuff is in fact documented in the code, but
> not appearing in generated output for some reason. I took a quick look but
> didn't see any o
Based on this discussion and the currently existing functions, I’m also really
leaning towards the dropping of ‘_hook’. Descriptive names and good docs feel
sufficient enough.
In regards to my previous contribution (post_compile_hook), I may rework that
PR to remove the ‘_hook’ part before it g
On Sat, Sep 14, 2013 at 8:17 PM, badgerious wrote:
> Re: the yard docs, I think they are generally pretty good for API docs,
> and it looks like most of the stuff is in fact documented in the code, but
> not appearing in generated output for some reason. I took a quick look but
> didn't see any o
16 matches
Mail list logo
