On Thu, Mar 11, 2010 at 3:36 AM, Brice Figureau
brice-pup...@daysofwonder.com wrote:
On Wed, 2010-03-10 at 23:09 -0500, Michael DeHaan wrote:
On Wed, Mar 10, 2010 at 9:07 PM, Ohad Levy ohadl...@gmail.com wrote:
I think that the main issue for me for running puppet as a daemon is its
memory
On Thu, Mar 11, 2010 at 2:54 AM, James Turnbull ja...@lovedthanlost.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/10 1:51 AM, Michael DeHaan wrote:
No, I haven't.
I'm curious as to feedback on the idea/implementation.
Tests can be added.
Mike
Actually I tend to
Hi Michael,
On Thu, 2010-03-11 at 09:11 -0500, Michael DeHaan wrote:
On Thu, Mar 11, 2010 at 3:36 AM, Brice Figureau
brice-pup...@daysofwonder.com wrote:
On Wed, 2010-03-10 at 23:09 -0500, Michael DeHaan wrote:
On Wed, Mar 10, 2010 at 9:07 PM, Ohad Levy ohadl...@gmail.com wrote:
I think
On Wed, Mar 10, 2010 at 8:04 PM, Michael DeHaan
mich...@reductivelabs.com wrote:
Can we take this just a little bit further and look at a simple plugin
architecture?
When we have to support more than one database type we should do it
modularly, but I didn't want
to overdesign it in the
On Thu, Mar 11, 2010 at 10:13 AM, Nigel Kersten nig...@google.com wrote:
On Wed, Mar 10, 2010 at 8:04 PM, Michael DeHaan
mich...@reductivelabs.com wrote:
Can we take this just a little bit further and look at a simple plugin
architecture?
When we have to support more than one database type
It's already on the roadmap and as an issue, but we need to fix facter
HEAD first.
Revisiting the facter bugs list, I don't see it as particularly in bad
shape now that this fact is reverted.
All tests pass for me on Ubuntu 9.10, for instance, though I've not
begun wider testing.
We've got a
On Thu, Mar 11, 2010 at 1:12 PM, Michael DeHaan
mich...@reductivelabs.com wrote:
It's already on the roadmap and as an issue, but we need to fix facter
HEAD first.
Revisiting the facter bugs list, I don't see it as particularly in bad
shape now that this fact is reverted.
This should read
On Wed, Mar 10, 2010 at 7:42 PM, Nigel Kersten nig...@google.com wrote:
Can we take this just a little bit further and look at a simple plugin
architecture?
+1 on this, Nigel. I've made a point in developing Dashboard of avoiding any
specific coupling to Dashboard on the Puppet side. We don't
On Mar 10, 2010, at 7:42 PM, Nigel Kersten wrote:
On Wed, Mar 10, 2010 at 6:09 PM, Ohad Levy ohadl...@gmail.com wrote:
I like the idea, would you consider adding an option to query
foreman as
well?
Foreman has already a lib for querying hosts, which could be done
as simply
as the
On 11 March 2010 18:12, Michael DeHaan mich...@reductivelabs.com wrote:
It's already on the roadmap and as an issue, but we need to fix facter
HEAD first.
Revisiting the facter bugs list, I don't see it as particularly in bad
shape now that this fact is reverted.
Yup I want to get 1.5.8 rc1
Michael,
Things like glob parsing are both inherently testable and prone to errors.
And, with respect, I don't know how to test this is not a valid argument
for not testing. I'd be happy to talk to you about Puppet testing
methodologies to the extent that they exist and that I am aware of them.
You know we have hudson and can kick off tests on a bunch of *nix
platforms on EC2, right? I'd like to get this going on commit, have
the instances moved over to a RL backed account rather than James'
personal one?
Not sure what the details are there, I can follow up with James.
Not
On Thu, Mar 11, 2010 at 1:56 PM, Rein Henrichs r...@reductivelabs.com wrote:
Michael,
Things like glob parsing are both inherently testable and prone to errors.
Dir.glob is prone to errors?
Personally, I think Puppet needs better testing methodologies just as much
as it needs more and better
On Mar 10, 2010, at 8:09 PM, Michael DeHaan wrote:
On Wed, Mar 10, 2010 at 9:07 PM, Ohad Levy ohadl...@gmail.com wrote:
I think that the main issue for me for running puppet as a daemon
is its
memory consumption.
e.g. if you have a VM with 256/512MB of RAM, puppet cant take
40-60% of
On Mar 11, 2010, at 6:17 AM, Michael DeHaan wrote:
On Thu, Mar 11, 2010 at 2:54 AM, James Turnbull ja...@lovedthanlost.net
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/10 1:51 AM, Michael DeHaan wrote:
No, I haven't.
I'm curious as to feedback on the idea/implementation.
On Thu, Mar 11, 2010 at 2:50 PM, Luke Kanies l...@reductivelabs.com wrote:
On Mar 11, 2010, at 6:17 AM, Michael DeHaan wrote:
On Thu, Mar 11, 2010 at 2:54 AM, James Turnbull ja...@lovedthanlost.net
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/10 1:51 AM, Michael DeHaan
On Mar 9, 2010, at 2:08 PM, Michael DeHaan wrote:
Also cleaned up a few error messages (unrelated)
---
lib/puppet/application/puppetrun.rb | 12 ++-
lib/puppet/daemon.rb|2 +-
lib/puppet/network/server.rb|2 +-
lib/puppet/util/runner.rb | 53
On Mar 9, 2010, at 10:56 PM, Paul Nasrat wrote:
On 10 March 2010 06:41, Luke Kanies l...@reductivelabs.com wrote:
On Mar 9, 2010, at 10:35 PM, Paul Nasrat wrote:
On 10 March 2010 03:56, Nigel Kersten nig...@google.com wrote:
On Tue, Mar 9, 2010 at 5:52 PM, Luke Kanies
A dependency on rake = 0.8.4 was added to the Dashboard to fix issue #2897,
caused by a missing reenable method on Rake::Task. Rake's release notes [1]
indicate that this method was added in 0.8.2. The Rails frozen in vendor/
require rake = 0.8.3. Since EPEL currently ships Rake 0.8.3, it would be
On 11 Mar 2010, at 5:35 PM, Ian Ward Comfort wrote:
A dependency on rake = 0.8.4 was added to the Dashboard to fix
issue #2897,
caused by a missing reenable method on Rake::Task. Rake's release
notes [1]
indicate that this method was added in 0.8.2. The Rails frozen in
vendor/
require rake
Anyone know what caused us to choose 0.8.4 in the first place?
As long as this actually works, then I'm fine with this.
On Mar 11, 2010, at 5:35 PM, Ian Ward Comfort wrote:
A dependency on rake = 0.8.4 was added to the Dashboard to fix
issue #2897,
caused by a missing reenable method on
as far as I know, rails cant dump the db/schema.rb without this method
undefined method `reenable' for Rake::Task db:schema:dump =
[environment]:Rake::Task
nevertheless, I don't think its a big deal, if your code comes already with
a schema.db (which is not suppose to be changed by users
On 11 Mar 2010, at 10:17 PM, Ohad Levy wrote:
as far as I know, rails cant dump the db/schema.rb without this method
undefined method `reenable' for Rake::Task db:schema:dump =
[environment]:Rake::Task
As the commit message indicates, this method was added in Rake 0.8.2.
On Fri, Mar 12,
Thanks. +1, then.
On Mar 11, 2010, at 10:29 PM, Ian Ward Comfort wrote:
On 11 Mar 2010, at 10:17 PM, Ohad Levy wrote:
as far as I know, rails cant dump the db/schema.rb without this
method
undefined method `reenable' for Rake::Task db:schema:dump =
[environment]:Rake::Task
As the
I'm pretty uncomfortable with this patch. Does it replace the direct
ldap integration? If I used it with external nodes, what would
happen? Do we expect our users to maintain these files in addition to
their external nodes system?
I'd much rather make sure that Node.search behaves like
25 matches
Mail list logo
