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
On Feb 28, 2016 11:17 PM, "Robert Davidson" <robert.david...@nominum.com>
wrote:

> (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
>
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CALuoJ64u6Hjds%2Bf%3DCp0kBCVhDjjuv%3Do1DLH8KqTkYCgH1nX8GQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to