Hello,
I''m trying to test out new features of a module before I deploy it and
I
have difficulty with the functions declared by the module.
I''m using an enviroment called "development" where I dropped
the "new"
module and would like to test on a node with the following:
puppetd --environment=development -t --noop
I can see that the file containing the function gets created but puppet
complains that it doesn''t know the function in question:
info: Retrieving plugin
notice: /File[/var/lib/puppet/lib]/mode: mode changed ''775'' to
''755''
notice: /File[/var/lib/puppet/lib/puppet]/mode: mode changed
''775'' to ''755''
notice: /File[/var/lib/puppet/lib/puppet/parser]/mode: mode changed
''775'' to ''755''
notice: /File[/var/lib/puppet/lib/puppet/parser/functions]/mode: mode
changed ''775'' to ''755''
notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/debian_nextcodename.rb]/ensure:
defined content as ''{md5}930cce14ff8a84fa29f9a2312d564d37''
notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/debian_nextrelease.rb]/ensure:
defined content as ''{md5}f314fb8d164034f1562acb00924d4232''
notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/debian_release.rb]/ensure:
defined content as ''{md5}cb4789fe5e233f2ae193e84a754350f9''
notice:
/File[/var/lib/puppet/lib/puppet/parser/functions/debian_release_version.rb]/ensure:
defined content as ''{md5}8cd893cbb749897d17a28dd17a06ef6c''
info: Loading downloaded plugin
/var/lib/puppet/lib/puppet/parser/functions/debian_nextcodename.rb
info: Loading downloaded plugin
/var/lib/puppet/lib/puppet/parser/functions/debian_nextrelease.rb
info: Loading downloaded plugin
/var/lib/puppet/lib/puppet/parser/functions/debian_release.rb
info: Loading downloaded plugin
/var/lib/puppet/lib/puppet/parser/functions/debian_release_version.rb
info: Loading facts in sshkeys
info: Loading facts in interfaces
info: Loading facts in acpi_available
info: Loading facts in vserver
info: Loading facts in mysql
info: Loading facts in mountpoints
info: Loading facts in netmask
info: Loading facts in smbldap_installed
info: Loading facts in virtual
info: Loading facts in sshkeys
info: Loading facts in interfaces
info: Loading facts in acpi_available
info: Loading facts in vserver
info: Loading facts in mysql
info: Loading facts in mountpoints
info: Loading facts in netmask
info: Loading facts in smbldap_installed
info: Loading facts in virtual
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Unknown function debian_release at
/etc/puppet/modules-development/apt/manifests/init.pp:73 on node
node.mydomain.net
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
There''s a mention on the wiki [1] about plugins vs. environments but I
don''t really get what would be needed.
[1] :
http://projects.puppetlabs.com/projects/1/wiki/Using_Multiple_Environments#Plugins+and+Facts
Could anybody help me sort out a way to do my tests?
--
Gabriel Filion
--
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.
On Tue, Jun 14, 2011 at 1:26 PM, Gabriel Filion <lelutin@gmail.com> wrote:> Hello, > > I''m trying to test out new features of a module before I deploy it and I > have difficulty with the functions declared by the module. > > I''m using an enviroment called "development" where I dropped the "new" > module and would like to test on a node with the following: > > puppetd --environment=development -t --noop > > I can see that the file containing the function gets created but puppet > complains that it doesn''t know the function in question: >Functions get executed master side, so even though they get delivered to the node, they need to be accessible on the master. What version of Puppet are you running on the master and nodes?> > info: Retrieving plugin > notice: /File[/var/lib/puppet/lib]/mode: mode changed ''775'' to ''755'' > notice: /File[/var/lib/puppet/lib/puppet]/mode: mode changed ''775'' to ''755'' > notice: /File[/var/lib/puppet/lib/puppet/parser]/mode: mode changed > ''775'' to ''755'' > notice: /File[/var/lib/puppet/lib/puppet/parser/functions]/mode: mode > changed ''775'' to ''755'' > notice: > > /File[/var/lib/puppet/lib/puppet/parser/functions/debian_nextcodename.rb]/ensure: > defined content as ''{md5}930cce14ff8a84fa29f9a2312d564d37'' > notice: > > /File[/var/lib/puppet/lib/puppet/parser/functions/debian_nextrelease.rb]/ensure: > defined content as ''{md5}f314fb8d164034f1562acb00924d4232'' > notice: > > /File[/var/lib/puppet/lib/puppet/parser/functions/debian_release.rb]/ensure: > defined content as ''{md5}cb4789fe5e233f2ae193e84a754350f9'' > notice: > > /File[/var/lib/puppet/lib/puppet/parser/functions/debian_release_version.rb]/ensure: > defined content as ''{md5}8cd893cbb749897d17a28dd17a06ef6c'' > info: Loading downloaded plugin > /var/lib/puppet/lib/puppet/parser/functions/debian_nextcodename.rb > info: Loading downloaded plugin > /var/lib/puppet/lib/puppet/parser/functions/debian_nextrelease.rb > info: Loading downloaded plugin > /var/lib/puppet/lib/puppet/parser/functions/debian_release.rb > info: Loading downloaded plugin > /var/lib/puppet/lib/puppet/parser/functions/debian_release_version.rb > info: Loading facts in sshkeys > info: Loading facts in interfaces > info: Loading facts in acpi_available > info: Loading facts in vserver > info: Loading facts in mysql > info: Loading facts in mountpoints > info: Loading facts in netmask > info: Loading facts in smbldap_installed > info: Loading facts in virtual > info: Loading facts in sshkeys > info: Loading facts in interfaces > info: Loading facts in acpi_available > info: Loading facts in vserver > info: Loading facts in mysql > info: Loading facts in mountpoints > info: Loading facts in netmask > info: Loading facts in smbldap_installed > info: Loading facts in virtual > err: Could not retrieve catalog from remote server: Error 400 on SERVER: > Unknown function debian_release at > /etc/puppet/modules-development/apt/manifests/init.pp:73 on node > node.mydomain.net > warning: Not using cache on failed catalog > err: Could not retrieve catalog; skipping run > > There''s a mention on the wiki [1] about plugins vs. environments but I > don''t really get what would be needed. > > [1] : > > http://projects.puppetlabs.com/projects/1/wiki/Using_Multiple_Environments#Plugins+and+Facts > > Could anybody help me sort out a way to do my tests? > > -- > Gabriel Filion > > -- > 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. > >-- Nigel Kersten Product, Puppet Labs @nigelkersten -- 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.
On 11-06-14 04:39 PM, Nigel Kersten wrote:> On Tue, Jun 14, 2011 at 1:26 PM, Gabriel Filion <lelutin@gmail.com > <mailto:lelutin@gmail.com>> wrote: > I''m trying to test out new features of a module before I deploy it and I > have difficulty with the functions declared by the module. > > I''m using an enviroment called "development" where I dropped the "new" > module and would like to test on a node with the following: > > puppetd --environment=development -t --noop > > I can see that the file containing the function gets created but puppet > complains that it doesn''t know the function in question: > > Functions get executed master side, so even though they get delivered to > the node, they need to be accessible on the master.oh, ok.. so I''d need to have that new plugin used by the master first?> What version of Puppet are you running on the master and nodes?master: 0.25.4 node: 0.25.4> info: Retrieving plugin > notice: /File[/var/lib/puppet/lib]/mode: mode changed ''775'' to ''755'' > notice: /File[/var/lib/puppet/lib/puppet]/mode: mode changed ''775'' > to ''755'' > notice: /File[/var/lib/puppet/lib/puppet/parser]/mode: mode changed > ''775'' to ''755'' > notice: /File[/var/lib/puppet/lib/puppet/parser/functions]/mode: mode > changed ''775'' to ''755'' > notice: > /File[/var/lib/puppet/lib/puppet/parser/functions/debian_nextcodename.rb]/ensure: > defined content as ''{md5}930cce14ff8a84fa29f9a2312d564d37'' > notice: > /File[/var/lib/puppet/lib/puppet/parser/functions/debian_nextrelease.rb]/ensure: > defined content as ''{md5}f314fb8d164034f1562acb00924d4232'' > notice: > /File[/var/lib/puppet/lib/puppet/parser/functions/debian_release.rb]/ensure: > defined content as ''{md5}cb4789fe5e233f2ae193e84a754350f9'' > notice: > /File[/var/lib/puppet/lib/puppet/parser/functions/debian_release_version.rb]/ensure: > defined content as ''{md5}8cd893cbb749897d17a28dd17a06ef6c'' > info: Loading downloaded plugin > /var/lib/puppet/lib/puppet/parser/functions/debian_nextcodename.rb > info: Loading downloaded plugin > /var/lib/puppet/lib/puppet/parser/functions/debian_nextrelease.rb > info: Loading downloaded plugin > /var/lib/puppet/lib/puppet/parser/functions/debian_release.rb > info: Loading downloaded plugin > /var/lib/puppet/lib/puppet/parser/functions/debian_release_version.rb > info: Loading facts in sshkeys > info: Loading facts in interfaces > info: Loading facts in acpi_available > info: Loading facts in vserver > info: Loading facts in mysql > info: Loading facts in mountpoints > info: Loading facts in netmask > info: Loading facts in smbldap_installed > info: Loading facts in virtual > info: Loading facts in sshkeys > info: Loading facts in interfaces > info: Loading facts in acpi_available > info: Loading facts in vserver > info: Loading facts in mysql > info: Loading facts in mountpoints > info: Loading facts in netmask > info: Loading facts in smbldap_installed > info: Loading facts in virtual > err: Could not retrieve catalog from remote server: Error 400 on SERVER: > Unknown function debian_release at > /etc/puppet/modules-development/apt/manifests/init.pp:73 on node > node.mydomain.net <http://node.mydomain.net> > warning: Not using cache on failed catalog > err: Could not retrieve catalog; skipping run > > There''s a mention on the wiki [1] about plugins vs. environments but I > don''t really get what would be needed. > > [1] : > http://projects.puppetlabs.com/projects/1/wiki/Using_Multiple_Environments#Plugins+and+Facts-- Gabriel Filion -- 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.
On Wed, Jun 15, 2011 at 8:56 AM, Gabriel Filion <lelutin@gmail.com> wrote:> On 11-06-14 04:39 PM, Nigel Kersten wrote: > > On Tue, Jun 14, 2011 at 1:26 PM, Gabriel Filion <lelutin@gmail.com > > <mailto:lelutin@gmail.com>> wrote: > > I''m trying to test out new features of a module before I deploy it > and I > > have difficulty with the functions declared by the module. > > > > I''m using an enviroment called "development" where I dropped the > "new" > > module and would like to test on a node with the following: > > > > puppetd --environment=development -t --noop > > > > I can see that the file containing the function gets created but > puppet > > complains that it doesn''t know the function in question: > > > > Functions get executed master side, so even though they get delivered to > > the node, they need to be accessible on the master. > > oh, ok.. so I''d need to have that new plugin used by the master first? > > > What version of Puppet are you running on the master and nodes? > > master: 0.25.4 > node: 0.25.4 > >Ah. For that version, you''ll need to make sure the function is in the libdir of the puppet master, as I believe that functions from environments weren''t accessible to the master in 0.25.x -- 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.
I got further into the problem thanks to your help.. but there''s something else now. On 11-06-15 12:36 PM, Nigel Kersten wrote:> > Functions get executed master side, so even though they get > delivered to > > the node, they need to be accessible on the master. > > oh, ok.. so I''d need to have that new plugin used by the master first? > > > What version of Puppet are you running on the master and nodes? > > master: 0.25.4 > node: 0.25.4 > > > Ah. For that version, you''ll need to make sure the function is in the > libdir of the puppet master, as I believe that functions from > environments weren''t accessible to the master in 0.25.xthat seems to have worked. I copied the files in the master''s lib dir and it got further. However, I''m now stuck on another weirdness between environments: I get an error about some resource that gets redefined between the init.pp from the production environment and another manifest from the development environment called moduledir.pp in the puppet master''s config I have: [main] logdir=/var/log/puppet vardir=/var/lib/puppet rundir=/var/run/puppet ssldir=/var/lib/puppet/ssl environment=production [...] [development] modulepath=/etc/puppet/modules-development:/etc/puppet/modules:/usr/share/puppet/modules I was expecting the declaration in the [development] section to mean that if modules are found in the first directory, then the other dirs are not inspected.. But apparently this is not the case. This could lead to some nasty bugs when testing things out with such a mixed environment. Is there a work around to make the other module of the same name in the /etc/puppet/modules directory not influence the development environment? -- Gabriel Filion -- 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.
If you want your environments to never be able to affect one another then your module paths should not contain any common directories. On Thu, Jun 16, 2011 at 12:33 PM, Gabriel Filion <lelutin@gmail.com> wrote:> I got further into the problem thanks to your help.. but there''s > something else now. > > On 11-06-15 12:36 PM, Nigel Kersten wrote: > > > Functions get executed master side, so even though they get > > delivered to > > > the node, they need to be accessible on the master. > > > > oh, ok.. so I''d need to have that new plugin used by the master > first? > > > > > What version of Puppet are you running on the master and nodes? > > > > master: 0.25.4 > > node: 0.25.4 > > > > > > Ah. For that version, you''ll need to make sure the function is in the > > libdir of the puppet master, as I believe that functions from > > environments weren''t accessible to the master in 0.25.x > > that seems to have worked. I copied the files in the master''s lib dir > and it got further. However, I''m now stuck on another weirdness between > environments: > > I get an error about some resource that gets redefined between the > init.pp from the production environment and another manifest from the > development environment called moduledir.pp > > in the puppet master''s config I have: > > [main] > logdir=/var/log/puppet > vardir=/var/lib/puppet > rundir=/var/run/puppet > ssldir=/var/lib/puppet/ssl > environment=production > > [...] > > [development] > > modulepath=/etc/puppet/modules-development:/etc/puppet/modules:/usr/share/puppet/modules > > > I was expecting the declaration in the [development] section to mean > that if modules are found in the first directory, then the other dirs > are not inspected.. But apparently this is not the case. > > This could lead to some nasty bugs when testing things out with such a > mixed environment. > Is there a work around to make the other module of the same name in the > /etc/puppet/modules directory not influence the development environment? > > -- > Gabriel Filion > > -- > 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.
Or what you might want to do is to create a specific common directory for code that should be shared, and per-environment directories which contain code that should not be shared. If you find that something should no longer be common, you then move it into the per-env directories as appropriate. -- Nathan Clemons http://www.livemocha.com The worlds largest online language learning community On Thu, Jun 16, 2011 at 12:42 PM, Aaron Grewell <aaron.grewell@gmail.com>wrote:> If you want your environments to never be able to affect one another then > your module paths should not contain any common directories. > > > On Thu, Jun 16, 2011 at 12:33 PM, Gabriel Filion <lelutin@gmail.com>wrote: > >> I got further into the problem thanks to your help.. but there''s >> something else now. >> >> On 11-06-15 12:36 PM, Nigel Kersten wrote: >> > > Functions get executed master side, so even though they get >> > delivered to >> > > the node, they need to be accessible on the master. >> > >> > oh, ok.. so I''d need to have that new plugin used by the master >> first? >> > >> > > What version of Puppet are you running on the master and nodes? >> > >> > master: 0.25.4 >> > node: 0.25.4 >> > >> > >> > Ah. For that version, you''ll need to make sure the function is in the >> > libdir of the puppet master, as I believe that functions from >> > environments weren''t accessible to the master in 0.25.x >> >> that seems to have worked. I copied the files in the master''s lib dir >> and it got further. However, I''m now stuck on another weirdness between >> environments: >> >> I get an error about some resource that gets redefined between the >> init.pp from the production environment and another manifest from the >> development environment called moduledir.pp >> >> in the puppet master''s config I have: >> >> [main] >> logdir=/var/log/puppet >> vardir=/var/lib/puppet >> rundir=/var/run/puppet >> ssldir=/var/lib/puppet/ssl >> environment=production >> >> [...] >> >> [development] >> >> modulepath=/etc/puppet/modules-development:/etc/puppet/modules:/usr/share/puppet/modules >> >> >> I was expecting the declaration in the [development] section to mean >> that if modules are found in the first directory, then the other dirs >> are not inspected.. But apparently this is not the case. >> >> This could lead to some nasty bugs when testing things out with such a >> mixed environment. >> Is there a work around to make the other module of the same name in the >> /etc/puppet/modules directory not influence the development environment? >> >> -- >> Gabriel Filion >> >> -- >> 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. >-- 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.
On 11-06-16 03:47 PM, Nathan Clemons wrote:> Or what you might want to do is to create a specific common directory > for code that should be shared, and per-environment directories which > contain code that should not be shared. If you find that something > should no longer be common, you then move it into the per-env > directories as appropriate.Oh ok ... I''ll have to work something out then.. this is more complicated to use than I thought. Thanks everyone for all the help. -- Gabriel Filion -- 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.
On Thu, Jun 16, 2011 at 1:59 PM, Gabriel Filion <lelutin@gmail.com> wrote:> On 11-06-16 03:47 PM, Nathan Clemons wrote: > > Or what you might want to do is to create a specific common directory > > for code that should be shared, and per-environment directories which > > contain code that should not be shared. If you find that something > > should no longer be common, you then move it into the per-env > > directories as appropriate. > > Oh ok ... I''ll have to work something out then.. this is more > complicated to use than I thought. >This shouldn''t be that complicated. Do you have modules with the same name in multiple modulepath components? If not, then you should be seeing the behavior you''re expecting. It''s not entirely unreasonable to expect that if module ''foo'' is found in one modulepath component, that no other module named ''foo'' should come into play, but I think we have some edge cases here. Please feel free to file a feature request around modulepath behaving more like $PATH in the shell does. -- 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.
On 06/17/2011 10:52 AM, Nigel Kersten wrote:> It''s not entirely unreasonable to expect that if module ''foo'' is found > in one modulepath component, that no other module named ''foo'' should > come into play, but I think we have some edge cases here. Please feel > free to file a feature request around modulepath behaving more like > $PATH in the shell does.I actually played around with this for a while, trying to come up with a scheme for stackable configurations. The hack needed to make it work is to install links higher in the stack to files lower in the stack, because where ever puppet finds a module in the stack of modules trees, that module tree is where it looks for all the other related files. It will not drill down through the stack (''path'') for each file of the module. Nor would you want it to. Anyway, it ended up ugly, and I went looking for a better way. -- vagn -- 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.