0

We'd like to have our Rspec Puppet tests read in the contents of params.pp into a hash and verify there are no unexpected elements in that hash.

All the info I've found describes how to set parameters for testing via let (:params).

We are doing that already, but want to do something like expect params.keys.sort.to eq ('param1', 'param2', 'param3'), but don't know how to get the contents of params.pp into a variable we can use in our tests.

We are using Puppet 3.7.5.

Matthew Schuchard
  • 25,172
  • 3
  • 47
  • 67
Kenny Drobnack
  • 171
  • 2
  • 12
  • The params symbol is actually for class parameters and not a params manifest. My first reaction to your question was no, and a cursory glance at some more advanced rpsec-puppet stuff I have done also seems to indicate no. Puppet 3.7.x is EOL and `params.pp` use has been deprecated for a while. Have you considered updating, or is this one of those legacy code headache things? – Matthew Schuchard Jul 13 '16 at 15:02
  • @MattSchuchard, I don't follow. If you write a params class, say `mymodule::params`, what would *you* name the manifest in which its definition is stored? – John Bollinger Jul 13 '16 at 15:41
  • Additionally, there are still many modules around that use the params class pattern, and the Puppet language guide has [a specific discussion of it](https://docs.puppet.com/puppet/latest/reference/lang_classes.html#inheritance). I don't see any basis to claim that it is deprecated, nor even falling out of favor. Indeed, although Puppet, Inc. could deprecate class inheritance, on which the pattern relies, it does not have the power to deprecate the pattern itself. – John Bollinger Jul 13 '16 at 15:51
  • @JohnBollinger Puppet has told us more than once and in their official guides supplied to us that inheritance and `params.pp` are to be absolutely avoided since late 3.x. I probably should have said 'extremely discouraged' instead of deprecated. Now with 4.x you are supposed to use the module data with Puppet data provider (hence why RIPienaar no longer supports his gem to do module data). – Matthew Schuchard Jul 13 '16 at 16:53
  • @MattSchuchard, evidently Puppet is sending mixed messages, then. The latest language guide (linked in a previous comment) contains a discussion of class inheritance in general and of the params class pattern in particular, with no suggestion (there) that the params class pattern should be avoided. I don't recall seeing any conflicting messages myself. *Node* inheritance, on the other hand, is a whole different kettle of fish: it was deprecated somewhere in 3.x, and no longer exists in Puppet 4. – John Bollinger Jul 13 '16 at 17:13
  • To answer the questions - we've got quite a bit of Puppet code and it's standardized on using the params.pp for passing in params. Upgrading is on our radar but it's likely to be a while before we get there due to other project deadlines. – Kenny Drobnack Jul 13 '16 at 17:25
  • @JohnBollinger I wouldn't be surprised. Their customer support is dodgy and there seems to be a disconnect between development/engineering and their support team (it was support that told us this). You are probably correct that the thing I thought was deprecated was node inheritance and not class inheritance and I got the two confused. – Matthew Schuchard Jul 13 '16 at 17:58
  • @JohnBollinger Not to get further off-topic, but I just remembered that inheriting from params is part of the official style guidelines as something not to do and a warning in puppet-lint. – Matthew Schuchard Jul 15 '16 at 15:08
  • @MattSchuchard, I don't know about puppet-lint, but the current version of [Puppet's official style guide](https://docs.puppet.com/guides/style_guide.html#the-puppet-language-style-guide) demonstrates the params class pattern as [recommended style](https://docs.puppet.com/guides/style_guide.html#internal-organization-of-classes-and-defined-types), and elsewhere is explicitly accepting of class inheritance for that purpose (and only that purpose). For example, "Remember: Class inheritance should only be used for `myclass::params` parameter defaults." – John Bollinger Jul 15 '16 at 15:21
  • @JohnBollinger Ok, this clearly seems to be an enormously conflicting directive. I guess my personal preference will continue to be module data from the Puppet data provider, but be fine with others doing params inherits. – Matthew Schuchard Jul 15 '16 at 17:21

1 Answers1

0

The contents of a Puppet manifest named params.pp would ordinarily be the definition of a Puppet class whose simple name is "params" (or possibly of a defined type having that name). It is fairly common for modules to use such a class in an implementation of the "params class" pattern, wherein the purpose of the class is to provide, via its class variables, default values for the class parameters of other classes in the module.

I suppose, therefore, that what you propose to do is collect the names and values of the class's variables into a hash to test them, but such a test is outside the scope of rspec-puppet:

Rspec-puppet tests are there to test the behaviour of Puppet when it compiles your manifests into a catalogue of Puppet resources.

(Rspec-puppet Tutorial)

In other words, rspec-puppet is for testing the catalog compilation process and its results. If you examine the available matchers, you will see that this is their focus. The values of class variables that are not parameters (such as those of a params class) are not included as themselves in compiled catalogs, however, so they are not subject to testing with puppet-rspec. You can test whether those values are reflected in the parameters of resources that are included in the catalog, but the catalog contains no information whatever on variables that were available but not used.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157