module version support?

[Schofield]

Does puppet have any built in support for applying different versions of modules to different nodes?  I haven't come across any documentation describing such a feature so I assume no but wanted to verify.  As a follow up question are there any best practices to do such a thing?

[Throwe, Jesse]

Environments would probably be a good starting point for what your after.

http://docs.puppetlabs.com/guides/environment.html

On Thu, Dec 27, 2012 at 8:06 AM, Schofield <dbsch...@gmail.com> wrote:

Does puppet have any built in support for applying different versions of modules to different nodes?  I haven't come across any documentation describing such a feature so I assume no but wanted to verify.  As a follow up question are there any best practices to do such a thing?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/zzn_ldfcOoIJ.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Schofield]

On Thursday, December 27, 2012 8:38:47 AM UTC-6, Jesse Throwe wrote:

Environments would probably be a good starting point for what your after.

http://docs.puppetlabs.com/guides/environment.html

Not quite what I was after.  I already have dev/test/production environments that handle different versions of modules during the release process.  I'm pondering the situation where a version of a module makes it to the production environment and is not backwards compatible on some nodes.  At this point I am wondering if puppet has any support for applying the new version of the module to some set of nodes and applying the old version to the remaining nodes?  After researching I have to conclude no. 

[Throwe, Jesse]

You are not limited to just dev/test/prod.  So if you were aware of the incompatibility you could create a 'prod-migration' environment and move sets of machines over at a time.

Or take it one step further and integrate your SCM and puppet ( http://puppetlabs.com/blog/git-workflow-and-puppet-environments/ ), and use an ENC such as dashboard, foreman, LDAP, etc to make changing the environment a simple data change. This combination of things is the basis that we use to develop vet and migrate incompatible changes to the production environment.

Ultimately it seems you may be trying to solve a problem that is not really a puppet problem per-se.

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/0l0XZq_5SqMJ.

[Schofield]

Or take it one step further and integrate your SCM and puppet ( http://puppetlabs.com/blog/git-workflow-and-puppet-environments/ ), and use an ENC such as dashboard, foreman, LDAP, etc to make changing the environment a simple data change. This combination of things is the basis that we use to develop vet and migrate incompatible changes to the production environment.

Ultimately it seems you may be trying to solve a problem that is not really a puppet problem per-se.

You are correct the problem would be introduced by bad module code.  Not really a puppet problem.  We do use the git workflow and dynamic environments so your suggestion for a new environment is definitely workable.  Thanks for your comments.