fix spec_dir in rest_spec indirector

[agadelshin]

Pluginsync uses /var/lib/puppet/lib/ directory for syncing plugins in modules, but puppet-policy is looking for specs in /var/lib/puppet/policy/server (I don't have /var/lib/puppet/policy directory by default).

'lib/' was added in spec_dir to fix that problem.

[coveralls]

Coverage remained the same when pulling abcf36f on pondohva:master into fd83d15 on raphink:master.

[raphink]

You are right that this is wrong. However, the solution is using :libdir instead of :vardir. If you fix this, I'll happily merge the change.

[coveralls]

Coverage remained the same when pulling 68e93e8 on pondohva:master into fd83d15 on raphink:master.

[agadelshin]

Thank you. Done!

[raphink]

Hmm actually, I'm just reading the doc and code again. It is intended to be vardir and not libdir. The reason for this is that serverspec code doesn't need to be distributed with pluginsync, since it runs after the Puppet run.

For this reason, I had chosen to distribute it using file resources. There is a policy::serverspec definition which deploys server specs to vardir.

[agadelshin]

I saw this definition, but I think that serverspec logic in modules is kinda weird. And could you tell me, where are you creating directory /var/lib/puppet/policy/server?

You are right, serverspec doesn't need to be distributed with pluginsync, but it's easier way to get serverspecs in right place.

I have some hacks for puppet-policy in my vagrant testing environment, but I don't want to use hacks in production.

[agadelshin]

I thought about copying serverspecs in rest_spec indirector (like auto_spec do it), but I can't get list of modules (or don't know how to do it)

[raphink]

Iirc, the one reason why I chose against using libdir was the autospec system, which generates specs. Pluginsync will wipe the directory every time, which is not what I want iirc.

[raphink]

In fact, the idea of the definition was that you could choose to deploy serverspec associated to a class, so you wouldn't deploy all the tests just because a module is present on the Puppetmaster.

[agadelshin]

I have serverspecs which I don't want to generate. If you generate serverspecs from code, you just check how puppet works. But I want to find mistakes in code and if I'll generate its from code, I never find them.

So, my auto_specs look like

Puppetx::Policy::AutoSpec.newspec 'Apache::Vhost' do |v|
 content =   "  describe port('80') do\n     it { should be_listening }\n  end\n"
 content +=  "  describe file('/test/file') do\n     it { should be_file }\n  end\n"
 content +=  "  describe file('/test/file2') do\n     it { should be_file }\n  end\n
end

It looks awful. That's why I decided to distribute serverspecs with pluginsync or just copy with rest_spec.

And I'm totally agree with you, distribution with pluginsync is a bad idea, I don't want to have all serverspecs :)

[raphink]

I don't agree that autospecs only check how Puppet works. They check that it actually worked, which is quite different.

Say Puppet deployed the vhost fine, and started Apache fine, but the Apache init script failed and Apache crashed after a few seconds, or didn't actually load the vhost properly. You'll see that with the autospecs, but it's not Puppet's fault.

[agadelshin]

OK, I got your point, just don't want to use serverspecs only for monitoring but acceptance tests.

I'll think about it and try to find a way to resolve it without using policy::serverspec in code. Thank you!

[raphink]

Sure. If you have new ideas to improve deployment of tests and how to pick which tests to run, I'll be happy to hear them!