Catalog compilation weirdness

[Robert Davidson]

(This is under puppet 3.6.2.)

In my ongoing monkey-knife-fight with the openstack puppet modules, I've run across a weird thing. I'm getting this error when I try to run puppet with a particular role:
Error: Could not retrieve catalog from remote server: Could not intern from text/pson: Could not intern from data: Could not find relationship target "Keystone_domain[]"
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Now, relationship errors usually mean that you're trying to define an empty resource, as I understand it. But the weird thing is that this is what I see on the puppet master:
2016-02-28 13:07:51 -0800 Puppet (info): Not using expired facts for $HOSTNAME from cache; expired at 2016-02-27 22:29:58 -0800
2016-02-28 13:07:51 -0800 Puppet (info): Caching facts for $HOSTNAME
2016-02-28 13:07:51 -0800 Puppet (info): Caching node for $HOSTNAME
2016-02-28 13:07:54 -0800 Puppet (info): 'replace facts' command for $HOSTNAME submitted to PuppetDB with UUID cc3dc352-e02c-440e-9684-1d6ecc804b97
2016-02-28 13:07:55 -0800 Puppet (info): Caching node for $HOSTNAME
2016-02-28 13:08:01 -0800 Puppet (warning): Keystone under Eventlet has been deprecated during the Kilo cycle. Support for deploying under eventlet will be dropped as of the M-release of OpenStack.
2016-02-28 13:08:02 -0800 Puppet (warning): The version parameter is deprecated in Liberty.
2016-02-28 13:08:03 -0800 Puppet (notice): Compiled catalog for $HOSTNAME in environment development in 8.80 seconds
2016-02-28 13:08:03 -0800 Puppet (info): Caching catalog for $HOSTNAME
2016-02-28 13:08:05 -0800 Puppet (info): 'replace catalog' command for $HOSTNAME submitted to PuppetDB with UUID 8c6a8b88-86ef-4914-9339-77b8caed8d3a
2016-02-28 13:08:08 -0800 Puppet (info): 'store report' command for $HOSTNAME submitted to PuppetDB with UUID adef58d0-ea93-47f6-a038-14a279e972c1

The master says it's successfully compiling a catalog, and thus giving me absolutely no useful information on where the problem is. As I'm trying to debug modules written by someone else, this is Not Helpful. Turning on debug output on the puppet master doesn't give me anything I can use either - is there some way to force it to spit out where this relationship problem is actually happening?


--
Robert Davidson

[Hristo Mohamed]

I have seen the same type of error with a custom fact, that was failing to set the proper value for the variable(the variable was an array). Then the empty variable was used as a name for resource creation.
Care to check for that in your manifests?

Hristo

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1EE73329D6577F44A3C2FB0F7D4ACAE98D08D178%40mbx-02.
For more options, visit https://groups.google.com/d/optout.

[Robert Davidson]

I think I figured it out.

The problem statement was
$domains = unique(delete_undef_values([ $admin_user_domain, $admin_project_domain, $service_project_domain]))
keystone_domain { $domains:
ensure => present,
enabled => true,
}

For whatever reason, delete_undef_values wasn't doing what it said on the tin - I'm not sure why, or if I should even report this as a bug to the puppet-keystone devs. That looks like a valid bit of puppetry to me, and I have no idea why it wasn't working on our setup.

--
Robert Davidson

> <mailto:puppet-users%2Bunsu...@googlegroups.com> .

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-
> users/1EE73329D6577F44A3C2FB0F7D4ACAE98D08D178%40mbx-02.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-

> users/CALuoJ64u6Hjds%2Bf%3DCp0kBCVhDjjuv%3Do1DLH8KqTkYCgH1nX8G
> Q%40mail.gmail.com <https://groups.google.com/d/msgid/puppet-
> users/CALuoJ64u6Hjds%2Bf%3DCp0kBCVhDjjuv%3Do1DLH8KqTkYCgH1nX8G
> Q%40mail.gmail.com?utm_medium=email&utm_source=footer> .

[Henrik Lindberg]

On 29/02/16 01:18, Robert Davidson wrote:
> I think I figured it out.
>
>

> For whatever reason, delete_undef_values wasn't doing what it said on the tin - I'm not sure why,
> or if I should even report this as a bug to the puppet-keystone devs.
That looks like a valid bit
> of puppetry to me, and I have no idea why it wasn't working on our setup.
>

The function delete_undef_values from stdlib does not do a good job. It
can only recognize some forms of historical undefined values.

If you are using future parser in 3.x, or puppet 4.x you can do the same
with the filter function in puppet.

# Keep those that are not undef
$filtered = $array.filter |$x| { $x !~ Undef }

Please report the problem against puppet stdlib.

Regards
- henrik
--

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