I have the class below and it doens;t work. That it is, it does work if I
run it twice. On the second puppet-run everything works, on the first it
doesn''t run the third, because of failed dependencies.
Any suggestions?
class ebssnapshot::prepare {
exec{"netamzonec2a":
command => "export PERL_MM_USE_DEFAULT=1; cpan o conf
prerequisites_policy follow",
}
exec{"netamzonec2b":
command => "cpan o conf commit",
require => Exec["netamzonec2a"]
}
exec{"netamzonec2c":
command => "cpan -i Net::Amazon::EC2",
require => Exec["netamzonec2b"]
}
}
--
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 Sun, 15 Aug 2010, Bram Enning wrote:> I have the class below and it doens;t work. That it is, it does work if I > run it twice. On the second puppet-run everything works, on the first it > doesn''t run the third, because of failed dependencies. > > Any suggestions? >cpanminus might make your life eaiser. http://github.com/miyagawa/cpanminus -- bob walker buses should be purple and bendy -- 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.
Bram Enning <bramenning@gmail.com> writes:> I have the class below and it doens;t work. That it is, it does work if I > run it twice. On the second puppet-run everything works, on the first it > doesn''t run the third, because of failed dependencies. > > Any suggestions?Well, the first one is that you would be much, much, much, much better off not doing this on each host: this is utterly non-deterministic. Instead, package your Perl code somehow and deploy *that* to the systems. When you need to upgrade, upgrade the package and redeploy. This could be as unsophisticated as a tarball you unpack, although I would strongly suggest you use whatever platform packaging you have to manage things. That way you gain the ability to have *exactly* the same configuration deployed to your systems, with the same versions, every time you deploy. (Your current code will upgrade Net::Amazon::EC2 automatically, which will eventually break your application, I promise. ;) Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- 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 have to agree with Daniel on this one. While it''s annoying to build Solaris (in my case) packages for every CPAN package you want to install, then end result is that I can control the installed version *precisely*. While it may never have been a problem for you, I''ve been bitten more than once by CPAN upgrades that break my software, so "old" systems work while new systems don''t. On Sun, Aug 15, 2010 at 7:55 PM, Daniel Pittman <daniel@rimspace.net> wrote:> Bram Enning <bramenning@gmail.com> writes: > > > I have the class below and it doens;t work. That it is, it does work if I > > run it twice. On the second puppet-run everything works, on the first it > > doesn''t run the third, because of failed dependencies. > > > > Any suggestions? > > Well, the first one is that you would be much, much, much, much better off > not > doing this on each host: this is utterly non-deterministic. > > Instead, package your Perl code somehow and deploy *that* to the systems. > When you need to upgrade, upgrade the package and redeploy. > > This could be as unsophisticated as a tarball you unpack, although I would > strongly suggest you use whatever platform packaging you have to manage > things. > > > That way you gain the ability to have *exactly* the same configuration > deployed to your systems, with the same versions, every time you deploy. > (Your current code will upgrade Net::Amazon::EC2 automatically, which will > eventually break your application, I promise. ;) > > Daniel > > -- > ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 > 707 > ♽ made with 100 percent post-consumer electrons > > -- > 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<puppet-users%2Bunsubscribe@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.
Brian Gallew <geek@gallew.org> writes: It is always nice if y''all follow the existing quoting style in mails; it makes it much less confusing to follow later.> I have to agree with Daniel on this one. While it''s annoying to build > Solaris (in my case) packages for every CPAN package you want to install, > then end result is that I can control the installed version *precisely*. > While it may never have been a problem for you, I''ve been bitten more than > once by CPAN upgrades that break my software, so "old" systems work while > new systems don''t.FWIW, at work we gave up on that despite using Debian and having pretty good support tools to do the job. We settled on packaging all the Perl bits we use as a single package and landing that everywhere. That gives us a good balance between the two paths, and has worked out well to date. Plus it keeps system Perl and company Perl separate... Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- 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.
Sorry, when you use Gmail you end up top-posting whether you like it or not. On Mon, Aug 16, 2010 at 8:45 PM, Daniel Pittman <daniel@rimspace.net> wrote:> Brian Gallew <geek@gallew.org> writes: > > It is always nice if y''all follow the existing quoting style in mails; it > makes it much less confusing to follow later. > > > I have to agree with Daniel on this one. While it''s annoying to build > > Solaris (in my case) packages for every CPAN package you want to install, > > then end result is that I can control the installed version *precisely*. > > While it may never have been a problem for you, I''ve been bitten more > than > > once by CPAN upgrades that break my software, so "old" systems work while > > new systems don''t. > > FWIW, at work we gave up on that despite using Debian and having pretty > good > support tools to do the job. We settled on packaging all the Perl bits we > use > as a single package and landing that everywhere. > > That gives us a good balance between the two paths, and has worked out well > to > date. Plus it keeps system Perl and company Perl separate... > > Daniel > > -- > ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 > 707 > ♽ made with 100 percent post-consumer electrons > > -- > 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<puppet-users%2Bunsubscribe@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.
Thanks for all your answers, but I settled for a different solution.
It appeared the perl-package was available in the debian-repo, so I
can use package{}.
On Aug 17, 5:49 am, Brian Gallew <g...@gallew.org>
wrote:> Sorry, when you use Gmail you end up top-posting whether you like it or
not.
>
> On Mon, Aug 16, 2010 at 8:45 PM, Daniel Pittman <dan...@rimspace.net>
wrote:
> > Brian Gallew <g...@gallew.org> writes:
>
> > It is always nice if y''all follow the existing quoting style
in mails; it
> > makes it much less confusing to follow later.
>
> > > I have to agree with Daniel on this one. While it''s
annoying to build
> > > Solaris (in my case) packages for every CPAN package you want to
install,
> > > then end result is that I can control the installed version
*precisely*.
> > > While it may never have been a problem for you, I''ve
been bitten more
> > than
> > > once by CPAN upgrades that break my software, so "old"
systems work while
> > > new systems don''t.
>
> > FWIW, at work we gave up on that despite using Debian and having
pretty
> > good
> > support tools to do the job. We settled on packaging all the Perl
bits we
> > use
> > as a single package and landing that everywhere.
>
> > That gives us a good balance between the two paths, and has worked out
well
> > to
> > date. Plus it keeps system Perl and company Perl separate...
>
> > Daniel
>
> > --
> > ✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401
155
> > 707
> > ♽ made with 100 percent post-consumer electrons
>
> > --
> > 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<puppet-users%2Bunsubscribe@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.