I happen to do that quite frequently I'm afraid.
> Sorry if it created some issues. I didn't expect (no pun intended) that
> it wasn't working (and I'm positive this used to work).
>
> > Expecting a stubbed method never wasn't working, however expecting a
> > stubbed method >= once behaved as expec
S --
I'm currrently looking at the specs for the ssh_authorized_key provider.
> There are two tests that give me a headache:
>
>it "should create the directory if it doesn't exist" do
> File.stubs(:exist?).with(@dir).returns false
> Dir.expects(:mkdir).with(@dir,0700)
> @provide
S --
I'm currrently looking at the specs for the ssh_authorized_key provider.
>> There are two tests that give me a headache:
>>
>>it "should create the directory if it doesn't exist" do
>> File.stubs(:exist?).with(@dir).returns false
>> Dir.expects(:mkdir).with(@dir,0700)
>> @
Brice --
> This is a rather complex set of structural changes. But to understand it
> you
> > really only need to grasp two key sections; the rest is cleanup.
>
> Can you explain for people like me that didn't had time to try to
> understand the patch what it brings, how (roughly) the internals
>
ct => ... )
after_application_run_command( :application_object => ... )
on_commandline_initialization(:command_line_object => ... )
on_application_initialization(:appliation_object => ... )
Paired-with: Daniel Pitman
Signed-off-by: Markus Roberts
---
lib/puppet/applicat
Signed-off-by: Markus Roberts
---
lib/puppet/application.rb |8
lib/puppet/util/command_line.rb | 20 +---
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/lib/puppet/application.rb b/lib/puppet/application.rb
index 5e69bae..a028a15 100644
fact that some one-step edges are now two-step edges and
tests, event propagation, etc. need to reflect that.
Paired-with: Jesse Wolfe
Signed-off-by: Markus Roberts
---
Local-branch: feature/next/resource_application_order
lib/puppet/resource/catalog.rb | 64 -
lib
0, #6810,
and #6944 which may simplify or complicate their resolution.
Paired-with: Jesse Wolfe
Signed-off-by: Markus Roberts
---
Local-branch: feature/next/resource_application_order
lib/puppet/simple_graph.rb|8 +++
lib/puppet/transaction.rb
The preceeding changes left some rough edges in the Transactions (a short,
badly named method that was only used in one place and would be clearer in-
line, a return value that was carfully retained and never used, etc.) This
commit clears some of that up.
Signed-off-by: Markus Roberts
---
Local
d the property used
to cheat Demeter which has the apropriate lifetime and can be used to hold the
state information durring a traversal.
Paired-with: Jesse Wolfe
Signed-off-by: Markus Roberts
---
Local-branch: feature/next/resource_application_order
lib/puppet/transaction.rb |
The previous commit left only one meaningful value for the method parameter
of generate_additional_resources, making it a constant not a parameter. This
commit removes it.
Paired-with: Jesse Wolfe
Signed-off-by: Markus Roberts
---
Local-branch: feature/next/resource_application_order
lib
aining the original semantic.
Paired-with: Jesse Wolfe
Signed-off-by: Markus Roberts
---
Local-branch: feature/next/resource_application_order
lib/puppet/resource/catalog.rb | 42
lib/puppet/transaction.rb | 107 ++--
lib/p
aired-with: Jesse Wolfe
Signed-off-by: Markus Roberts
---
Local-branch: feature/next/resource_application_order
lib/puppet/type.rb |8 +---
lib/puppet/type/file.rb |2 --
lib/puppet/type/tidy.rb |4 +++-
3 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/lib/p
This is a rather complex set of structural changes. But to understand it you
really only need to grasp two key sections; the rest is cleanup.
Cleanup commits:
The thrust of these is to localize the code that we are going to change (the
itterator over the dependency graph) and get all th
The recent AIX work added a dependency on Puppet::Parameter::Keyvalue in
the group type, but didn't add the requisite require, causing failures
under some load orders.
Signed-off-by: Markus Roberts
---
Local-branch: feature/next/resource_application_order
lib/puppet/type/group.rb |1
> We’re also going to introduce a concatenation function called “cat”.
>
Note there is already a concatenation operator in puppet (from
lib/puppet/parser/ast/leaf.rb):
class Concat < AST::Leaf
def evaluate(scope)
@value.collect { |x| x.evaluate(scope) }.collect{ |x| x ==
:undef ? ''
> +def self.title_patterns
> + [
> +# we have two title_patterns "name" and "name:protocol". We won't
> use
> +# one pattern (that will eventually set :protocol to nil) because
> we
> +# want to use a default value for :protocol. And that does only
> work
> +
D --
For some reason FileTest.exist? was returning false,
> and FileTest.directory? returns true.
> >>
> >> […]
> >>> At best, we have some leaky stubbing in a tests or some other
> confounding
> >>> factor (but nothing that should require changing lib-code); at worst,
> we
> >>> have so
L --
For some reason FileTest.exist? was returning false,
> and FileTest.directory? returns true.
>
>
> # Find this module in the modulepath.
> def path
> -environment.modulepath.collect { |path| File.join(path, name) }.find {
> |d| FileTest.exist?(d) }
> +environment.modulepath.collec
> >validate do |value|
> > raise Puppet::Error, "number has to be numeric, not #{value}"
> unless value =~ /^[0-9]+$/
> > -raise Puppet::Error, "number #{value} out of range" unless
> (0...2**16).include?(Integer(value))
>
> just out of curiosity: Will (0...2**16) generate
> I thing that recursive copies are the type that fits worst into the current
> code; I suggest we move that out and then wait and see if symlinks should
> follow or not.
>
The match with symlinks qua symlinks is pretty hideous as well. It just
looks a little less lumpy because it's been hammered
On Mon, Mar 21, 2011 at 8:23 AM, Todd Zullinger wrote:
> If xend is not running, xm list writes to stderr and facter propagates
> this to the user. Redirect stderr to /dev/null.
> ---
> lib/facter/util/xendomains.rb |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/
> This is mostly to Brice, but I figure others are interested.
>>
>> We've been looking at what it will take to get the network device support
>> prototype as implemented by Brice into core, along with the fact that we'll
>> be producing the RC1 for statler on April 13, and I don't think it will ma
> On Fri, Mar 18, 2011 at 11:36 AM, Markus Roberts
> wrote:
> > One thought, looking through the code (I haven't given it a thorough read
> > yet) is that it may make sense to split the MS Windows provider off from
> the
> > posixs provider (though that'
On Fri, Mar 18, 2011 at 12:07 PM, Jay Flowers wrote:
> I finally got some more time to work on this. I ended up getting RubyMine
> setup and configured for me to develop and debug with.
>
> I logged a bug on this:
> https://projects.puppetlabs.com/issues/6773
>
> If someone can give me a clue I
This is mostly to Brice, but I figure others are interested.
>
> We've been looking at what it will take to get the network device support
> prototype as implemented by Brice into core, along with the fact that we'll
> be producing the RC1 for statler on April 13, and I don't think it will make
> t
One thought, looking through the code (I haven't given it a thorough read
yet) is that it may make sense to split the MS Windows provider off from the
posixs provider (though that's out of scope here, I think).
-- M
---
When in trouble or in
>> I am very new to yaml so I have to research your suggestions. It
> >> sounds like I'll need to create an object for the yaml output to map
> >> to though.
> >>
> >> I'll respond back in the thread once I figure this out.
> >
> > It looks likr pyyaml does support loading foreign types (by mappin
On Tue, Mar 15, 2011 at 3:45 PM, Corey Osman wrote:
> I am very new to yaml so I have to research your suggestions. It
> sounds like I'll need to create an object for the yaml output to map
> to though.
>
> I'll respond back in the thread once I figure this out.
>
It looks likr pyyaml does supp
Corey --
I mentioned this before in a previous post but I can't find that post.
>
> Anyways, I am using the puppet api rest interface and my python yaml
> parser doesn't like the output given. Exactly what parser are you
> guys using to encode your objects into Yaml? I don't know why my
> parser
> # ACL is wide open
> path /
> #auth no
> allow *
>
>
> This finally worked. You were right about the trailing characters. I
> had a space after no and a space after the *. I removed the space and
> commented out the auth and I am able to get the data.
>
I've updated the ticket for this bug (
This is what I have in my auth.conf file:
>
> path /
> auth no
> allow *
>
>
> However I still get this error
>
> '/' incorrect authenticated value: no 0x15e56090>
>
So that looks like a puppet error message wrapped in a python error report.
So I'm assuming you saw this client side. If you run t
J --
On Sun, Mar 13, 2011 at 3:29 PM, Jay Flowers wrote:
> Markus,
> I found the getting the source page and am trying to follow it. I can
> install facter. I get the following error when trying to install puppet:
>
> C:\Projects\Puppet\puppet>ruby install.rb
> Missing ronn; skipping man page
Jay --
I am experiencing this bug: http://projects.puppetlabs.com/issues/6693.
>
> I would like to work on fixing this. How do I get setup to do this on a
> Windows box? I would like to get start trying to fix this, using it as a
> way to dive into Puppet development. Is there a wiki page on se
> Thinking about it though (and after looking at the code), do you need the
>> little bit at the top there to be executed? Why can't you just do something
>> like:
>>
>> Puppet::Util.expects(:execute).with { |command,options| ... }
>>
>>
> This was the first approach I tried. There were three
> - Vendor the "json_shape" library, a lightweight JSON schema validator (
> https://github.com/jes5199/json_shape).
>
> I'm fully in support of this proposal, with one caveat: The definition of
> 'vendor'. Do you mean creating a vendor directly in the puppet repo and
> adding it as a gem there,
P --
I'm not particularly proud of this code, but I don't see an alternative that
> I like better. Eliminating Puppet::Util::ExecutionStub in favor of a global
> variable seems very clumsy (not to mention that it would leave no place to
> put comments warning that it is intended for spec testing
Am I missing something, or is this:
--- /dev/null
> +++ b/lib/puppet/util/execution_stub.rb
> @@ -0,0 +1,26 @@
> +module Puppet::Util
> + class ExecutionStub
> +class << self
> + # Set a stub block that Puppet::Util.execute() should invoke instead
> + # of actually executing command
N --
What changed in 2.6.x with regard to functional settings in [environment]
> blocks?
>
> Have we documented the list of functional settings anywhere?
>
> What settings are currently not functional in an [environment] block and
> would be desirable to make functional?
>
I'm not sure I under st
So going back to the initial proposal that James made:
It occurs to me that the logical extension of a Dashboard RBAC system (or
perhaps even moving elements of the problem upstream) is for auth.conf to
recognize users or perhaps better "roles" as an authentication construct.
This seems like a ve
Trevor --
Thanks for the extended explanation. This is something that should be
> stuck up on the Type dev wiki.
>
> I'll try to get around to it, but no promises :-/.
>
At the point it was introduced (2.6.0) I believe we held back on publicly
documenting it because 1) it might be forced to chang
J --
> It occurs to me that the logical extension of a Dashboard RBAC system
> > (or perhaps even moving elements of the problem upstream) is for
> > auth.conf to recognize users or perhaps better "roles" as an
> > authentication construct.
> >
> >
> > I like. There would be some
J --
It occurs to me that the logical extension of a Dashboard RBAC system
> (or perhaps even moving elements of the problem upstream) is for
> auth.conf to recognize users or perhaps better "roles" as an
> authentication construct.
>
I like. There would be some details that should be sorted out
> 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 ] ]
>
>
> 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
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
/^
>
> > > 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,
> > 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
+1
On Wed, Mar 2, 2011 at 12:47 PM, James Turnbull wrote:
> This came from the use of the @@colormap class variable.
>
> The variables has been changed to a constant.
>
> Signed-off-by: James Turnbull
> ---
> lib/puppet/util/log/destinations.rb |6 +++---
> 1 files changed, 3 insertions(+),
On Wed, Mar 2, 2011 at 12:47 PM, James Turnbull wrote:
> The kick application has the option to ping hosts. On 1.9.x this
> code was returning "Invalid next". The next in this code has been
> replaced with an exit. Testing has confirmed this doesn't change the
> behavior of puppet kick.
>
+1
The
R.I. --
>> I'm not sure that the "how it got in there" part is irrelevant (for
>> instance, I'd like if you could confirm that state.yaml shows
>> type=>absent on a node that has not been upgraded, and note the
> yes, all my nodes have it - before upgrading. and people on IRC also
> has it witho
R.I. --
> > If :absent is there, I believe it was correct (that is, that the
> > > file really was absent).
>
> the file wasn't absent.
This is the thing we need to be trying to reproduce then.
also notice its :type not :ensure.
>
That's an implementation detail, which I don't think we need to
N --
> That is reassuring.
> >
> > I think if we peel away:
> >
> > * the "always auditing" bug
>
> Yes. I believe this is fixed by Jesse's patch you reviewed:
>
>
> https://github.com/puppetlabs/puppet/commit/e3dfe41ce7da108fc345e58c7df8c1576ea951a0
>
> > * the "audits notify" surprise
>
> This i
If you were on 2.6.4 (and probably earlier) and
> if you managed a file with the source parameter and
> if the local file was absent or content differed, we wrote out:
>
>!ruby/sym type: !ruby/sym absent
!ruby/sym owner: !ruby/sym absent
>
> to state.yaml, even if you weren't auditing.
I'm having trouble framing a response, in part because I think the question
is posed at the wrong level.
Specifically, rather than talking about the "symbols" that are being written
to state.yaml we should be asking about the conditions that they signify.
The question as posed sounds as if it's a
On Tue, Mar 1, 2011 at 9:05 AM, Dan Bode wrote:
> Hi Nick (long time :) )
>
> On Tue, Mar 1, 2011 at 3:14 AM, Nick Moffitt wrote:
>
>> I mean to write a lint checker for my manifests, but I am not a ruby
>> developer to any degree of proficiency. What I think I would like is
>> some kind of ser
> > > What are you updating from? Is it possibly that this is related to
> > > the update and not the audit bug...that is, if you update a node to
> > > a version with the audit bug fixed, such as the current 2.6.next
> > > (HEAD), does it restart the services?
> >
> > 2.6.4 release to 2.6.5 releas
> > What are you updating from? Is it possibly that this is related to
> > the update and not the audit bug...that is, if you update a node to
> > a version with the audit bug fixed, such as the current 2.6.next
> > (HEAD), does it restart the services?
>
> 2.6.4 release to 2.6.5 release. If I upd
R.I. --
> > Worse it seems changing auditing sends notifies:
> > >
> > > Mar 1 08:55:57 monitor2 puppet-agent[9797]:
> > > (/Stage[main]/Mcollective::Config/File[/etc/mcollective/policies/])
> > > Scheduling refresh of Service[mcollective]
> > > Mar 1 08:56:01 monitor2 puppet-agent[9797]:
> > >
I am not a DBA, but I've seen the following pattern play out many times: the
DBA says "normalize, normalize!" the developers say "normalizing is a pain,
and in this particular case it doesn't buy us much, etc." and down the road
the DBA turns out to have been right. Then the developers rediscover
B -
> + def self.listeners_of(label)
> > +synchronize {
> > + @listeners_of[label] ||= @listeners.select do |k,l|
> > +l.listen_to?(label)
> > + end
> > +}
> > + end
> >
> >
> > Does this (due to memoization) omit listeners who are added afte
B --
> 2) Would you get a more useful stack-trace without the rescue?
>
> Actually the first version didn't had the rescue, but I had some issues
> and I wanted to print the exception, it apparently escaped the garbage
> collection.
>
> Now, I thought that a straight raise would rethrow the except
B --
> + # Triggers an instrumentation
> + #
> + # Call this method around the instrumentation point
> + # Puppet::Util::Instrumentation.instrument(:my_long_computation) do
> + # ... a long computation
> + # end
> + #
> + # This will send an event to all the listeners of "my_long_
B --
Thoughts:
1) Wow.
> +def enable
> + raise "Probe already enabled" if enabled?
> + method = @method
> + label = @label
> + data = @data
> + klass.class_eval {
> +alias_method("instrumented_#{method}", method)
> +define_method(method) do |*args|
>
>> 2) you have to be careful with interpolation, in any case, as there are
> > scope changes to watch out for.
>
> Can you elaborate on this?
>
Sure. You can do this, and it works:
x = [1,2,3]
class << x
def sum_of_squares
collect { |x| x*x }.inject { |a,b| a+b }
end
end
p x.su
P & S --
The one I currently dont know how to address (besides splitting the
> current type in two fstab-only mount-only types) is #5991
>
I have to say that this one appeals to me a lot for some reason, though I'm
not as deep in the weeds as the two of you and may be missing subtleties. I
think
M --
Currently the storeconfigs tables dealing with facts look something
> like this (I've removed the columns that are irrelevant to the
> inventory service):
>
>create_table :hosts do |t|
> t.column :name, :string, :null => false
>end
>
>create_table :fact_names
B --
Thanks for the example. This is quite interesting and opens the door to
> a lot of strange things :)
>
Yes it does. Be sure to have a big stick handy when you open that door. :)
> I was thinking about allowing the user to describe probes by specifying
> a puppet class and a method throu
> There's also a 3rd thing I didn't started working on: allow the code to
> set probes dynamically (instead of statistically adding them by
> modifying puppet code). I don't know if ruby versatility can allow this,
> but I'd love to be able to instance_eval { ... add probes around a
> method ... }
N --
Do we want to cross post this on the user list?
-- M
On Wed, Feb 23, 2011 at 2:04 PM, Nick Lewis wrote:
> Our current plan for the inventory service is to provide active_record
> termini for the "facts" and "inventory" indirections. This is to support
> fast look-up of facts, and search o
L --
>>> BTW this is discussed a bit in Analysis Patterns by Martin Fowler as the
>>> operational layer and knowledge layer (where the classes are at the
>>> operational layer and the instances are the knowledge layer).
>>
>> Yeah. I like Martin's stuff in general but on this I've never found
>
L --
> BTW this is discussed a bit in Analysis Patterns by Martin Fowler as the
> operational layer and knowledge layer (where the classes are at the
> operational layer and the instances are the knowledge layer).
Yeah. I like Martin's stuff in general but on this I've never found
his distinct
L --
> I thought this design point would be interesting, assuming I can make it
> sufficiently clearly.
>
> I just did a refactor of my Interfaces work - previously, I had a base class
> of Puppet::Interface, and all interfaces were subclasses of that class.
>
> However, once Dan Bode asked for
On Mon, Feb 21, 2011 at 7:20 PM, Luke Kanies wrote:
> On Feb 21, 2011, at 6:00 PM, Thomas S Hatch wrote:
>
>> Thanks, thats what I thought, but I figure it is worth checking every now
>> and then. As the Arch Linux puppet maintainer I am looking forward to Ruby
>> 1.9 support since Arch is on r
On Sun, Feb 20, 2011 at 12:44 AM, donavan wrote:
> Is there a specific reason for forcing the log destination to :console
> in the agent application? If the log level is set with verbose/debug
> then :console is always added to any logdest the user specifies. I see
> bits of this in the applicati
On Sun, Feb 20, 2011 at 2:41 PM, Luke Kanies wrote:
> As I said on the ticket, I don't think this is necessary - all we need to
> do is add the module lib dirs to Ruby's search path.
>
> That way any library can be used, rather than having to specifically use
> any plugin system.
>
I just noted
On Fri, Feb 18, 2011 at 12:24 PM, Ian Ward Comfort wrote:
> On 18 Feb 2011, at 12:04 PM, Markus Roberts wrote:
> >> Heh, right. I was trying to think of a clean way to give types a way to
> say, "autorequire the first of these dependencies that's found in the
>
Heh, right. I was trying to think of a clean way to give types a way to say,
> "autorequire the first of these dependencies that's found in the catalog,
> and ignore the rest". Adding an autorequirefirst method would do it in a
> backwards-compatible way, but that feels icky.
>
Can you explain wha
C --
Is it possible that the output from the api url returns malformed YAML
> code? I have two YAML parsers that are choking on the same YAML
> output.
>
> I loaded the YAML output into this parser and it returned with an
> error.
>
> http://yaml-online-parser.appspot.com/
>
I just tried that pa
> Hudson wasn't notifying us when there was a test failure because
> fail_on_error was set to false. This appears to be because of a
> misconception that setting this to true caused the specs to run slower.
> That is not the case.
>
Not that it made the tests run slower, but that it caused the ge
On Mon, Feb 7, 2011 at 3:23 PM, Luke Kanies wrote:
> On Feb 7, 2011, at 3:11 PM, henrik lindberg wrote:
>
> > I noticed that the regexp for dollar variable in the lexer uses this
> > regexp - %r{\$(\w*::)*\w+}
> > which as I understand it would make a variable called $a
> > valid, is this
D --
The intent is to perform operations on catalogs from 0.25.x using the 2.6.x
>>> codebase.
>>>
>>> things like:
>>> - diffs
>>> - Writing filters (show me all resources, show me all Files)
>>> - eventually some more complicated things.
>>>
>>
>> So off the top of my head (& before coffee
D --
The intent is to perform operations on catalogs from 0.25.x using the 2.6.x
> codebase.
>
> things like:
> - diffs
> - Writing filters (show me all resources, show me all Files)
> - eventually some more complicated things.
>
So off the top of my head (& before coffee) we probably need
D --
Is there a method somewhere in puppet to convert 0.25.x catalogs into
> something that 2.6.x can interact with?
>
> I had to monkeypatch the resources:
>
> catalog.resources.each do |r|
> unless r.title
> # this is for 0.25 catalogs, this is ghetto,
> # but I thi
Daniel pointed out that I caught one hash-order time bomb and "fixed it with
extreme prejudice" but missed another. This change would address both with
a kinder touch:
diff --git a/spec/unit/util/zaml_spec.rb b/spec/unit/util/zaml_spec.rb
index 782ebdb..920e90e 100755
--- a/spec/unit/util/zaml_sp
iseration: Jesse Wolfe
Signed-off-by: Markus Roberts
---
lib/puppet/util/zaml.rb | 52 --
spec/unit/util/zaml_spec.rb | 26 -
2 files changed, 50 insertions(+), 28 deletions(-)
diff --git a/lib/puppet/util/zaml.rb b/lib/puppet/u
I spoke too soon. This patch breaks the case that motivated the
original change:
a = [1,2]
x = [a,a]
YAML.load(ZAML.dump(x))
will fail with this patch in place.
-- M
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to
L --
> My big question is just whether it's worth spending time trying to solve
> harder problems at this level rather than just skipping to the next level
> right away.
I'm not sure yet, but I'm pretty sure that skipping to the next level
without at least understanding the issues at this level
Luke:
> I think there's a lot of desire for these, but the reason people aren't
> doing it isn't a lack of use cases, it's (I think) a lack of people wanting
> to hack the core, or at least understanding how to do so.
I can believe that.
> Note that individual types can add metaparams, but they'l
Here's a question I doubt anyone is expecting.
Puppet presently provides the ability for types to define new
relationship metaparameters using code analogous to the standard four
(require, subscribe, notify, and before), like so:
newmetaparam(:before, :parent => RelationshipMetaparam, :attribut
> It sounds like this patch makes things better and not worse. It would be
> nice if in the future we tested our integration with both versions of the
> RRD library in some sort of non-unit test fashion (e.g. an acceptance test),
+1 on that idea.
> I put it on the ticket (#4726) in a comment sin
needed to be set.
Signed-off-by: Markus Roberts
---
lib/puppet/provider/user/user_role_add.rb |4 ++--
lib/puppet/provider/user/useradd.rb |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/puppet/provider/user/user_role_add.rb
b/lib/puppet/pro
-1 on the patch; Luke's pointed out a much cleaner way to fix the
issue; I'll re-fix and resubmit.
-- M
---
When in trouble or in doubt, run in circles,
scream and shout. -- 1920's parody of the
maritime general prudential rule
--
L --
> This might be out of scope for this patch, but do we really need a 'retrieve'
> method here? It looks like the method is very similar to the default method.
>
> We haven't made this a hard requirement yet, but one of the goals Nigel and I
> have been talking about is making the existing
P --
> If this is getting missed, isn't that an indication that this is too
> much cluttered and should be more centralized? I didn't look in the code
> and I'm just asking that because of your commit message.
>
> Otherwise I tested the patch and it fixed my problem.
The problem was that it was c
s the lookup
to AST::Collection nodes in the same way it was added to the other node types.
Note that I haven't audited the other note types for similar cases.
Signed-off-by: Markus Roberts
---
lib/puppet/parser/ast/collection.rb |3 ++-
spec/unit/parser/ast/collection_spec.rb |
My code smell routines bobbled this one, so I'm fixing it manually.
Signed-off-by: Markus Roberts
---
lib/puppet/parser/ast/collection.rb | 84 ++-
1 files changed, 33 insertions(+), 51 deletions(-)
diff --git a/lib/puppet/parser/ast/collection.rb
The newly added password age properties didn't implement a retrieve method and
thus never got the current value from the provider. It therefore was always
seens as :absent and so puppet always thought it needed to be set.
Signed-off-by: Markus Roberts
---
lib/puppet/type/user.rb |
> +1. Note that whoever merges this into next or master will have merge
> conflicts with my patch for the same ticket.
Did you patch #5289 on master/next? If so, I'm not seeing it. If by
"this" you mean 2.6.x and by "the same ticket" you mean #4894 then a)
it won't be any worse than before, sin
error rather
than retrying.
Also fixed the spelling of "simultaneous."
Signed-off-by: Markus Roberts
---
.../indirector/bucket_file/rest_spec.rb|3 ++-
.../certificate_revocation_list/rest_spec.rb |3 ++-
spec/integration/indirector/rest_spec.rb |
1 - 100 of 1042 matches
Mail list logo
