I want to setup a node using a three step process
1) download node requirements (git)
2) download modules to fit requirements (puppet)
3) Bring up the node in the required state (puppet)
The second step is the one I am having trouble with. I want a file
(master.pp) to list out all the modules and what versions are needed before
applying the site.pp file. From what I have been able to find there are
two possible approaches.
1) Use some module to download and unzip tars. In this master.pp file use
the module to download the other modules from urls and extract them in the
module path. The problem I have is that I cannot figure out how to get the
modulepath in the master.pp file and parse it such that I can extract the
tars in the right location. I tried something like:
archive {"$file":
ensure => present,
url => "$url",
checksum => false,
extension => "tar.gz",
target => split("$::modulepath", ":")[0],
}
But that doesn''t work.
2) There is another module called puppet_module
(https://github.com/rcoleman/puppet_module_provider) which allows you to
download and install modules from puppetforge. This module works great.
Except that I need to download modules from an intranet location not an
internet location. I do not have control over puppetforge so I do not have
control over how long stuff stays up there, when it changes etc. I need to
house the modules on a local file store such that as we make the decision
to upgrade we can do those upgrades other then that the modules will always
remain available. The puppet_module (reading the source code) does have a
source parameter. I assume then you could point it at something other than
puppetforge. But it is not documented and I am not sure I can easily
produce a in house puppet forge that would have the needed filesystem
layout for puppet_module to work.
Have other people looked into this problem? What have they come up with?
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@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.
Unless you''re using puppet apply, you don''t download modules to the individual nodes, you download them to your master. The master uses the modules to compile a catalog which it then ships off to a node. Or in other words, I''m not sure what your question is. Why do your nodes need to download modules? On Friday, March 15, 2013 9:24:36 AM UTC-7, Mike Power wrote:> > I want to setup a node using a three step process > 1) download node requirements (git) > 2) download modules to fit requirements (puppet) > 3) Bring up the node in the required state (puppet) > > The second step is the one I am having trouble with. I want a file > (master.pp) to list out all the modules and what versions are needed before > applying the site.pp file. From what I have been able to find there are > two possible approaches. > > 1) Use some module to download and unzip tars. In this master.pp file use > the module to download the other modules from urls and extract them in the > module path. The problem I have is that I cannot figure out how to get the > modulepath in the master.pp file and parse it such that I can extract the > tars in the right location. I tried something like: > archive {"$file": > ensure => present, > url => "$url", > checksum => false, > extension => "tar.gz", > target => split("$::modulepath", ":")[0], > } > > But that doesn''t work. > > > 2) There is another module called puppet_module ( > https://github.com/rcoleman/puppet_module_provider) which allows you to > download and install modules from puppetforge. This module works great. > Except that I need to download modules from an intranet location not an > internet location. I do not have control over puppetforge so I do not have > control over how long stuff stays up there, when it changes etc. I need to > house the modules on a local file store such that as we make the decision > to upgrade we can do those upgrades other then that the modules will always > remain available. The puppet_module (reading the source code) does have a > source parameter. I assume then you could point it at something other than > puppetforge. But it is not documented and I am not sure I can easily > produce a in house puppet forge that would have the needed filesystem > layout for puppet_module to work. > > Have other people looked into this problem? What have they come up with? >-- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@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.
I use vagrant. So first I apply on the host machine, then I apply on the virtual machine. Either solution I use whether master slave or apply I still have not solved the problem of downloading the right modules. On Friday, March 15, 2013 8:31:58 PM UTC-7, Ellison Marks wrote:> > Unless you''re using puppet apply, you don''t download modules to the > individual nodes, you download them to your master. The master uses the > modules to compile a catalog which it then ships off to a node. Or in other > words, I''m not sure what your question is. Why do your nodes need to > download modules? > > On Friday, March 15, 2013 9:24:36 AM UTC-7, Mike Power wrote: >> >> I want to setup a node using a three step process >> 1) download node requirements (git) >> 2) download modules to fit requirements (puppet) >> 3) Bring up the node in the required state (puppet) >> >> The second step is the one I am having trouble with. I want a file >> (master.pp) to list out all the modules and what versions are needed before >> applying the site.pp file. From what I have been able to find there are >> two possible approaches. >> >> 1) Use some module to download and unzip tars. In this master.pp file >> use the module to download the other modules from urls and extract them in >> the module path. The problem I have is that I cannot figure out how to get >> the modulepath in the master.pp file and parse it such that I can extract >> the tars in the right location. I tried something like: >> archive {"$file": >> ensure => present, >> url => "$url", >> checksum => false, >> extension => "tar.gz", >> target => split("$::modulepath", ":")[0], >> } >> >> But that doesn''t work. >> >> >> 2) There is another module called puppet_module ( >> https://github.com/rcoleman/puppet_module_provider) which allows you to >> download and install modules from puppetforge. This module works great. >> Except that I need to download modules from an intranet location not an >> internet location. I do not have control over puppetforge so I do not have >> control over how long stuff stays up there, when it changes etc. I need to >> house the modules on a local file store such that as we make the decision >> to upgrade we can do those upgrades other then that the modules will always >> remain available. The puppet_module (reading the source code) does have a >> source parameter. I assume then you could point it at something other than >> puppetforge. But it is not documented and I am not sure I can easily >> produce a in house puppet forge that would have the needed filesystem >> layout for puppet_module to work. >> >> Have other people looked into this problem? What have they come up with? >> >-- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@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.
On Sat, Mar 16, 2013 at 8:07 PM, Mike Power <dodtsair@gmail.com> wrote:> I use vagrant. So first I apply on the host machine, then I apply on the > virtual machine. >If you''re using Vagrant, have you considered maintaining the modules on your host computer and sharing them into vagrant via shared folders? I do that for my module testing and find that more manageable. Alternatively, you could run the shell provisioner against some `puppet module install` commands or a stand-alone manifest with those puppet_module resources. When it comes to not accessing the Forge directly, you could try using Puppets built-in proxy support http://docs.puppetlabs.com/references/latest/configuration.html#httpproxyhost. If you''re interested in an on-premise Forge, please email me off-list with contact information and what features you''d like out of it. We don''t have enough engineers to tackle this problem yet, but when we do, I want to hit the ground running. HTH, --Ryan -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@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.