[no description] https://git.osdyson.ru/pkg-puppet/puppet/atom?h=master 2014-10-16T23:37:46Z 2014-10-16T23:37:46Z Andrew Parker andy@puppetlabs.com 2014-10-16T23:37:46Z urn:sha1:d4b882760269060287bd8325548eea2a29f64506 The :undef symbol was still leaking all over the place internally. This caused type inference to sometimes end up with Runtime[ruby, Symbol]. By using nil instead of :undef, everything can be much more straightforward. Once the code removal for puppet 4 comes into play even more oddities around how resource parameters are handled can be performed. 2014-10-16T21:20:00Z Andrew Parker andy@puppetlabs.com 2014-10-16T21:20:00Z urn:sha1:a40cfd624fbc7380690d76a6cb691225e0e9eeba The lookup function only works when the future parser is in effect. This changes the spec tests to turn on the future parser. 2014-10-03T19:58:40Z Andrew Parker andy@puppetlabs.com 2014-10-03T00:18:39Z urn:sha1:b62ec8c7d1c3f7c6a34e804f0c568275e77a2aa4 After talking with Reid Vandewiele, it turns out that the problematic behavior isn't directly the order of the classes themselves. Previous assertions that there are possible conflicts from the classes when they were done in one order or another are incorrect. The classes, when any have parameters, are kept by the node in a hash keyed off of the class name, which means that there is no possibility of them creating a duplicate resource error. The actual usecase comes down to *how* parameterized classes vs unparameterized classes are often used. A parameterized class can often be simply a set of shared data that the unparameterized classes depend on (or inherit from) parameterized classes. This modifies the test case for the reordering change to provide an example of the use case here. 2014-10-03T19:58:40Z Jeff McCune jeff@puppetlabs.com 2014-09-26T18:09:04Z urn:sha1:378b656d9de32b644c16e0e3f3e6aefd45af4304 Without this patch classes declared from an ENC are evaluated in the wrong order. This is a problem because classes declared without parameters are evaluated prior to classes with parameters which causes an Error: Duplicate declaration when the classes with parameters are evaluated. According to the code comments for the `evaluate_node_classes` method, the expected behavior is that classes with an empty set of parameters will not conflict with classes that have declared parameters. 2014-08-29T21:53:36Z Josh Partlow joshua.partlow@puppetlabs.com 2014-08-29T21:53:36Z urn:sha1:4f67f7b93a1c7517240d8a9948a5107a2a424723 After discussion with Nick Fagerlund and Henrik Lindberg, changing restrict_environment_manifest setting to disable_per_environment_manifest to more clearly reflect what the setting does. 2014-08-29T18:33:21Z Josh Partlow joshua.partlow@puppetlabs.com 2014-08-28T22:41:14Z urn:sha1:acf6f9b4a6b1489f9b1e5d7d85a236324e53470c Henrik brought up that with the new restrict_environment_manifest setting set true, authors of modules in a particular environment may be surprised by a manifest they have specified in their environment.conf not being pulled in, leading to bad behavior when a catalog is executed. Although this is logged on the master, compilation delivery and catalog execution is not prevented. This commit will raise an exception on the master prior to catalog compilation if it detect's a conflict between manifest settings in the requested environment. 2014-08-01T18:49:47Z Andrew Parker andy@puppetlabs.com 2014-08-01T16:46:54Z urn:sha1:4c28090552ffe56a71ce15b9290bdbd552e6ec31 This adds checks for the specification's assertions that virutal and exported resources are not in the produced catalog, but are available for later operations (realization) and reference (reading a parameter value). This cannot check that the exported resources are made available to catalog processors, since that is implementation dependent. In order to check this the compile_to_catalog method needed to be changed to filter out expoerted resources, just like the catalog indirection does. This required a change to the create_resources test. 2014-07-24T23:45:47Z Josh Partlow joshua.partlow@puppetlabs.com 2014-07-24T23:45:47Z urn:sha1:7e3ec7f18ba6fb262f6d76384e0b5af501cf0da9 I believe most of these predated our clearing the settings before each test in the central puppet/test/test_helper.rb. And since we then set some base settings (such as :environment_timeout) in the test_helper, the effect of a secondary clear in the test itself is to wipe out the baseline setup test_helper just laid down. In particular this is a problem with environment_timeout, as it leads to tests which end up creating environments, getting them cached with the default 180s timeout, which can leak to subsequent tests and create unpleasant spec order issues. 2014-07-11T16:27:51Z Andrew Parker andy@puppetlabs.com 2014-07-11T16:27:51Z urn:sha1:93f2eb4894281b108340e97da8dce4f44c317097 Testing that the function exists isn't really needed since the later tests that actually use the function will find that fairly quickly. 2014-07-10T21:01:49Z Daniel Thornton dthornton@mozilla.com 2014-05-20T21:19:02Z urn:sha1:1d3d839307bc546584f99904a9feb9331e234385 This modifies the file() function to accept module paths (like the template() function) as well as fully qualified paths. This makes it possible for modules that use the file() function to be more portable, instead of being tied to a specific puppet server configuration. Example with directory structure: /etc/puppet/modules/example ├── files │ └──file.ext ├── manifests │ └──init.pp └── templates └──template.erb When the module path for files can be used instead of the absolute path: file('example/file.ext') returns the same as file('/etc/puppet/modules/example/files/file.ext'). This is supposed to be like how template does module paths, where: template('example/template.erb') returns the same as template('/etc/puppet/modules/example/templates/template.erb')