[Puppet Users] Namespacing, includes and module lookup. Bug?
Hey all,
I'm not sure if I've made a fundamental misunderstanding of Puppet
namespacing and include resolution or whether there's a bug.
Background:
I have a modules, called kerberos, that configures a client for working
on my kerberos domain. I then have a module called ssh that sets up a
basic sshd. I wanted to create a ssh::kerberos class in the ssh module
that extends my ssh setup with kerberos support. I wanted to put a
dependency on the kerberos module. However things fell apart and there
was lots of hair tearing thinking I'd done something stupid (e.g. a
typo.) I now believe it's not that simple...
[Contrived, simplistic example]
Take a module called t that creates a folder:
/etc/puppet/modules/t/manifests/init.pp:
class t {
file { '/tmp/t': ensure = directory }
}
Create another module called test, that creates a file in that directory:
/etc/puppet/modules/test/manifests/init.pp
class test {
include t
file { '/tmp/t/foo':
ensure = file,
require = File['/tmp/t'],
}
Everything's super happy and fine. I have /tmp/t/foo. puppet agent
--test --debug:
info: Caching catalog for debian.localdomain
debug: Creating default schedules
debug: Loaded state in 0.00 seconds
debug: /Stage[main]/Test/File[/tmp/t/foo]/require: requires File[/tmp/t]
info: Applying configuration version '1293188258'
notice: /Stage[main]/T/File[/tmp/t]/ensure: created
notice: /Stage[main]/Test/File[/tmp/t/foo]/ensure: created
debug: Finishing transaction -615069188
debug: Storing state
debug: Stored state in 0.01 seconds
notice: Finished catalog run in 0.03 seconds
Now, create a test::t class.
/etc/puppet/modules/test/manifests/t.pp:
class test::t {
}
It falls apart. Puppet resolves the include t as being the subclass of
test, rather than the module:
info: Caching catalog for debian.localdomain
debug: Creating default schedules
err: Could not run Puppet configuration client: Could not find
dependency File[/tmp/t] for File[/tmp/t/foo] at
/etc/puppet/modules/test/manifests/init.pp:6
Replacing the require with Class['t'] is rather more telling in the debug:
info: Caching catalog for debian.localdomain
debug: Creating default schedules
debug: Loaded state in 0.00 seconds
debug: /Stage[main]/Test/File[/tmp/t/foo]/require: requires Class[Test::T]
info: Applying configuration version '1293188643'
err: /Stage[main]/Test/File[/tmp/t/foo]/ensure: change from absent to
file failed: Could not set 'file on ensure: No such file or directory -
/tmp/t/foo at /etc/puppet/modules/test/manifests/init.pp:6
debug: Finishing transaction -614790778
debug: Storing state
debug: Stored state in 0.01 seconds
notice: Finished catalog run in 0.03 seconds
Is this by design? If so, how do I specify module, not subclass, in the
include/require?
Is there a bug?
Cheers,
Dan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Namespacing, includes and module lookup. Bug?
On 24/12/10 11:11, Daniel Piddock wrote:
Hey all,
I'm not sure if I've made a fundamental misunderstanding of Puppet
namespacing and include resolution or whether there's a bug.
Background:
I have a modules, called kerberos, that configures a client for working
on my kerberos domain. I then have a module called ssh that sets up a
basic sshd. I wanted to create a ssh::kerberos class in the ssh module
that extends my ssh setup with kerberos support. I wanted to put a
dependency on the kerberos module. However things fell apart and there
was lots of hair tearing thinking I'd done something stupid (e.g. a
typo.) I now believe it's not that simple...
[Contrived, simplistic example]
Take a module called t that creates a folder:
/etc/puppet/modules/t/manifests/init.pp:
class t {
file { '/tmp/t': ensure = directory }
}
Create another module called test, that creates a file in that directory:
/etc/puppet/modules/test/manifests/init.pp
class test {
include t
file { '/tmp/t/foo':
ensure = file,
require = File['/tmp/t'],
}
Everything's super happy and fine. I have /tmp/t/foo. puppet agent
--test --debug:
info: Caching catalog for debian.localdomain
debug: Creating default schedules
debug: Loaded state in 0.00 seconds
debug: /Stage[main]/Test/File[/tmp/t/foo]/require: requires File[/tmp/t]
info: Applying configuration version '1293188258'
notice: /Stage[main]/T/File[/tmp/t]/ensure: created
notice: /Stage[main]/Test/File[/tmp/t/foo]/ensure: created
debug: Finishing transaction -615069188
debug: Storing state
debug: Stored state in 0.01 seconds
notice: Finished catalog run in 0.03 seconds
Now, create a test::t class.
/etc/puppet/modules/test/manifests/t.pp:
class test::t {
}
It falls apart. Puppet resolves the include t as being the subclass of
test, rather than the module:
info: Caching catalog for debian.localdomain
debug: Creating default schedules
err: Could not run Puppet configuration client: Could not find
dependency File[/tmp/t] for File[/tmp/t/foo] at
/etc/puppet/modules/test/manifests/init.pp:6
Replacing the require with Class['t'] is rather more telling in the debug:
info: Caching catalog for debian.localdomain
debug: Creating default schedules
debug: Loaded state in 0.00 seconds
debug: /Stage[main]/Test/File[/tmp/t/foo]/require: requires Class[Test::T]
info: Applying configuration version '1293188643'
err: /Stage[main]/Test/File[/tmp/t/foo]/ensure: change from absent to
file failed: Could not set 'file on ensure: No such file or directory -
/tmp/t/foo at /etc/puppet/modules/test/manifests/init.pp:6
debug: Finishing transaction -614790778
debug: Storing state
debug: Stored state in 0.01 seconds
notice: Finished catalog run in 0.03 seconds
Is this by design? If so, how do I specify module, not subclass, in the
include/require?
Is there a bug?
I should have mentioned that I first got the issue under 2.6.2 but have
also tested under 2.6.4
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet SSL Ciphers
On Fri, Dec 24, 2010 at 7:42 AM, Douglas Garstang doug.garst...@gmail.comwrote: Right... I do have listen=true on the clients because I want to be able to trigger puppet to run on a number of hosts centrally with puppetrun. If I set listen != true, I can't do this. Also... if puppet is running from cron, you can't do that either. Replacing webrick with passenger isn't really feasible since passenger isn't available as a nice simple RPM for CentOS 5.5, and I don't know what magic the gems do under the covers in order to build my own passenger RPM. I would also then need to have apache running on every single client. btw: thats not accurate, you can use the puppetlisten/puppetrun from the ext [1] directory, which stand as its on service, but doesnt use webrick (and use as many system resources as puppet). Ohad [1] - https://github.com/puppetlabs/puppet/tree/master/ext/puppetlisten -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: New Employee Announcement -- Daniel Pittman joins Puppet Labs.
On 24 Dec 2010, at 00:15, Nigel Kersten wrote: Seriously though, I'm thrilled Daniel is joining us. Awesome mix of dev and ops and a great community participant to boot. Being Australian is just a bonus on top of those :) Yup, having had the pleasure of working with Daniel several years ago in Melbourne, I'm very glad that he's joined PuppetLabs - and totally agree with you on the dev+ops front. Well done Daniel, hope the move goes well :) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Namespacing, includes and module lookup. Bug?
On 24 December 2010 11:11, Daniel Piddock dgp-g...@corefiling.co.uk wrote:
Hey all,
I'm not sure if I've made a fundamental misunderstanding of Puppet
namespacing and include resolution or whether there's a bug.
Background:
I have a modules, called kerberos, that configures a client for working
on my kerberos domain. I then have a module called ssh that sets up a
basic sshd. I wanted to create a ssh::kerberos class in the ssh module
that extends my ssh setup with kerberos support. I wanted to put a
dependency on the kerberos module. However things fell apart and there
was lots of hair tearing thinking I'd done something stupid (e.g. a
typo.) I now believe it's not that simple...
..
Is this by design? If so, how do I specify module, not subclass, in the
include/require?
Is there a bug?
It's a bug, IMO. One which seems to be cropping up more frequently.
I think it's quite a common use case to have sub-classes of the same name as
top-level classes. For instance, I have a number of classes like
'php::mysql', 'python::mysql' and 'exim::mysql' which all 'include mysql' in
order to pull in common MySQL client functionality.
The trouble is that the resolution of a class name always begins relative to
the current class. If it's able to satisfy the include from within the
current class namespace, including the current class itself, then it won't
check the top-level. It can be demonstrated with a simplified example:
d...@dan-macpro:~$ puppet apply
class bar {
notify { bar: }
}
class foo::bar {
include bar
notify { foo: }
}
include foo::bar
^D
notice: foo
notice: /Stage[main]/Foo::Bar/Notify[foo]/message: defined 'message' as
'foo'
You can see that Class[bar] and Notify[bar] have both been ignored. I
suspect that in a lot of cases this behaviour will go unnoticed by people.
It's not until you add a require to the resource that the loop is then
exposed with a failure:
d...@dan-macpro:~$ puppet apply
class bar {
notify { bar: }
}
class foo::bar {
include bar
notify { foo:
require = Class[bar],
}
}
include foo::bar
^D
err: Could not apply complete catalog: Found dependency cycles in the
following relationships: Notify[foo] = Notify[foo]
There are some hack-ish ways to work around it. You can specify that all of
your includes come from the top scope by prefixing them with ::, such as
'include ::mysql'. But this makes for some pretty long winded manifest
writing if you want to be sure 100% of the time. There isn't
an equivalent syntax for require meta-parameters. You can achieve
something vaguely similar with 'require ::mysql' which will create
dependencies from all resources in the current class. It's certainly not the
same effect though.
I spoke to James Turnbull and some others on IRC about this a couple of
weeks ago. I believe he was going to see whether it fitted in with an
existing ticket. If there isn't one, then something new needs to be
raised. What I'd really like to see is that all class naming becomes
absolute. That would leave much less scope for this kind of confusion and
erratic behaviour.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Namespacing, includes and module lookup. Bug?
On 24/12/10 12:10, Dan Carley wrote:
On 24 December 2010 11:11, Daniel Piddock dgp-g...@corefiling.co.uk
mailto:dgp-g...@corefiling.co.uk wrote:
Hey all,
I'm not sure if I've made a fundamental misunderstanding of Puppet
namespacing and include resolution or whether there's a bug.
Background:
I have a modules, called kerberos, that configures a client for
working
on my kerberos domain. I then have a module called ssh that sets up a
basic sshd. I wanted to create a ssh::kerberos class in the ssh module
that extends my ssh setup with kerberos support. I wanted to put a
dependency on the kerberos module. However things fell apart and there
was lots of hair tearing thinking I'd done something stupid (e.g. a
typo.) I now believe it's not that simple...
..
Is this by design? If so, how do I specify module, not subclass,
in the
include/require?
Is there a bug?
It's a bug, IMO. One which seems to be cropping up more frequently.
I think it's quite a common use case to have sub-classes of the same
name as top-level classes. For instance, I have a number of classes
like 'php::mysql', 'python::mysql' and 'exim::mysql' which all
'include mysql' in order to pull in common MySQL client functionality.
The trouble is that the resolution of a class name always begins
relative to the current class. If it's able to satisfy the include
from within the current class namespace, including the current class
itself, then it won't check the top-level. It can be demonstrated with
a simplified example:
d...@dan-macpro:~$ puppet apply
class bar {
notify { bar: }
}
class foo::bar {
include bar
notify { foo: }
}
include foo::bar
^D
notice: foo
notice: /Stage[main]/Foo::Bar/Notify[foo]/message: defined 'message'
as 'foo'
You can see that Class[bar] and Notify[bar] have both been
ignored. I suspect that in a lot of cases this behaviour will go
unnoticed by people. It's not until you add a require to the resource
that the loop is then exposed with a failure:
d...@dan-macpro:~$ puppet apply
class bar {
notify { bar: }
}
class foo::bar {
include bar
notify { foo:
require = Class[bar],
}
}
include foo::bar
^D
err: Could not apply complete catalog: Found dependency cycles in the
following relationships: Notify[foo] = Notify[foo]
There are some hack-ish ways to work around it. You can specify that
all of your includes come from the top scope by prefixing them with
::, such as 'include ::mysql'. But this makes for some pretty long
winded manifest writing if you want to be sure 100% of the time. There
isn't an equivalent syntax for require meta-parameters. You can
achieve something vaguely similar with 'require ::mysql' which will
create dependencies from all resources in the current class. It's
certainly not the same effect though.
I spoke to James Turnbull and some others on IRC about this a couple
of weeks ago. I believe he was going to see whether it fitted in with
an existing ticket. If there isn't one, then something new needs to be
raised. What I'd really like to see is that all class naming becomes
absolute. That would leave much less scope for this kind of confusion
and erratic behaviour.
That's a tidier example, thanks.
I've done a bit of poking around the issue tracker. Issue 4473
http://projects.puppetlabs.com/issues/4473 appears to be the ticket
related to this. Unfortunately it looks like puppeteers expect this
unusual name resolution order, if they ever knowingly stumble upon it
(e.g. 4483, 4472). Either I need to hack around this problem carefully
or wait a long time for the next major release, if puppetlabs decide to
follow the OO programming crowd.
The use of top scope prefixing seems to work around my current selection
of problems, if I'm consistent in its use.
Thank you,
Dan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Report rrdgraph failed: could not create RRD file
Hi, Today, I set up 'rrdgraph' reports. What could be the cause of this: Dec 24 15:52:35 offman01 puppet-master[20593]: Report rrdgraph failed: Could not create RRD file /var/lib/puppet/rrd/talk.dev.iphion.nl/changes.rrd: you must define at least one Data Source This happens for some nodes, but for other nodes it works fine. For the nodes for which this happens, no HTML files (daily.html, events.html, etc.) are created either. So, for some (good) nodes, I have: /var/lib/puppet/rrd/test2.dev.iphion.nl: total 248 -rw-r--r-- 1 puppet puppet 7592 2010-12-24 14:44 changes-daily.png -rw-r--r-- 1 puppet puppet 8422 2010-12-24 14:44 changes-monthly.png -rw-r--r-- 1 puppet puppet 8295 2010-12-24 14:44 changes-weekly.png -rw-r--r-- 1 puppet puppet 9290 2010-12-24 14:44 changes-yearly.png -rw-r--r-- 1 puppet puppet 226 2010-12-24 14:44 changes.html -rw-r--r-- 1 puppet puppet 2944 2010-12-24 14:44 changes.rrd -rw-r--r-- 1 puppet puppet 218 2010-12-24 14:44 daily.html -rw-r--r-- 1 puppet puppet 6142 2010-12-24 16:16 events-daily.png -rw-r--r-- 1 puppet puppet 8265 2010-12-24 16:16 events-monthly.png -rw-r--r-- 1 puppet puppet 6876 2010-12-24 16:16 events-weekly.png -rw-r--r-- 1 puppet puppet 9013 2010-12-24 16:16 events-yearly.png -rw-r--r-- 1 puppet puppet 221 2010-12-24 14:44 events.html -rw-r--r-- 1 puppet puppet 5656 2010-12-24 16:16 events.rrd -rw-r--r-- 1 puppet puppet 401 2010-12-24 14:44 index.html -rw-r--r-- 1 puppet puppet 228 2010-12-24 14:44 monthly.html -rw-r--r-- 1 puppet puppet 7583 2010-12-24 16:16 resources-daily.png -rw-r--r-- 1 puppet puppet 8694 2010-12-24 16:16 resources-monthly.png -rw-r--r-- 1 puppet puppet 8605 2010-12-24 16:16 resources-weekly.png -rw-r--r-- 1 puppet puppet 9897 2010-12-24 16:16 resources-yearly.png -rw-r--r-- 1 puppet puppet 236 2010-12-24 14:44 resources.html -rw-r--r-- 1 puppet puppet 13792 2010-12-24 16:16 resources.rrd -rw-r--r-- 1 puppet puppet 7213 2010-12-24 16:16 time-daily.png -rw-r--r-- 1 puppet puppet 8339 2010-12-24 16:16 time-monthly.png -rw-r--r-- 1 puppet puppet 8326 2010-12-24 16:16 time-weekly.png -rw-r--r-- 1 puppet puppet 9272 2010-12-24 16:16 time-yearly.png -rw-r--r-- 1 puppet puppet 211 2010-12-24 14:44 time.html -rw-r--r-- 1 puppet puppet 2944 2010-12-24 16:16 time.rrd -rw-r--r-- 1 puppet puppet 223 2010-12-24 14:44 weekly.html -rw-r--r-- 1 puppet puppet 223 2010-12-24 14:44 yearly.html And for others: /var/lib/puppet/rrd/test4.dev.iphion.nl: total 144 -rw-r--r-- 1 puppet puppet 7041 2010-12-24 16:28 events-daily.png -rw-r--r-- 1 puppet puppet 8124 2010-12-24 16:28 events-monthly.png -rw-r--r-- 1 puppet puppet 8079 2010-12-24 16:28 events-weekly.png -rw-r--r-- 1 puppet puppet 9013 2010-12-24 16:28 events-yearly.png -rw-r--r-- 1 puppet puppet 2944 2010-12-24 16:28 events.rrd -rw-r--r-- 1 puppet puppet 6891 2010-12-24 16:28 resources-daily.png -rw-r--r-- 1 puppet puppet 9043 2010-12-24 16:28 resources-monthly.png -rw-r--r-- 1 puppet puppet 7682 2010-12-24 16:28 resources-weekly.png -rw-r--r-- 1 puppet puppet 9897 2010-12-24 16:28 resources-yearly.png -rw-r--r-- 1 puppet puppet 5656 2010-12-24 16:28 resources.rrd -rw-r--r-- 1 puppet puppet 7374 2010-12-24 16:28 time-daily.png -rw-r--r-- 1 puppet puppet 8537 2010-12-24 16:28 time-monthly.png -rw-r--r-- 1 puppet puppet 8316 2010-12-24 16:28 time-weekly.png -rw-r--r-- 1 puppet puppet 9272 2010-12-24 16:28 time-yearly.png -rw-r--r-- 1 puppet puppet 2944 2010-12-24 16:28 time.rrd All nodes are configured identically. Best regards, Martijn. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Namespacing, includes and module lookup. Bug?
On Dec 24, 2010, at 6:41 AM, Daniel Piddock wrote: Unfortunately it looks like puppeteers expect this unusual name resolution order, if they ever knowingly stumble upon it (e.g. 4483, 4472). Either I need to hack around this problem carefully or wait a long time for the next major release, if puppetlabs decide to follow the OO programming crowd. Judging from what I've, since this is a breaking change, I would guess that you are right since Puppet almost never includes breaking changes in a minor release. I'm guessing the very best you can hope for in a minor release is a warning when you do this. Also, I can see it both ways, but to me, the way it's working makes the most sense. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
