I hope I''m overlooking something obvious here. There''s a lot
of good stuff in puppet that is missing a clue doc ;-) Appreciate a
clue-by-four if I overlooked something.
I''d like to be able to apply a puppet policy on demand from a node.
For example:
puppet agent --test --debug --class fixjavainstall
The obvious purpose is to test a new class before applying it to many systems.
Yes, I can do this:
node /test-node/ inherits normal-node-class {
fixjavainstall
}
But this means checking files in and out of SVN, and is a bit heavy for a simple
test. I can also copy the class file down to the system and run
puppet apply fixjavainstall.pp
…but this only tests the class in isolation, not as part of the entire policy.
Any better idea for testing new classes or modules within the entire policy run
would be appreciated.
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source and other
randomness
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Sep 15, 2011, at 11:31 PM, Jo Rhett wrote:> I hope I''m overlooking something obvious here. There''s a lot of good stuff in puppet that is missing a clue doc ;-) Appreciate a clue-by-four if I overlooked something. > > I''d like to be able to apply a puppet policy on demand from a node. For example: > puppet agent --test --debug --class fixjavainstall > > The obvious purpose is to test a new class before applying it to many systems. Yes, I can do this: > node /test-node/ inherits normal-node-class { > fixjavainstall > } > > But this means checking files in and out of SVN, and is a bit heavy for a simple test. I can also copy the class file down to the system and run > puppet apply fixjavainstall.pp > > …but this only tests the class in isolation, not as part of the entire policy. > > Any better idea for testing new classes or modules within the entire policy run would be appreciated.---- I thought that was the point of environments. Craig -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> On Sep 15, 2011, at 11:31 PM, Jo Rhett wrote: >> Any better idea for testing new classes or modules within the entire policy run would be appreciated.On Sep 16, 2011, at 8:01 AM, Craig White wrote:> I thought that was the point of environments.Would you mind explaining that statement? There simply isn''t anything on this page http://docs.puppetlabs.com/guides/environment.html that would indicate such. Yes, I agree that "puppet agent --environment dev" looks like any easy invocation, but the implementation requires a daemon restart so this doesn''t make much sense. In fact, this is a heavy-handed approach that requires about 10x the amount of work compared to creating a node statement for just the node. Any time you have to modify puppet.conf and restart the daemon … very much missing the point for "easy testing" -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Okay, I figured this out. Yes, you can tweak puppet.conf based on environment
(which could be useful for testing new modules) but for my simplified test case
below it works something like this:
Put this in the class/module:
# Client can opt in to this for testing
if $environment == ''fixjava'' {
include fixjavainstall
}
And then run the client like so:
puppet agent --test --environment fixjava
On Sep 16, 2011, at 11:21 AM, Jo Rhett wrote:>> On Sep 15, 2011, at 11:31 PM, Jo Rhett wrote:
>>> Any better idea for testing new classes or modules within the
entire policy run would be appreciated.
>
> On Sep 16, 2011, at 8:01 AM, Craig White wrote:
>> I thought that was the point of environments.
>
> Would you mind explaining that statement? There simply isn''t
anything on this page http://docs.puppetlabs.com/guides/environment.html that
would indicate such. Yes, I agree that "puppet agent --environment
dev" looks like any easy invocation, but the implementation requires a
daemon restart so this doesn''t make much sense.
>
> In fact, this is a heavy-handed approach that requires about 10x the amount
of work compared to creating a node statement for just the node. Any time you
have to modify puppet.conf and restart the daemon … very much missing the point
for "easy testing"
>
>
> --
> Jo Rhett
> Net Consonance : consonant endings by net philanthropy, open source and
other randomness
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source and other
randomness
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
If you use dynamic environments with git as detailed in http://hunnur.com/blog/2010/10/dynamic-git-branch-puppet-environments/ you can get a lot of flexibility without having to hardcode environments. Just branch, commit, push a new remote branch, and then use the environment. On Fri, Sep 16, 2011 at 11:42 AM, Jo Rhett <jrhett@netconsonance.com> wrote:> Okay, I figured this out. Yes, you can tweak puppet.conf based on > environment (which could be useful for testing new modules) but for my > simplified test case below it works something like this: > > Put this in the class/module: > > # Client can opt in to this for testing > if $environment == ''fixjava'' { > include fixjavainstall > } > > And then run the client like so: > puppet agent --test --environment fixjava > > On Sep 16, 2011, at 11:21 AM, Jo Rhett wrote: > > On Sep 15, 2011, at 11:31 PM, Jo Rhett wrote: > > Any better idea for testing new classes or modules within the entire policy > run would be appreciated. > > > On Sep 16, 2011, at 8:01 AM, Craig White wrote: > > I thought that was the point of environments. > > > Would you mind explaining that statement? There simply isn''t anything on > this page http://docs.puppetlabs.com/guides/environment.html that would > indicate such. Yes, I agree that "puppet agent --environment dev" looks like > any easy invocation, but the implementation requires a daemon restart so > this doesn''t make much sense. > > In fact, this is a heavy-handed approach that requires about 10x the amount > of work compared to creating a node statement for just the node. Any time > you have to modify puppet.conf and restart the daemon … very much missing > the point for "easy testing" > > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and > other randomness > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and > other randomness > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- Adrien Thebo adrien@puppetlabs.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sep 16, 2011 7:27 PM, "Adrien Thebo" <adrien@puppetlabs.com> wrote:> > If you use dynamic environments with git as detailed inhttp://hunnur.com/blog/2010/10/dynamic-git-branch-puppet-environments/ you can get a lot of flexibility without having to hardcode environments. Just branch, commit, push a new remote branch, and then use the environment. Adrien, Thank you for sharing this link. It''s exactly what I''ve been looking for. -paul -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.