Puppet users - Dec 2013 - cli-driven list-file-based ad-hoc runs

Currently, I have

  /etc/puppet/puppet.conf

on my nodes with 

 [main]
 :
 noop = true

 [agent]
 :

And puppet is running as:

  /usr/bin/ruby /usr/bin/puppet agent --verbose

On the Puppet Master:

  /etc/puppet/manifests/nodes.pp

  node ''basenode'' {
    include baseclass
  }
  :
  node ''somepattern'' inherits basenode {
     class { ''abc::def'':
        randomvariables => "random values"
     }
  }

However, I am finding it inconvenient for running all assigned classes 
on the node
or some subset of the nodes or some subset of classes and nodes, etc., and 
only 
when I specify they should be run (not 7x24x365, etc.):

What I want is, from the master do something like

  some-magical-puppet-command some-list-file

which based on the one-host-per-line some-list-file simply makes it happen
on the remote nodes, running the classes then and only then with the normal
YAML logging and /var/log/messages.

Anyone implemented non-GUI, CLI-based run-from-listfile within Open Source 
Puppet?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/f18a560d-e34a-4027-9eca-8770a4423f66%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

If I understand this correctly, you are looking for a way to remotely
initiate noop runs on a subset of your agents with a selected set of tags.

"puppet kick" used to be available for that, and has been superseded
by
MCollective. To do this in a compliant way, you will need to build an
MCollective infrastructure. Scheduling the desired puppet runs should
become trivial then.

On 12/02/2013 08:23 PM, Stuart Cracraft wrote:
>   some-magical-puppet-command some-list-file
> 
> which based on the one-host-per-line some-list-file simply makes it happen
> on the remote nodes, running the classes then and only then with the normal
> YAML logging and /var/log/messages.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/529D9EF8.3070604%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/groups/opt_out.

Thankyou. 
> On Dec 3, 2013, at 1:06 AM, Felix Frank
<felix.frank@alumni.tu-berlin.de> wrote:
> 
> If I understand this correctly, you are looking for a way to remotely
> initiate noop runs on a subset of your agents with a selected set of tags.
> 
> "puppet kick" used to be available for that, and has been
superseded by
> MCollective. To do this in a compliant way, you will need to build an
> MCollective infrastructure. Scheduling the desired puppet runs should
> become trivial then.
> 
>> On 12/02/2013 08:23 PM, Stuart Cracraft wrote:
>>  some-magical-puppet-command some-list-file
>> 
>> which based on the one-host-per-line some-list-file simply makes it
happen
>> on the remote nodes, running the classes then and only then with the
normal
>> YAML logging and /var/log/messages.
> 
> -- 
> You received this message because you are subscribed to a topic in the
Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
https://groups.google.com/d/topic/puppet-users/6OlNTbxwaC8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
puppet-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/529D9EF8.3070604%40alumni.tu-berlin.de.
> For more options, visit https://groups.google.com/groups/opt_out.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/A5246438-65D1-4126-A540-D35270D4ECB8%40me.com.
For more options, visit https://groups.google.com/groups/opt_out.

We''ll be using a simple parallel tool which has sequential as an option
to
do 
puppet agent -t --noop on the remote nodes. This means we won''t need 
MCollective
and the ports it requires open. We''re a hosted environment with very
heavy
security
and "deny all" is the default.

On Monday, December 2, 2013 11:23:52 AM UTC-8, Stuart Cracraft wrote:
> Currently, I have
>
>   /etc/puppet/puppet.conf
>
> on my nodes with 
>
>  [main]
>  :
>  noop = true
>
>  [agent]
>  :
>
> And puppet is running as:
>
>   /usr/bin/ruby /usr/bin/puppet agent --verbose
>
> On the Puppet Master:
>
>   /etc/puppet/manifests/nodes.pp
>
>   node ''basenode'' {
>     include baseclass
>   }
>   :
>   node ''somepattern'' inherits basenode {
>      class { ''abc::def'':
>         randomvariables => "random values"
>      }
>   }
>
> However, I am finding it inconvenient for running all assigned classes 
> on the node
> or some subset of the nodes or some subset of classes and nodes, etc., and 
> only 
> when I specify they should be run (not 7x24x365, etc.):
>
> What I want is, from the master do something like
>
>   some-magical-puppet-command some-list-file
>
> which based on the one-host-per-line some-list-file simply makes it happen
> on the remote nodes, running the classes then and only then with the normal
> YAML logging and /var/log/messages.
>
> Anyone implemented non-GUI, CLI-based run-from-listfile within Open Source 
> Puppet?
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/f5470b32-e511-4c77-9f22-cc555d053d42%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.