c to 10am Pacific. Hopefully that will be a better time for some to
> join in.
>
> What: PR Triage
> When: Feb 11, 2014 @ 10:00 Pacific/18:00 GMT/19:00 CET
> Where: Hangout @ http://links.puppetlabs.com/pr-triage
>
> --
> Andrew Parker
> a...@puppetlabs.com
> Free
On Feb 20, 2013, at 6:57 AM, Adrien Thebo wrote:
> One clarification - this file is a configuration file but it's going to be
> static, and specifically non-editable by the user. /usr being mounted as
> read-only in this case would be fine. Effectively we're vendoring a static
> file that sh
On Feb 19, 2013, at 2:47 AM, Nan Liu wrote:
>>> I'll admit, though, that puppet doesn't really have a concept of an "in
>>> progress" convergence of a resource, so I'm not sure how the report will
>>> work out for these kinds of resources. I suspect that it would show a
>>> change every time t
). That fits
our updated contributor guidelines and also helps us to comment on submissions
more easily.
Thanks,
Andrew Parker
On Jul 30, 2012, at 7:37 PM, swfan wrote:
> just tried facter under a system wpar (for sun folks, equiv of sun zones)...
> it fails. it cannot detect swap siz
On Jul 29, 2012, at 2:41 PM, Luke Kanies wrote:
> On Jul 28, 2012, at 2:04 PM, Ken Dreyer wrote:
>
>> I recently opened my first pull request [1], against master. After
>> re-reading CONTRIBUTORS.md I see that Puppet prefers to merge bug
>> fixes into the earliest branch first (eg 2.6.x or 2.7.
es :) They make programming hard and
world communications difficult.
On Jul 24, 2012, at 1:47 PM, Brice Figureau wrote:
> On 24/07/12 18:31, Andrew Parker wrote:
>> Although running the tests is important it isn't really the slowest
>> part of the whole thing (although
What version of puppet are you using? Also, what do you get if you run it with
--trace?
On Jul 24, 2012, at 11:06 AM, Matthew Probst wrote:
> I'm having a difficult time with a custom function:
>
> module Puppet::Parser::Functions
> newfunction(:subpaths, :type => :rvalue) do |args|
> re
een toying with the idea of setting up an "offices hours" where people
can sign up for time with someone here at Puppet Labs. Then talk on IRC or
Skype about the change and work out together what needs to be done.
On Jul 23, 2012, at 11:44 PM, David Schmitt wrote:
> On 23.07.2012 18:
Yeah, there is a problem with getting pull requests reviewed. And I think you
are right, the problem stems from being short staffed for responding to these
things. A pull request can take considerable amount of time to review and
shepherd through (or it can take very little time if it is good, c
On Jul 6, 2012, at 2:07 AM, Brice Figureau wrote:
>
>> By moving a couple of things around I think we can cache those calls
>> instead of needing to keep the cache of not found types. We'll keep
>> you posted on what we come up with.
>
> Thanks, I'm looking forward to that!
Brice, maybe you ca
On Jul 5, 2012, at 2:20 PM, Brice Figureau wrote:
>>
>> Absolutely agree. Andy and team are working hard on exactly this.
>
> That's really good. I'm going to try to profile one of my largest node
> agent (in noop mode) to see what it gives. This might point to some part
> of the code that we
As Deepak said, we are taking a look over Brice's patches right now. Initially
we'll target them at 3.0 and then we'll probably move on to back porting and
tuning a bit on 2.7 after we have 3.0 stabilized. At the same time we have been
taking a look at the catalog retrieval time problem. Based o
hrough the cracks.
Thanks,
Andrew Parker
On Jun 28, 2012, at 10:03 AM, swfan wrote:
> Greetings folks
> Had not seen this in the facter 1.6.X branch, and I did not see it in the 2.x
> branch either (may have missed it). Posted this to the puppet-users group,
> did not realize it was pr
I imagine that the fix would have to work with the two purposes of generating
the documentation that I'm seeing here: general docs expressing all possible
features and when they are available, and more specific docs that express what
is currently available on a particular system. I would guess t
Thanks for asking about this, it is a topic that needs a bit of thought. What
you'll find, I suspect, is that there is little agreement on a topic like this
:) But here is my take.
First off, we need to be careful with terminology. An acceptance test is a test
that is worked out with a stakehol
pect that
many of the things in 3.0 will also apply to 2.7. I'll likely try to have us
concentrate on getting 3.0 sorted out and then back port those to 2.7 in a
later release so that we don't take on too much at once.
>
> Thanks,
>
> Trevor
>
> On Tue, Jun 12, 2012 a
e have all functionality regressions out of the way,
we are going to start looking into profiling and tuning. Even then, if any
functionality regressions are brought up, we'll jump on them immediately.
On Jun 11, 2012, at 5:13 PM, Andrew Parker wrote:
> An update of the status of the va
On Jun 12, 2012, at 3:47 AM, Trevor Vaughan wrote:
> Hi Jo,
>
> I've experienced some of the same issues that you're highlighting
> while using Puppet internally at my company.
>
> My experience has shown:
>
> 1) 2.7 does slow things down significantly
Unfortunate, but true. If I understand co
Good point on the positives. I feel like I have to think too hard about what
'unless_system_user => true' means. Being able to give purge some sort of
structure (that can include negative expressions) of what to purge seems like a
nice way of solving this.
On May 22, 2012, at 1:07 PM, Philip B
the Puppet 3.0.0 docs will
> have more details when they are published.
>
> Puppet 3.0.0rc1 includes contributions from the following people:
> 20after4, Aditya Patawari, Andrew Parker, Ben Ford, Brice Figureau,
> Bruno Léon, Cameron Thomas, Carl Caum, Carla Souza, Chris Price,
&g
Thanks for looking into this. Could you send the traces that you are seeing and
the command that you are executing in irb?
On May 17, 2012, at 10:56 AM, Trevor Vaughan wrote:
> As I've been playing with more optimization factors, I'm noticing that
> the 'service' type appears to be quite slow.
>
Since the language already has boolean logic expressions
(http://docs.puppetlabs.com/guides/language_guide.html#expressions), it seems
like what we are looking for is maybe some way of treating expressions as
first-class and being able to pass them as parameters in order to be evaluated
later.
That ticket (#2892) is about the amount of memory being used during conversion.
Is that still the problem? Or is the problem really now centered around the
amount
of time that the conversion is taking? Either way using JSON all the way through
would probably fix both problems.
On May 15, 2012, at
Jeff came over and asked Daniel and I about this. He might be able to give his
understanding, as well. My response is below.
On May 9, 2012, at 2:26 PM, Kelsey Hightower wrote:
> On Tuesday, May 8, 2012 7:17:33 PM UTC-4, Andy Parker wrote:
> I'll chime in on this now, I suppose.
>
> You are rig
I'll chime in on this now, I suppose.
You are right that both read and write operations are good for abstraction. The
problem comes that comes into play is that read and write operations usually
end up with completely different needs for their abstractions and so combining
them together in a si
It can also be asked as "is passing nil or undefined as the value of a class
parameter the same as not specifying that class parameter at the point of use
at all?"
This way of phrasing it makes me think twice about this behavior, because it
now means that you can't look just at the point of us
On Apr 19, 2012, at 1:49 PM, R.I.Pienaar wrote:
>
>
> - Original Message -
>> From: "Andrew Parker"
>> To: puppet-dev@googlegroups.com
>> Sent: Thursday, April 19, 2012 9:43:36 PM
>> Subject: Re: [Puppet-dev] Changes to variable scoping in T
On Apr 19, 2012, at 1:28 PM, R.I.Pienaar wrote:
>
>
> - Original Message -
>> From: "Andrew Parker"
>> To: puppet-dev@googlegroups.com
>> Sent: Thursday, April 19, 2012 8:42:33 PM
>> Subject: Re: [Puppet-dev] Changes to variable scoping in Te
ut.
https://github.com/zaphod42/puppet/tree/feature/13970/remove-dynamic-scoping
On Apr 19, 2012, at 11:45 AM, R.I.Pienaar wrote:
>
>
> - Original Message -----
>> From: "Andrew Parker"
>> To: puppet-dev@googlegroups.com
>> Sent: Thursday, April
On Apr 19, 2012, at 11:45 AM, R.I.Pienaar wrote:
>
>
> - Original Message -
>> From: "Andrew Parker"
>> To: puppet-dev@googlegroups.com
>> Sent: Thursday, April 19, 2012 7:16:40 PM
>> Subject: Re: [Puppet-dev] Changes to variable scoping in T
On Apr 19, 2012, at 10:58 AM, Jo Rhett wrote:
> On Apr 19, 2012, at 9:24 AM, Andrew Parker wrote:
>> What do you do with inheritance (classes or nodes) wrt variables? Avoid?
>> Using a lot? Have a specific pattern that you follow?
>
> I have used inheritance for overridi
On Apr 19, 2012, at 9:38 AM, R.I.Pienaar wrote:
> - Original Message -
>> From: "Andrew Parker"
>> To: puppet-dev@googlegroups.com
>> Sent: Thursday, April 19, 2012 5:30:29 PM
>> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
>&g
On Apr 19, 2012, at 1:21 AM, Ken Barber wrote:
>> If I want a top-level variable, I'll ask for one. If I want a node-level
>> variable, I'd like to be able to ask for one (which I can't today afaik). I
>> never want either of them unless I ask for them by name.
>>
>> Yes, I do. Or an option to e
On Apr 18, 2012, at 4:27 PM, Jo Rhett wrote:
> On Apr 18, 2012, at 4:04 PM, Andrew Parker wrote:
>>> On Apr 17, 2012, at 9:00 AM, Andrew Parker wrote:
>>>> Has anyone seen something where a manifest used $::var in order to *not*
>>>> get the value
On Apr 18, 2012, at 3:20 PM, Jo Rhett wrote:
> On Apr 17, 2012, at 9:00 AM, Andrew Parker wrote:
>> Has anyone seen something where a manifest used $::var in order to *not* get
>> the value of $var that is overridden in a node?
>
> Uh… I use it extensively.
Ah, interesti
On Apr 18, 2012, at 8:47 AM, R.I.Pienaar wrote:
> Puppet is pretty frustrating, without years of using it its just really
> hard to grasp some of the problems people have with the language. A
> suggestion or statement about what is "never needed" is often incorrect
> coming from someone who stu
node scope because any
code that would want to do that will be under the user's control and so will
the node scoped variables.
On Apr 17, 2012, at 3:36 PM, R.I.Pienaar wrote:
>
>
> - Original Message -----
>> From: "Andrew Parker"
>> To: puppet-dev@go
On Apr 17, 2012, at 1:31 PM, R.I.Pienaar wrote:
> - Original Message -
>> From: "Andrew Parker"
>> To: puppet-dev@googlegroups.com
>> Sent: Tuesday, April 17, 2012 9:21:23 PM
>> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
>>
On Apr 17, 2012, at 10:08 AM, R.I.Pienaar wrote:
>
> We then started going down the route of saying all this leaky scope stuff
> is bad, its magical, its non deterministic, when you read a piece of code
> you have no idea what data you are actually looking at. Is it a fact, or
> a variable, a
On Apr 17, 2012, at 9:21 AM, James Turnbull wrote:
>
> Whilst I'm not so keen on the @facts syntax I agree with RI. We already
> have magic variables (which have changed their magical properties
> several times since my involvement with the project) we don't need
> anymore magic.
>
Since one pe
On Apr 17, 2012, at 9:15 AM, R.I.Pienaar wrote:
>>
>> What I am trying to address is issue of what it means for a node to
>> shadow a top-scope variable. Another possible solution is that we
>> just remove node from the language. Then the entire issue goes away,
>> but everything is still possibl
On Apr 17, 2012, at 2:03 AM, R.I.Pienaar wrote:
> I like the general idea for sure, but I think it still leaves way too much
> magic and layering and things that kind of needs to be studied to be
> understoof
> rather than just be obvious.
>
> So I'd like to just mention that a few of us thinks
yone seen something where a manifest used $::var in order to *not* get
the value of $var that is overridden in a node?
> On Apr 16, 2012 10:20 PM, "Andrew Parker" wrote:
> As I hope everyone is aware, we are planning on removing dynamic scoping in
> Telly (http://docs.puppetl
On Apr 16, 2012, at 2:47 PM, Eric Sorenson wrote:
> On Apr 16, 2012, at 2:19 PM, Andrew Parker wrote:
>
>> $var is going to evaluate to "node". If you change that to $::var, then
>> you'll end up with "top scope". This doesn't seem right a
As I hope everyone is aware, we are planning on removing dynamic scoping in
Telly (http://docs.puppetlabs.com/guides/scope_and_puppet.html). We know that
the deprecation warnings that puppet 2.7 has been issuing have been wrong, but,
hurray!, there is a fix going in for that! However, there is s
I just recently started working at Puppet Labs and have been pretty much been
ignoring most of what I see from this list because of the amount of github mail
on it. I think that removing the github email from this list will help it to do
what I'm hoping to see on it, which is to have discussions
It seems like we should just allow "magic removal" ala \$ to get a literal
dollar sign.
On Apr 11, 2012, at 1:08 PM, Jeff Weiss wrote:
> Community contribution to bypass variable interpolation.
>
> Before I merge, I have a few concerns:
> 1. We're making a specific exemption for dbpassword.
>
Retroactively deprecating functionality seems like an odd thing to do. From my
standpoint of a user of software I wouldn't expect that features of a minor
version were deprecated in a patch release in order to be removed at the next
major/minor release.
On Apr 2, 2012, at 9:25 AM, Chris Price w
48 matches
Mail list logo
