Douglas Garstang
2010-Jul-22 04:24 UTC
[Puppet Users] First Foray into Parameterized Classes.... not so good
I have this:
class foo::foobar ($version) {
}
which is called like this:
class facility::sanjose inherits facility::common {
class { foo::foobar: version => "1.3.13" }
}
puppet complains with this on the client:
Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find parent resource type ''facility::sanjose'' of
type
hostclass in production at
/etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node
slog01.pax.xxx.com
and this on the server:
Syntax error at ''foo::foobar''; expected ''}''
at
/etc/puppet/modules/facility/manifests/sanjose.pp:32 on node
slog01.pax.xxx.com
I suspect that it doesn''t like the ''::'', but I
can''t test it without
that because removing the module qualifier and the ''::'' means
the
autoloading doesn''t work. So... what''s the deal?
Can''t we use class
names qualified with the module name anymore? I tried putting the
class and module name in single and double quotes too:
class { "foo::foobar": version => "1.3.13" }
class { ''foo::foobar'': version => "1.3.13" }
.... same error.
Doug.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang
2010-Jul-22 04:55 UTC
[Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Wed, Jul 21, 2010 at 9:24 PM, Douglas Garstang <doug.garstang@gmail.com> wrote:> I have this: > > class foo::foobar ($version) { > } > > which is called like this: > > class facility::sanjose inherits facility::common { > class { foo::foobar: version => "1.3.13" } > } > > puppet complains with this on the client: > Could not retrieve catalog from remote server: Error 400 on SERVER: > Could not find parent resource type ''facility::sanjose'' of type > hostclass in production at > /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node > slog01.pax.xxx.com > > and this on the server: > Syntax error at ''foo::foobar''; expected ''}'' at > /etc/puppet/modules/facility/manifests/sanjose.pp:32 on node > slog01.pax.xxx.com > > I suspect that it doesn''t like the ''::'', but I can''t test it without > that because removing the module qualifier and the ''::'' means the > autoloading doesn''t work. So... what''s the deal? Can''t we use class > names qualified with the module name anymore? I tried putting the > class and module name in single and double quotes too: > > class { "foo::foobar": version => "1.3.13" } > class { ''foo::foobar'': version => "1.3.13" } > > .... same error. > > Doug. >Egads. Why is this so hard? So, I went back and tried it again without the module qualification. I created a module called foo, and put the following into site.pp: import "foo" My modules/foo/manifests/init.pp has this: class foobar ($version) { } Now, when I use ''include foobar'' everyone is happy. However, when I do "class { foobar: version => "1.3.13" }", puppet complains. It doesn''t like the way I''m calling the class. It reports the error: debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw yaml; using pson /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:57:in `deserialize'' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:71:in `find'' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find'' /usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:50:in `find'' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:225:in `retrieve_new_catalog'' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:414:in `thinmark'' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure'' /usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:413:in `thinmark'' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:224:in `retrieve_new_catalog'' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:102:in `retrieve_catalog'' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:143:in `run'' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' /usr/lib/ruby/1.8/sync.rb:229:in `synchronize'' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:101:in `with_client'' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:76:in `start'' /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in `call'' /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in `__signal__'' /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in `each'' /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in `__signal__'' (eval):2:in `signal'' /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:313:in `sound_alarm'' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:80:in `start'' /usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:124:in `start'' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:132:in `main'' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:89:in `run_command'' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:398:in `exit_on_fail'' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'' /usr/sbin/puppetd:4 err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find parent resource type ''facility::sanjose'' of type hostclass in production at /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node slog01.pax.xxx.com The module facility::sanjose is the calling class. So, what am I doing wrong? I''m just following the examples in the release notes. Doug. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang
2010-Jul-22 05:04 UTC
[Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Wed, Jul 21, 2010 at 9:55 PM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Wed, Jul 21, 2010 at 9:24 PM, Douglas Garstang > <doug.garstang@gmail.com> wrote: >> I have this: >> >> class foo::foobar ($version) { >> } >> >> which is called like this: >> >> class facility::sanjose inherits facility::common { >> class { foo::foobar: version => "1.3.13" } >> } >> >> puppet complains with this on the client: >> Could not retrieve catalog from remote server: Error 400 on SERVER: >> Could not find parent resource type ''facility::sanjose'' of type >> hostclass in production at >> /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node >> slog01.pax.xxx.com >> >> and this on the server: >> Syntax error at ''foo::foobar''; expected ''}'' at >> /etc/puppet/modules/facility/manifests/sanjose.pp:32 on node >> slog01.pax.xxx.com >> >> I suspect that it doesn''t like the ''::'', but I can''t test it without >> that because removing the module qualifier and the ''::'' means the >> autoloading doesn''t work. So... what''s the deal? Can''t we use class >> names qualified with the module name anymore? I tried putting the >> class and module name in single and double quotes too: >> >> class { "foo::foobar": version => "1.3.13" } >> class { ''foo::foobar'': version => "1.3.13" } >> >> .... same error. >> >> Doug. >> > > Egads. Why is this so hard? > > So, I went back and tried it again without the module qualification. I > created a module called foo, and put the following into site.pp: > > import "foo" > > My modules/foo/manifests/init.pp has this: > > class foobar ($version) { > } > > Now, when I use ''include foobar'' everyone is happy. However, when I do > "class { foobar: version => "1.3.13" }", puppet complains. It doesn''t > like the way I''m calling the class. It reports the error: > > debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw > yaml; using pson > /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:57:in `deserialize'' > /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:71:in `find'' > /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find'' > /usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:50:in `find'' > /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:225:in `retrieve_new_catalog'' > /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:414:in `thinmark'' > /usr/lib/ruby/1.8/benchmark.rb:293:in `measure'' > /usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'' > /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:413:in `thinmark'' > /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:224:in `retrieve_new_catalog'' > /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:102:in `retrieve_catalog'' > /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:143:in `run'' > /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' > /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'' > /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' > /usr/lib/ruby/1.8/sync.rb:229:in `synchronize'' > /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' > /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:101:in `with_client'' > /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'' > /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'' > /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'' > /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'' > /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:76:in `start'' > /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in > `call'' > /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in > `__signal__'' > /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in > `each'' > /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in > `__signal__'' > (eval):2:in `signal'' > /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:313:in > `sound_alarm'' > /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:80:in `start'' > /usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:124:in `start'' > /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:132:in `main'' > /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:89:in `run_command'' > /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'' > /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:398:in `exit_on_fail'' > /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'' > /usr/sbin/puppetd:4 > err: Could not retrieve catalog from remote server: Error 400 on > SERVER: Could not find parent resource type ''facility::sanjose'' of > type hostclass in production at > /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node > slog01.pax.xxx.com > > The module facility::sanjose is the calling class. So, what am I doing > wrong? I''m just following the examples in the release notes. > > Doug. >Well, here''s some more data. The call to "class { foobar: ver => "1.3.13" }" works fine when I remove it from the class it was in, and put it in a node definition. I''d ask if parameterized classes could only be called in nodes, except that the example in the release notes is clearly called from within another class. Doug. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang
2010-Jul-22 05:29 UTC
[Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Wed, Jul 21, 2010 at 10:04 PM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Wed, Jul 21, 2010 at 9:55 PM, Douglas Garstang > <doug.garstang@gmail.com> wrote: >> On Wed, Jul 21, 2010 at 9:24 PM, Douglas Garstang >> <doug.garstang@gmail.com> wrote: >>> I have this: >>> >>> class foo::foobar ($version) { >>> } >>> >>> which is called like this: >>> >>> class facility::sanjose inherits facility::common { >>> class { foo::foobar: version => "1.3.13" } >>> } >>> >>> puppet complains with this on the client: >>> Could not retrieve catalog from remote server: Error 400 on SERVER: >>> Could not find parent resource type ''facility::sanjose'' of type >>> hostclass in production at >>> /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node >>> slog01.pax.xxx.com >>> >>> and this on the server: >>> Syntax error at ''foo::foobar''; expected ''}'' at >>> /etc/puppet/modules/facility/manifests/sanjose.pp:32 on node >>> slog01.pax.xxx.com >>> >>> I suspect that it doesn''t like the ''::'', but I can''t test it without >>> that because removing the module qualifier and the ''::'' means the >>> autoloading doesn''t work. So... what''s the deal? Can''t we use class >>> names qualified with the module name anymore? I tried putting the >>> class and module name in single and double quotes too: >>> >>> class { "foo::foobar": version => "1.3.13" } >>> class { ''foo::foobar'': version => "1.3.13" } >>> >>> .... same error. >>> >>> Doug. >>> >> >> Egads. Why is this so hard? >> >> So, I went back and tried it again without the module qualification. I >> created a module called foo, and put the following into site.pp: >> >> import "foo" >> >> My modules/foo/manifests/init.pp has this: >> >> class foobar ($version) { >> } >> >> Now, when I use ''include foobar'' everyone is happy. However, when I do >> "class { foobar: version => "1.3.13" }", puppet complains. It doesn''t >> like the way I''m calling the class. It reports the error: >> >> debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw >> yaml; using pson >> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:57:in `deserialize'' >> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:71:in `find'' >> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find'' >> /usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:50:in `find'' >> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:225:in `retrieve_new_catalog'' >> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:414:in `thinmark'' >> /usr/lib/ruby/1.8/benchmark.rb:293:in `measure'' >> /usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'' >> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:413:in `thinmark'' >> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:224:in `retrieve_new_catalog'' >> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:102:in `retrieve_catalog'' >> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:143:in `run'' >> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' >> /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'' >> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' >> /usr/lib/ruby/1.8/sync.rb:229:in `synchronize'' >> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' >> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:101:in `with_client'' >> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'' >> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'' >> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'' >> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'' >> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:76:in `start'' >> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in >> `call'' >> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in >> `__signal__'' >> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in >> `each'' >> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in >> `__signal__'' >> (eval):2:in `signal'' >> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:313:in >> `sound_alarm'' >> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:80:in `start'' >> /usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:124:in `start'' >> /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:132:in `main'' >> /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:89:in `run_command'' >> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'' >> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:398:in `exit_on_fail'' >> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'' >> /usr/sbin/puppetd:4 >> err: Could not retrieve catalog from remote server: Error 400 on >> SERVER: Could not find parent resource type ''facility::sanjose'' of >> type hostclass in production at >> /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node >> slog01.pax.xxx.com >> >> The module facility::sanjose is the calling class. So, what am I doing >> wrong? I''m just following the examples in the release notes. >> >> Doug. >> > > Well, here''s some more data. The call to "class { foobar: ver => > "1.3.13" }" works fine when I remove it from the class it was in, and > put it in a node definition. I''d ask if parameterized classes could > only be called in nodes, except that the example in the release notes > is clearly called from within another class.And, digging a little further, this below works just fine: class facility::sanjose inherits facility::common { $repo_server = "prov.pax.xxx.com" $repo_set = "2010-07" include yum::client } node ''slog01.pax.xxx.com'' { include facility::sanjose } However, If I create a class called foobar, in a module called foo, which contains: class foobar ($ver) { } and I manually load it in site.pp with import "foo" AS SOON as I add the class to facility::sanjose like this: class facility::sanjose inherits facility::common { $repo_server = "prov.pax.xxx.com" $repo_set = "2010-07" include yum::client class { foobar: ver => "1.3.13" } } Puppet BARFS and complains that it can''t find facility::sanjose: Jul 21 22:06:34 s_sys@slog01.pax.livegamer.com puppet-agent[27500]: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find parent resource type ''facility::sanjose'' of type hostclass in production at /etc/pupp et/modules/facility/manifests/sanjose/logserver.pp:1 on node slog01.pax.xxx.com What on earth is going on here? Why does calling a parameterized class in another class cause the calling class to suddenly disappear? Doug. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang
2010-Jul-22 07:33 UTC
[Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Wed, Jul 21, 2010 at 10:29 PM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Wed, Jul 21, 2010 at 10:04 PM, Douglas Garstang > <doug.garstang@gmail.com> wrote: >> On Wed, Jul 21, 2010 at 9:55 PM, Douglas Garstang >> <doug.garstang@gmail.com> wrote: >>> On Wed, Jul 21, 2010 at 9:24 PM, Douglas Garstang >>> <doug.garstang@gmail.com> wrote: >>>> I have this: >>>> >>>> class foo::foobar ($version) { >>>> } >>>> >>>> which is called like this: >>>> >>>> class facility::sanjose inherits facility::common { >>>> class { foo::foobar: version => "1.3.13" } >>>> } >>>> >>>> puppet complains with this on the client: >>>> Could not retrieve catalog from remote server: Error 400 on SERVER: >>>> Could not find parent resource type ''facility::sanjose'' of type >>>> hostclass in production at >>>> /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node >>>> slog01.pax.xxx.com >>>> >>>> and this on the server: >>>> Syntax error at ''foo::foobar''; expected ''}'' at >>>> /etc/puppet/modules/facility/manifests/sanjose.pp:32 on node >>>> slog01.pax.xxx.com >>>> >>>> I suspect that it doesn''t like the ''::'', but I can''t test it without >>>> that because removing the module qualifier and the ''::'' means the >>>> autoloading doesn''t work. So... what''s the deal? Can''t we use class >>>> names qualified with the module name anymore? I tried putting the >>>> class and module name in single and double quotes too: >>>> >>>> class { "foo::foobar": version => "1.3.13" } >>>> class { ''foo::foobar'': version => "1.3.13" } >>>> >>>> .... same error. >>>> >>>> Doug. >>>> >>> >>> Egads. Why is this so hard? >>> >>> So, I went back and tried it again without the module qualification. I >>> created a module called foo, and put the following into site.pp: >>> >>> import "foo" >>> >>> My modules/foo/manifests/init.pp has this: >>> >>> class foobar ($version) { >>> } >>> >>> Now, when I use ''include foobar'' everyone is happy. However, when I do >>> "class { foobar: version => "1.3.13" }", puppet complains. It doesn''t >>> like the way I''m calling the class. It reports the error: >>> >>> debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw >>> yaml; using pson >>> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:57:in `deserialize'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:71:in `find'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:50:in `find'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:225:in `retrieve_new_catalog'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:414:in `thinmark'' >>> /usr/lib/ruby/1.8/benchmark.rb:293:in `measure'' >>> /usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:413:in `thinmark'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:224:in `retrieve_new_catalog'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:102:in `retrieve_catalog'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:143:in `run'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' >>> /usr/lib/ruby/1.8/sync.rb:229:in `synchronize'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:101:in `with_client'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:76:in `start'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in >>> `call'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in >>> `__signal__'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in >>> `each'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in >>> `__signal__'' >>> (eval):2:in `signal'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:313:in >>> `sound_alarm'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:80:in `start'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:124:in `start'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:132:in `main'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:89:in `run_command'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:398:in `exit_on_fail'' >>> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'' >>> /usr/sbin/puppetd:4 >>> err: Could not retrieve catalog from remote server: Error 400 on >>> SERVER: Could not find parent resource type ''facility::sanjose'' of >>> type hostclass in production at >>> /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node >>> slog01.pax.xxx.com >>> >>> The module facility::sanjose is the calling class. So, what am I doing >>> wrong? I''m just following the examples in the release notes. >>> >>> Doug. >>> >> >> Well, here''s some more data. The call to "class { foobar: ver => >> "1.3.13" }" works fine when I remove it from the class it was in, and >> put it in a node definition. I''d ask if parameterized classes could >> only be called in nodes, except that the example in the release notes >> is clearly called from within another class. > > And, digging a little further, this below works just fine: > > class facility::sanjose inherits facility::common { > $repo_server = "prov.pax.xxx.com" > $repo_set = "2010-07" > include yum::client > } > > node ''slog01.pax.xxx.com'' { > include facility::sanjose > } > > However, If I create a class called foobar, in a module called foo, > which contains: > > class foobar ($ver) { > } > > and I manually load it in site.pp with import "foo" > > AS SOON as I add the class to facility::sanjose like this: > > > class facility::sanjose inherits facility::common { > $repo_server = "prov.pax.xxx.com" > $repo_set = "2010-07" > include yum::client > class { foobar: ver => "1.3.13" } > } > > Puppet BARFS and complains that it can''t find facility::sanjose: > > Jul 21 22:06:34 s_sys@slog01.pax.livegamer.com puppet-agent[27500]: > Could not retrieve catalog from remote server: Error 400 on SERVER: > Could not find parent resource type ''facility::sanjose'' of type > hostclass in production at /etc/pupp > et/modules/facility/manifests/sanjose/logserver.pp:1 on node slog01.pax.xxx.com > > What on earth is going on here? Why does calling a parameterized class > in another class cause the calling class to suddenly disappear? > > Doug. >And finally, one more example, because I''ve been at this for 3 hours and I''m sick and tired of it: This does not work. These three classes are contained in /etc/puppet/modules/foobar/manifests/init.pp: class foobar::parent { class { "foobar::something": ver => "1.3.13"; } } class foobar::child inherits foobar::parent { } class foobar::something ($ver) { file { "/tmp/foo": ensure => directory; } } node ''slog01.pax.xxx.com'' { include foobar::child } Puppet complains with: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find class foobar::child at /etc/puppet/manifests/nodes/pax/slog01.pax.livegamer.com.pp:2 on node slog01.pax.xxx.com If I remove the call to class foobar::something in foobar::parent, that errors goes away. If I move the call to class foobar::something from foobar::parent down into foobar::child, then the same error returns: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find class foobar::child at /etc/puppet/manifests/nodes/pax/slog01.pax.livegamer.com.pp:2 on node slog01.pax.xxx.com I''m still scratching my head trying to understand why the call to foobar::something causes foobar::child to suddenly disappear. Doug. I''m still scratching my -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Peter Meier
2010-Jul-22 15:17 UTC
Re: [Puppet Users] Re: First Foray into Parameterized Classes.... not so good
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1> And finally, one more example, because I''ve been at this for 3 hours > and I''m sick and tired of it:maybe this is a bug and you should simply report it with the simplest example you have come up and which didn''t work. cheers pete -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxIYSAACgkQbwltcAfKi38M3ACfUWxwOt82SvhUdFp7wx//eFmo 2k8An20QS1e+SXpA4b3YHmvwyjl5VY37 =p9qX -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang
2010-Jul-22 15:20 UTC
Re: [Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Thu, Jul 22, 2010 at 8:17 AM, Peter Meier <peter.meier@immerda.ch> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> And finally, one more example, because I''ve been at this for 3 hours >> and I''m sick and tired of it: > > maybe this is a bug and you should simply report it with the simplest > example you have come up and which didn''t work.It seems more likely that it''s me doing something wrong.... even the simple example above isn''t working. Doug. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Brice Figureau
2010-Jul-22 15:55 UTC
Re: [Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Thu, 2010-07-22 at 08:20 -0700, Douglas Garstang wrote:> On Thu, Jul 22, 2010 at 8:17 AM, Peter Meier <peter.meier@immerda.ch> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > >> And finally, one more example, because I''ve been at this for 3 hours > >> and I''m sick and tired of it: > > > > maybe this is a bug and you should simply report it with the simplest > > example you have come up and which didn''t work. > > It seems more likely that it''s me doing something wrong.... even the > simple example above isn''t working.This is new stuff, so there might be bugs. You may have encountered one, but only the devs would know for sure. The best way for them to look to this issue is for you to file a bug report with the simplest manifest reproducing the issue (possibly with puppet, not puppetd/master). HTH -- Brice Figureau Follow the latest Puppet Community evolutions on www.planetpuppet.org! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thomas A. McGonagle
2010-Jul-25 01:55 UTC
Re: [Puppet Users] Re: First Foray into Parameterized Classes.... not so good
Hey Doug, I double checked your example. It doesn''t work for me either. I think it is a bug too, and not something you are doing. By the way, a define still works great :) -Tom Thomas A. McGonagle tom@dataero.com Google Voice: 617-229-5185 On Thu, Jul 22, 2010 at 11:55 AM, Brice Figureau <brice-puppet@daysofwonder.com> wrote:> On Thu, 2010-07-22 at 08:20 -0700, Douglas Garstang wrote: >> On Thu, Jul 22, 2010 at 8:17 AM, Peter Meier <peter.meier@immerda.ch> wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> >> And finally, one more example, because I''ve been at this for 3 hours >> >> and I''m sick and tired of it: >> > >> > maybe this is a bug and you should simply report it with the simplest >> > example you have come up and which didn''t work. >> >> It seems more likely that it''s me doing something wrong.... even the >> simple example above isn''t working. > > This is new stuff, so there might be bugs. > > You may have encountered one, but only the devs would know for sure. > > The best way for them to look to this issue is for you to file a bug > report with the simplest manifest reproducing the issue (possibly with > puppet, not puppetd/master). > > HTH > -- > Brice Figureau > Follow the latest Puppet Community evolutions on www.planetpuppet.org! > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
James Turnbull
2010-Jul-25 02:01 UTC
Re: [Puppet Users] Re: First Foray into Parameterized Classes.... not so good
Douglas Garstang wrote:> On Wed, Jul 21, 2010 at 9:24 PM, Douglas Garstang > <doug.garstang@gmail.com> wrote: >> I have this: >> >> class foo::foobar ($version) { >> } >> >> which is called like this: >> >> class facility::sanjose inherits facility::common { >> class { foo::foobar: version => "1.3.13" } >> } >> >> puppet complains with this on the client: >> Could not retrieve catalog from remote server: Error 400 on SERVER: >> Could not find parent resource type ''facility::sanjose'' of type >> hostclass in production at >> /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node >> slog01.pax.xxx.com >> >> and this on the server: >> Syntax error at ''foo::foobar''; expected ''}'' at >> /etc/puppet/modules/facility/manifests/sanjose.pp:32 on node >> slog01.pax.xxx.com >>I think this is a bug. Can you please log it. Thanks James Turnbull -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.