On Sat, Feb 13, 2010 at 4:29 AM, Trevor Vaughan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Inline
>
>>> - - I would have it be a stand alone application, not an add-on to the
>>> primary puppet daemon. The reason for this is that many of us use puppet
>>> from cron instead of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Inline
>> - - I would have it be a stand alone application, not an add-on to the
>> primary puppet daemon. The reason for this is that many of us use puppet
>> from cron instead of as a daemon for various reasons.
>
> Interesting yeah, in that ca
On 2/12/10 2:10 AM, Alan Barrett wrote:
Not exactly, but that would probably be acceptable. What actually
happens today is that puppetd is not run at all on the client unless an
authorised change is known to be ready for deployment; then puppetd is
run in --noop mode to verify that the changes i
On Thu, 11 Feb 2010, Scott Smith wrote:
> >Of course there are change control procedures for getting the manifests
> >updated on the puppetmaster, but that's not enough; it's also necessary
> >to run the puppet client only when specifically authorised. For
> >example, the manifest update and a --n
Hi,
May I recommend that you have a look at the ext directory for
puppetlisten/puppetrun[1], this two scripts I wrote a while ago reuse puppet
certificate infrastructure to trigger remote runs.
additionally, I've created a query interface in foreman[2], which could
probably give you some ideas of
Alan Barrett wrote:
On Wed, 10 Feb 2010, Michael DeHaan wrote:
We're attempting to provide a reason to not use cron :)
I have a requirement that puppet may not change anything on a production
host without change control approval in advance. It would be nice if a
new version of puppet had bett
On Wed, 10 Feb 2010, Michael DeHaan wrote:
> We're attempting to provide a reason to not use cron :)
I have a requirement that puppet may not change anything on a production
host without change control approval in advance. It would be nice if a
new version of puppet had better support for this us
On Wed, Feb 10, 2010 at 5:56 PM, Trevor Vaughan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> My thoughts:
>
> - - I would have it be a stand alone application, not an add-on to the
> primary puppet daemon. The reason for this is that many of us use puppet
> from cron instead of as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My thoughts:
- - I would have it be a stand alone application, not an add-on to the
primary puppet daemon. The reason for this is that many of us use puppet
from cron instead of as a daemon for various reasons.
- - I do have to wonder how this is muc
On Wed, Feb 10, 2010 at 5:30 PM, Scott Smith wrote:
> Michael DeHaan wrote:
>>
>> (We also need a CLI for dashboard... so it's easy to add nodes and tag
>> them here... we don't want people using
>> the extended DB to have to click around a WebUI if they don't want to, and
>> it would be helpful w
Michael DeHaan wrote:
(We also need a CLI for dashboard... so it's easy to add nodes and tag
them here... we don't want people using
the extended DB to have to click around a WebUI if they don't want to,
and it would be helpful with batch population).
http://github.com/ohlol/puppet-dashboard/b
Michael DeHaan wrote:
Joe McDonagh wrote:
Michael DeHaan wrote:
Joe McDonagh wrote:
Michael DeHaan wrote:
Additional ideas for stuff you would like to see?
--Michael
Please take out the 'feature' that you need LDAP hosts to run
puppetrun on a wide scale. The utility becomes useless for
Joe McDonagh wrote:
Michael DeHaan wrote:
Joe McDonagh wrote:
Michael DeHaan wrote:
Additional ideas for stuff you would like to see?
--Michael
Please take out the 'feature' that you need LDAP hosts to run
puppetrun on a wide scale. The utility becomes useless for a large
portion of peo
Michael DeHaan wrote:
Joe McDonagh wrote:
Michael DeHaan wrote:
Additional ideas for stuff you would like to see?
--Michael
Please take out the 'feature' that you need LDAP hosts to run
puppetrun on a wide scale. The utility becomes useless for a large
portion of people. I searched the t
Michael DeHaan wrote:
OT -- one thing I didn't explain about Func is it had the notion of "do
this N at a time", in our particular case,
there may be an opportunity to teach N hosts to update at a time, and
then do N hosts later... so in very large
setups, it would be possible to do easy rolling
Joe McDonagh wrote:
Michael DeHaan wrote:
Additional ideas for stuff you would like to see?
--Michael
Please take out the 'feature' that you need LDAP hosts to run
puppetrun on a wide scale. The utility becomes useless for a large
portion of people. I searched the thread quickly and didn'
Daniel wrote:
Something like "/etc/init.d/tomcat stop", "deploy",
"/etc/init.d/tomcat start". It also would be great to manage services
in general. Like stop/start/restart service X.
Seems like this would be better modelled as:
punc --server-tags webservers --puppetrun --tags "tomcat"
And m
Michael DeHaan wrote:
Additional ideas for stuff you would like to see?
--Michael
Please take out the 'feature' that you need LDAP hosts to run puppetrun
on a wide scale. The utility becomes useless for a large portion of
people. I searched the thread quickly and didn't see this mentioned.
Something like "/etc/init.d/tomcat stop", "deploy",
"/etc/init.d/tomcat start". It also would be great to manage services
in general. Like stop/start/restart service X.
On Wed, Feb 10, 2010 at 8:49 PM, Michael DeHaan
wrote:
> Daniel wrote:
>>
>> Sounds promising. What about a combination of shell
Daniel wrote:
Sounds promising. What about a combination of shell execution and a
normal puppetrun? Something like run a shell command, apply catalog,
run another command.
Possibly --- What's the shell command in that example so I can grok the
use case?
OT -- one thing I didn't explain abo
Sounds promising. What about a combination of shell execution and a
normal puppetrun? Something like run a shell command, apply catalog,
run another command.
On Wed, Feb 10, 2010 at 6:45 PM, Michael DeHaan
wrote:
> Teyo, Bruce, and I were bouncing around some ideas resently for an
> simple but en
On Wed, Feb 10, 2010 at 12:49 PM, Scott Smith wrote:
> Michael DeHaan wrote:
>>
>> Example syntax:
>>
>> punc
>
> Python or Ruby?
>
> -scott
Totally Ruby :)
I think the RAL really makes up for and eliminates the need of a lot
of the stuff we tried to do as Func modules. Good stuff. I think
Michael DeHaan wrote:
Example syntax:
punc
Python or Ruby?
-scott
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-user
Teyo, Bruce, and I were bouncing around some ideas resently for an
simple but enhanced puppetrun.
Basically the idea is merging the ideas behind Func and Puppetrun.
Obviously other tools like mcollective have various other advantaged
features so this will be fairly primative by comparison, though
24 matches
Mail list logo
