On Monday, September 15, 2014 9:23:08 AM UTC-5, Henrik Lindberg wrote:
>
> On 2014-12-09 14:57, Juan Sierra Pons wrote:
> > Hi,
> >
> > I am using a mix of the following two blog post:
> >
> > [1] A modern Puppet Master from scratch
> >
> > [2] Puppet Infrastructure
> >
> > After upgrading to 3.7 I am getting the following error message
> >
> > Error: Could not retrieve catalog from remote server: Error 400 on
> > SERVER: Evaluation Error: Illegal Resource Type expression, expected
> > result to be a type name, or untitled Resource, got Type[Class] at
> > /etc/puppet/environments/production/site/profiles/manifests/base.pp:5:3
> > on node server3.example.com
> > Warning: Not using cache on failed catalog
> > Error: Could not retrieve catalog; skipping run
> >
> > With 3.6 it worked like a charm.
> >
>
In the sense that catalogs were compiled without error, perhaps. The
example does not perform proper containment, however: to do containment
with Anchor resources you need *two* per containing class, one to serve as
a lower bound and another to serve as an upper bound (see Henrik's link).
The example code and the terrarun tutorial on which it is based miss the
latter, leaving no containment whatever. You could just delete the anchor
resources and Class defaults without meaningfully changing the semantics of
the manifests.
Furthermore, using resource defaults for this purpose is tricky and prone
to failure because the default is ignored for any class that is declared
with its own specific require parameter.
> From the error message, I think you are using the future parser.
> Did you use the future parser on 3.6 as well?
>
> > The base.pp is like this:
> >
> > class profiles::base {
> > anchor { 'profiles::base': }
> > Class { require => Anchor['profiles::base'] }
> > users { users: }
> > }
> >
>
> It looks like your intention is to set the default for every class in
> the entire system to have a require of Anchor['profiles::base']. Is that
> true, or are you trying to achieve something else?
>
>
Remember that resource defaults are dynamically scoped. The code is trying
to make every class *declared by the given profile class* have have the
Anchor as a require. The model on which it is based proposes that several
of these classes might be declared, all chained together. I think the idea
is that they could thereby get away with only one anchor apiece, but that
doesn't work. For example, Puppet could choose to apply all the
(non-class) resources declared directly by the profile classes first,
including the anchors, and then all the other classes in any order.
> Read more about containment here:
> https://docs.puppetlabs.com/puppet/latest/reference/lang_containment.html
>
>
+1
I observe also that Puppet has suffered for years from confusion among
users, among developers, in documentation, and even in code about whether
(or in what sense) classes are resources. Starting with the introduction
of parameterized classes, there was a push -- largely originating at PL, I
think -- to cast the class as just another resource type. Thankfully, that
seems to have waned, because however much the DSL can present classes in
the same mold as ordinary resources, they manifestly are *not* ordinary
resources. More than a few bugs were reported around this, some without
any possibility of a fully satisfactory resolution.
It seems the future parser / type system may be swinging even more back the
other way. As a longtime critic of the conflation of classes and
resources, I am just fine with that. The future parser and Puppet 4 docs
should certainly discuss the matter, though.
John
--
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/0f266c5b-fbbc-482a-9d1e-76ba6e5b4926%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
