Manually apply puppet class

I am testing a puppet init.pp file (on windows) that looks something like:

class myclass {    
 package { 'java':
    ensure => installed,
    provider => 'msi',
    source => 'S:puppet-repojdk1.6.0_31.msi',
    install_options => { 'INSTALLDIR' => 'C:toolsjava' },
  }
}

Then my site.pp file looks like:

node default {
  include myclass
}

I created a tests/init.pp file that just calls the myclass module:

class { 'myclass': }

I can run the tests/init.pp file and it does install java correctly. I was wondering if there is a way to just run the myclass module from the command line without creating a separate tests/init.pp file. Or maybe I could move the package statement in myclass to its own .pp file and include that in init.pp and then I could run that separate .pp file if I wanted to. What is the more correct way to do this?

First, a trick for verifying syntax if you don’t already know:

puppet parser validate my_file.pp

Now, how you approach spot-testing a new class can vary based on your deployment but I can tell you how I do it, and perhaps it will make sense in your case. Or perhaps everyone on ServerFault will tell me how wrong I am.

In any given environment I have a set of node declarations using inheritance:

node base_production_environment {
  include ssh
  include ntp
  include whatever_else
}

node /prod-appd+.mycompany.com/ inherits base_production_environment { }

Now, when I write a new class, I want to test it on a particular system first before rolling it out, so I add a more specific (by hostname) node declaration so that it will override the less specific (by regular expression) declaration, like so:

node 'prod-app7.mycompany.com' inherits base_production_environment {
  include my_new_class
}

I simplified this a lot to highlight using specific node declarations for spot-checking new classes. We also use environments to roll out changes to less critical environments prior to rolling them out to production, etc.

So I just re-read your question and it occurred to me that you may be using a pushed modules directory approach, rather than using a puppetmaster. If that’s true, you can include a class for testing purposes with something like:

puppet apply --modulepath=C:puppet-modules -e "include my_class"

I don’t know if that’s the correct directory syntax for puppet under Windows, though.

you could also run:
puppet agent -t –tags your_class_name

So in your case:

puppet agent -t --tags my_new_class