Re: [Puppet Users] Migration from 0.25.4 to the latest puppet and relating issues ....

67 views
Skip to first unread message

Pete Brown

unread,
May 19, 2013, 11:43:19 PM5/19/13
to puppet-users
You just hit the biggest.



On 19 May 2013 03:16, Jagan Kommineni <jagan.k...@gmail.com> wrote:
Team,

I am in the process of investigating issues that going to popup during migration process. Currently I have installed puppet 3.1.1 from yum repository of puppetlabs 

The installation process is pretty much strait forward but when I try to test the modules which were written based on the puppet-0.25.4, 

Most of the files sourced from the puppet server to agents using the following format, 

source => [ "puppet:///bamssh/sshd_config.$hostname", "puppet:///bamssh/sshd_config.$virtual", "puppet:///bamssh/sshd_config.$operatingsystemrelease" ],

I am getting the following error message when I run the following command on master server ... (puppet apply bamssh/test/init.pp --debug)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Error: /Stage[main]/Bamssh/File[/etc/ssh/sshd_config]: Could not evaluate: Could not retrieve information from environment production source(s) puppet:///modules/bamssh/sshd_config.oel-puppet-master, puppet:///modules/bamssh/sshd_config.virtualbox, puppet:///bamssh/sshd_config.5.9
Notice: /Stage[main]/Bamssh/Service[sshd]: Dependency File[/etc/ssh/sshd_config] has failures: true
Warning: /Stage[main]/Bamssh/Service[sshd]: Skipping because of failed dependencies
---------------------------------------------------------------------------------------------------

When I specify the modules in the path, everything went fine when I run the same command (puppet apply bamssh/test/init.pp --debug) ...
 source => [ "puppet:///modules/bamssh/sshd_config.$hostname", "puppet:///modules/bamssh/sshd_config.$virtual", "puppet:///modules/bamssh/sshd_config.$operatingsystemrelease" ],
------------------------
Debug: Executing '/sbin/service sshd status'
Debug: /Schedule[never]: Skipping device resources because running on a host
Debug: /Schedule[weekly]: Skipping device resources because running on a host
Debug: /Schedule[puppet]: Skipping device resources because running on a host
Debug: Finishing transaction 70344638024840
Debug: Storing state
Debug: Stored state in 0.01 seconds
Notice: Finished catalog run in 0.32 seconds
------------------------------------------------------------------------------------------------------------

There are many places that requires this change, is there any round about to use old format in specifying path without the word "modules" word in sourcing file from puppet server to client (node) 

Could someone advise best-way to migrate from puppet-0.25.4 to the latest puppet, I will appreciate if someone share their experiences in migrating old puppet version to the latest ...
 
Thank you very much in advance ,,,...

--
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...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

jcbollinger

unread,
May 20, 2013, 9:31:39 AM5/20/13
to puppet...@googlegroups.com


Those are good documents to read, but neither appears to discuss the specific issue at hand.  As it turns out, the URI format in question was deprecated long before Puppet 3.  In fact, I think it was already deprecated in the OP's v. 0.25.4, and I'm sure it was deprecated by the next major version, 2.6.

There is no workaround short of hacking the master, but the manifest text that needs modified (to resolve this particular issue) is pretty distinctive, and the change needed is pretty straightforward.  It shouldn't be too hard to automate the change via sed.  Something like

find /etc/puppet/modules -name '*.pp' -exec /bin/sed -i -e 's,puppet:///,puppet:///modules/,g' {} ';'

would probably do the trick if every single puppet: URI needs changed.  Accommodation could also be made for URIs that are already in the needed form, if necessary. 

Note: that command is untested.  Understand what it does, and how, and why before running it.  Back up your manifests first.

Note, too, that the newer form is compatible with Puppet 0.25 (as I recall), so it should be possible to perform the URI update separately from the Puppet update, so as to test the former first.
 

There are way too many changed between 0.25.4 and 3.1.1
You just hit the biggest.



I can't agree that the URI format is the biggest change.  I think far and away the biggest is the removal of dynamic scoping (after its deprecation in Puppet 2.7).  Still v0.25 -> v3.1 is a very big upgrade.  I would recommend upgrading first to Puppet 2.7 for a short transition period in order to be warned of dynamic scope uses, and possibly of uses of other deprecated features.  A significant purpose of v2.7 was to help users prepare for v3, and it can still serve that purpose.  I don't recall offhand whether v2.7 still recognizes the old URI form, though.


John

Pete Brown

unread,
May 20, 2013, 10:58:58 PM5/20/13
to puppet-users
On 20 May 2013 23:31, jcbollinger <John.Bo...@stjude.org> wrote:


Those are good documents to read, but neither appears to discuss the specific issue at hand.  As it turns out, the URI format in question was deprecated long before Puppet 3.  In fact, I think it was already deprecated in the OP's v. 0.25.4, and I'm sure it was deprecated by the next major version, 2.6.

Yep that's true.
It has been a while since I had a 0.25 server.
 

There is no workaround short of hacking the master, but the manifest text that needs modified (to resolve this particular issue) is pretty distinctive, and the change needed is pretty straightforward.  It shouldn't be too hard to automate the change via sed.  Something like

find /etc/puppet/modules -name '*.pp' -exec /bin/sed -i -e 's,puppet:///,puppet:///modules/,g' {} ';'

would probably do the trick if every single puppet: URI needs changed.  Accommodation could also be made for URIs that are already in the needed form, if necessary. 

Note: that command is untested.  Understand what it does, and how, and why before running it.  Back up your manifests first.

Note, too, that the newer form is compatible with Puppet 0.25 (as I recall), so it should be possible to perform the URI update separately from the Puppet update, so as to test the former first.
 

There are way too many changed between 0.25.4 and 3.1.1
You just hit the biggest.



I can't agree that the URI format is the biggest change.  I think far and away the biggest is the removal of dynamic scoping (after its deprecation in Puppet 2.7).  Still v0.25 -> v3.1 is a very big upgrade.  I would recommend upgrading first to Puppet 2.7 for a short transition period in order to be warned of dynamic scope uses, and possibly of uses of other deprecated features.  A significant purpose of v2.7 was to help users prepare for v3, and it can still serve that purpose.  I don't recall offhand whether v2.7 still recognizes the old URI form, though.

Again this is true.
It was the biggest change in my upgrade cycle and I never relied of dynamic scoping so it slipped my mind.

 


John
Reply all
Reply to author
Forward
0 new messages