On 4 Mar 2011, at 6:03 PM, nfagerlund wrote:
> This patch appends **Autorequires:** notes to the @doc string of every type
> whose instances can autorequire other resources. This will put autorequire
> info right on the types reference where it can do the most good.
>
> Signed-off-by: nfagerlund
This patch appends **Autorequires:** notes to the @doc string of every type
whose instances can autorequire other resources. This will put autorequire info
right on the types reference where it can do the most good.
Signed-off-by: nfagerlund
---
lib/puppet/type/computer.rb |6 +++
> The title_pattern method is used in resource.rb in the parse_title
> method. It will expect that you return an (not really intuitive) array
> of the form
>
> [ [ regex1, ARRAY ], [ regex2, ARRAY ] ]
>
> with ARRAY = [ [:namevar1, proc_that_is_called_with_namevar1], ...
> ,[:namevarN, proc ] ]
>
>
On Fri, Mar 04, 2011 at 05:08:05PM -0500, Trevor Vaughan wrote:
> Thanks for the example! That was exactly what I was looking for.
>
> Also, thanks for the bug list since I would have run into them.
>
> Is title_patterns an override that must be called? What's the
> difference between this and ju
On Mar 4, 2011, at 2:19 PM, Paul Berry wrote:
> On Fri, Mar 4, 2011 at 8:39 AM, Luke Kanies wrote:
> On Mar 4, 2011, at 8:25 AM, Markus Roberts wrote:
>
>> > > This would terminate the operating code inside puppet at that point;
>> > now logging is fatal, and there is no mechanism to suppress t
On Fri, Mar 4, 2011 at 8:39 AM, Luke Kanies wrote:
> On Mar 4, 2011, at 8:25 AM, Markus Roberts wrote:
>
> > > This would terminate the operating code inside puppet at that point;
>
>> > now logging is fatal, and there is no mechanism to suppress that. If
>> > it wasn't for that property I wou
Thanks for the example! That was exactly what I was looking for.
Also, thanks for the bug list since I would have run into them.
Is title_patterns an override that must be called? What's the
difference between this and just munging in each of the parameters?
Thanks,
Trevor
On Fri, Mar 4, 2011
The URL had been /inventory/search, and changed in Puppet to
/facts_search/search, so Dashboard reflects this.
Paired-With: Daniel Pittman
Signed-off-by: Nick Lewis
---
Local-branch: ticket/next/6601
app/models/node.rb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ap
On Fri, Mar 04, 2011 at 01:46:54PM -0500, Trevor Vaughan wrote:
> Is it possible to create a composite namevar when creating a custom type?
>
> Say you have an /etc/passwd like file that could exist at multiple locations.
>
> The actual unique set of variables is the target path of the file
> com
Yeah, using the path:username is fine but a big fugly.
What I'd like is this:
foo { "meaningless_name":
target => "/some/path",
username => "username"
}
Then, in foo.rb, I'd like to be able to say:
:namevar = "#{target}:#{username}
This would effectively throw away 'meaningless_name' and a
> What I mean is this:
>
> * My understanding is that the goal is to fail when any warning or higher
> logs get sent that the tests don't expect
>
> * My experience is that immediate failure with resulting stack trace is
> always easier to debug than delayed failure
>
> * Thus, my proposal, which
> What I don't understand is where my logic has gone wrong and why Daniel's
> proposal is preferred.
>
The logic is fine, but:
1) We've got some learned skittishness on relying on mocha for this
sort of thing
2) If your problem is that you're over-catching exceptions, raising an
exception when you
Trevor --
It should be. The way to do it would be to set up a naming scheme that let
the key fields be inferred from the title (e.g. something like "username in
path" or the "path:username" that you gave as an example) with a regular
expression to parse them (e.g. /^([a-zA-Z_0-9+) in (.+)$/ or
/^
Is it possible to create a composite namevar when creating a custom type?
Say you have an /etc/passwd like file that could exist at multiple locations.
The actual unique set of variables is the target path of the file
combined with the username.
I'm trying to avoid something like:
foo { "/some/
On Mar 4, 2011, at 9:25 AM, Markus Roberts wrote:
>> > > This would terminate the operating code inside puppet at that point;
>> > now logging is fatal, and there is no mechanism to suppress that. If
>> > it wasn't for that property I would pretty much entirely agree.
>>
>> Huh; not sure why it'
>
> > > This would terminate the operating code inside puppet at that point;
>
>> > now logging is fatal, and there is no mechanism to suppress that. If
>> > it wasn't for that property I would pretty much entirely agree.
>>
>> Huh; not sure why it's a bad thing to terminate the processing here,
On Mar 4, 2011, at 8:25 AM, Markus Roberts wrote:
> > This would terminate the operating code inside puppet at that point;
> > now logging is fatal, and there is no mechanism to suppress that. If
> > it wasn't for that property I would pretty much entirely agree.
>
> Huh; not sure why it's a b
> > This would terminate the operating code inside puppet at that point;
> > now logging is fatal, and there is no mechanism to suppress that. If
> > it wasn't for that property I would pretty much entirely agree.
>
> Huh; not sure why it's a bad thing to terminate the processing here, since
> th
18 matches
Mail list logo
