On Mon, Feb 16, 2009 at 7:53 AM, Luke Kanies wrote:
> It makes sense, I'm just concerned about the repercussions. Is it
> unreasonable for people to want to override a given parameter more
> than once?
Yes, if it happens outside of a class hierarchy.
> I'm torn here, because I agree that the i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A new Facter release is available - 1.5.4.
This is a maintenance release that will be the last of the 1.5.x branch.
It combines a number of fixes, a new fact - physicalprocessorcount,
and support for flavours of Oracle Linux.
Full list of change
On Feb 16, 2009, at 6:03 PM, Paul Nasrat wrote:
>
>> Based on our discussions from our last dev call, I think the branch
>> should instead be called 'next', rather than '1.anything'.
>
> Indeed.
>
>> I'll make and publish such a branch right now.
>
> Thanks I'll start going over the tickets and g
> Based on our discussions from our last dev call, I think the branch
> should instead be called 'next', rather than '1.anything'.
Indeed.
> I'll make and publish such a branch right now.
Thanks I'll start going over the tickets and generating new ones
shortly after (maybe tomorrow)
Paul
--~-
On Feb 16, 2009, at 5:53 PM, Paul Nasrat wrote:
>
>> I would maybe describe this as 'setting TTL on fact values' or
>> something similar -- the TTL is the critical bit, since we're already
>> caching values.
>
> Yeah.
>
>> That seems to be it. Let us know when you're done. :)
>
> Will start when
> I would maybe describe this as 'setting TTL on fact values' or
> something similar -- the TTL is the critical bit, since we're already
> caching values.
Yeah.
> That seems to be it. Let us know when you're done. :)
Will start when I can see 1.9.x branch in say github.com/reductivelabs/facter
On Feb 16, 2009, at 1:35 PM, Paul Nasrat wrote:
>
> I've tried to capture all the key features I've seen in this thread
> below to eventually translate into feature requests/stories:
>
> * Namespaces
> * Hierachical grouping
> * Collapsing information for coarse grained logic (has_interface?)
> *
Luke Kanies writes:
> I'm torn here, because I agree that the inheritance system has gotten in
> the way too often, but I'm not sure that just removing the concept of
> inheritance is the correct move.
>
> Anyone else have any opinions about this? Anyone see other ways to
> reduce the complexit
On Feb 16, 2009, at 1:12 PM, Paul Nasrat wrote:
>
> 2009/2/16 Luke Kanies :
>>
>> Are these changes to ENV done in the same process or in a subprocess
>> after a fork?
>>
>> If they're they same process, they should probably clean the value up
>> to its previous value.
>
> The patch does that by
I've tried to capture all the key features I've seen in this thread
below to eventually translate into feature requests/stories:
* Namespaces
* Hierachical grouping
* Collapsing information for coarse grained logic (has_interface?)
* External fact loading mechanisms (note I think these depend o
2009/2/16 Luke Kanies :
>
> Are these changes to ENV done in the same process or in a subprocess
> after a fork?
>
> If they're they same process, they should probably clean the value up
> to its previous value.
The patch does that by setting @rubylib and restoring it after:
>> +@rubylib
> Oh, one more thing -- this isn't required or anything, but it would be
> simpler to read this commit series if you ran it through 'rebase -i
> master, and squashed paired commits.
I've added a note on the DevelopmentLifecycle to let people who may
not know about rebase -i they can and should do
On Feb 14, 2009, at 4:17 PM, Brice Figureau wrote:
>
> On 14/02/09 17:45, Brice Figureau wrote:
>> Signed-off-by: Brice Figureau
>> ---
>> bin/pi | 223
>> +---
>> bin/pi => lib/puppet/application/pi.rb | 99 ++-
>> spec/
On Feb 6, 2009, at 1:30 PM, Brice Figureau wrote:
>
> On 5/02/09 23:26, Luke Kanies wrote:
>> On Feb 5, 2009, at 4:18 PM, Brice Figureau wrote:
>>
>>> I know I assigned the bug to Luke, but I had 5 spare minutes
>>> tonight, and
>>> wanted to try to solve this as this is affecting me.
>>> So far
Nice.
On Feb 14, 2009, at 10:45 AM, Brice Figureau wrote:
>
> Signed-off-by: Brice Figureau
> ---
> lib/puppet/application/filebucket.rb|5 -
> lib/puppet/application/puppet.rb|5 -
> lib/puppet/application/puppetca.rb |3 ---
> lib/puppet/application/puppetd.r
On 16/02/09 18:17, Luke Kanies wrote:
> On Feb 14, 2009, at 10:45 AM, Brice Figureau wrote:
>
>> Hi,
>>
>> I'm proud to announce I've finished my work on the Application
>> Controller
>> refactoring. It is based on (a rather) current master (so it is on
>> top of #1405).
>>
>> I tested all ap
I don't think it should be done as part of this commit series, but
this executable is clearly ripe for refactoring, now that it's
migrated and tested.
That's a lot of long methods.
On Feb 14, 2009, at 10:45 AM, Brice Figureau wrote:
>
> Signed-off-by: Brice Figureau
> ---
> bin/puppetrun
On Feb 14, 2009, at 10:45 AM, Brice Figureau wrote:
>
> Hi,
>
> I'm proud to announce I've finished my work on the Application
> Controller
> refactoring. It is based on (a rather) current master (so it is on
> top of #1405).
>
> I tested all applications before the rebasing so I'm pretty
>
On Feb 14, 2009, at 10:45 AM, Brice Figureau wrote:
> Hi,
>
> I'm proud to announce I've finished my work on the Application
> Controller
> refactoring. It is based on (a rather) current master (so it is on
> top of #1405).
>
> I tested all applications before the rebasing so I'm pretty
> c
Hi Luke,
On 16/02/09 17:16, Luke Kanies wrote:
> Looks good.
Thanks
> I'm not sure how worth it is to go through and do point-by-point
> reviews here, since there's such a huge amount of code, but I'll do
> what I can.
OK, fair enough :-)
> Note that the overall code is great, and I'd acc
On Feb 14, 2009, at 10:45 AM, Brice Figureau wrote:
>
> Signed-off-by: Brice Figureau
> ---
> bin/puppet | 191 +
> lib/puppet/application/puppet.rb | 151
> spec/unit/application/puppet.rb | 291 +
I would like to reiterate, great work, this makes the executables so
much more maintainable.
On Feb 14, 2009, at 10:45 AM, Brice Figureau wrote:
>
> Signed-off-by: Brice Figureau
> ---
> bin/filebucket | 122 +--
> lib/puppet/application/filebucket.rb |
Holy crap this is awesome.
Really, the whole CA Interface class should be pulled into this
application -- it's essentially duplicate functionality, now that
you've got this.
But that can be done at a later date.
On Feb 14, 2009, at 10:45 AM, Brice Figureau wrote:
>
> Signed-off-by: Brice
Looks good.
I'm not sure how worth it is to go through and do point-by-point
reviews here, since there's such a huge amount of code, but I'll do
what I can.
Note that the overall code is great, and I'd accept the patches as
they are now. These are just little points. I think there are ju
On Feb 14, 2009, at 1:51 PM, Eric Gerlach wrote:
>
> On Fri, Feb 13, 2009 at 09:52:38AM -0600, Luke Kanies wrote:
>>
>> On Feb 11, 2009, at 6:08 PM, Eric Gerlach wrote:
>>
>>>
>>> Hi all,
>>>
>>> I know that I might be breaking some ettiquette by posting a patch
>>> without
>>> lurking first, but
On Feb 15, 2009, at 7:20 PM, Robin Sheat wrote:
>
> I'm interested in the idea of using S3 as a file source for puppet, so
> you could have something like:
>
> file { "/etc/myfile.conf":
>source => "s3://bucket/path/to/myfile.conf",
>...
> }
>
> There are ruby libraries out there that wor
On Feb 13, 2009, at 6:32 PM, Paul Lathrop wrote:
>
> On Fri, Feb 13, 2009 at 4:07 PM, Luke Kanies wrote:
>> I don't know that it's a subtlety; there are cases where you'd want
>> to
>> override a given parameter multiple times; linux, then debian, then
>> ubuntu, for instance.
>>
>> I agree th
Are these changes to ENV done in the same process or in a subprocess
after a fork?
If they're they same process, they should probably clean the value up
to its previous value.
On Feb 12, 2009, at 10:30 AM, Paul Nasrat wrote:
>
> This patch fixes up the puppetmasterd tests to run locally.
>
28 matches
Mail list logo
