puppet4 regressions or features?

50 views
Skip to first unread message

Joshua hoblitt

unread,
May 14, 2015, 6:59:49 PM5/14/15
to puppe...@googlegroups.com
As I'm slowly updating my modules' testing boilerplate for puppet 4.x,
I've run into a couple cases of breakage that I'm unsure if they are
intentional changes in semantics or regressions.

When introspecting on a resource and the param is undefined, an empty
string is now being returned instead of my good friend `undef`.

I understand that '' is the same type of the param in this case but it
seems like a step backwards to have to go back to [the early days of]
comparing everything to '' instead of undef.

```
$user_home = getparam(User[$user], 'home')

$home = $user_home ? {
'' => "/home/${user}", # puppet 4.0
undef => "/home/${user}", # puppet 3.7
default => $user_home,
}
```

It appears that classes are no longer a first class resource.

```
Class['port389::admin::ssl']{ notify =>
Class['port389::admin::service'] }
```

```
Evaluation Error: Resource Override can only operate on
resources, got: Class[port389::admin::ssl]-Type at
/home/jhoblitt/github/puppet-port389/spec/fixtures/modules/port389/manifests/admin/ssl.pp:8:3
on node leo.tuc.noao.edu
```

I confess that this is fairly unusual syntax but it does work as
expected under 3.x.

What do you guys think?

-Josh

--

Erik Dalén

unread,
May 14, 2015, 7:10:56 PM5/14/15
to puppe...@googlegroups.com
This second issue was discussed a bit in the comments on PUP-2891: https://tickets.puppetlabs.com/browse/PUP-2891

You could work around it by using the syntax Class['port389::admin::ssl'] ~> Class['port389::admin::service'] instead which works in both 3.x and 4.x.

Henrik Lindberg

unread,
May 15, 2015, 7:07:13 AM5/15/15
to puppe...@googlegroups.com
On 2015-15-05 24:59, Joshua hoblitt wrote:
> As I'm slowly updating my modules' testing boilerplate for puppet 4.x,
> I've run into a couple cases of breakage that I'm unsure if they are
> intentional changes in semantics or regressions.
>
> When introspecting on a resource and the param is undefined, an empty
> string is now being returned instead of my good friend `undef`.
>
> I understand that '' is the same type of the param in this case but it
> seems like a step backwards to have to go back to [the early days of]
> comparing everything to '' instead of undef.
>
> ```
> $user_home = getparam(User[$user], 'home')
>
> $home = $user_home ? {
> '' => "/home/${user}", # puppet 4.0
> undef => "/home/${user}", # puppet 3.7
> default => $user_home,
> }
> ```
>
> It appears that classes are no longer a first class resource.

There is a chain of things happening here. First User[$user] is
evaluated, it is an instance of a resource type - and it gets translated
to a Resource internally (with type and title). This is then given to
the getparam function. If it does not find a value it returns an empty
string
(https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/puppet/parser/functions/getparam.rb#L34)

An empty string is truthy in 4.x and not the same as undef. The function
should be updated (it should not have returned an empty string in the
3.x version, and it should return nil in 4.x).

There is cleanup of stdlib under way.

>
> ```
> Class['port389::admin::ssl']{ notify =>
> Class['port389::admin::service'] }
> ```
>
> ```
> Evaluation Error: Resource Override can only operate on
> resources, got: Class[port389::admin::ssl]-Type at
> /home/jhoblitt/github/puppet-port389/spec/fixtures/modules/port389/manifests/admin/ssl.pp:8:3
> on node leo.tuc.noao.edu
> ```
>
That change is intentional. While classes behave as resources for some
operations it is not true for all. It happened to work for forming
relationships, but not for other things. Using the lazy evaluating
relationship expressions is much better (i.e. -> or ~> as Eric Dalén
pointed out).

- henrik


--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

John Bollinger

unread,
May 15, 2015, 3:41:37 PM5/15/15
to puppe...@googlegroups.com


On Thursday, May 14, 2015 at 5:59:49 PM UTC-5, Joshua Hoblitt wrote:
It appears that classes are no longer a first class resource.


Classes have never been a first class resource, though for a time there was a concerted effort to give that impression.


John

Reply all
Reply to author
Forward
0 new messages