[Puppet Users] Re: hash iteration with erb templates

[denmat]

Sorted. Thanks Kevin,

https://gist.github.com/1674234

On Jan 25, 1:42 pm, denmat  wrote:
> Hi list,
>
> I'm trying to deploy a configuration file via a template (puppet 2.6.13).
>
> The problem is that I can't get my iteration right.
>
> You can check out the gist here:https://gist.github.com/1674234
>
> But the code is like the following:
>
> $drbd_resource = { data_share1 => { 'node1.local' =>
> ['192.168.222.21','/dev/drbd1'],
>                                                       'node2.local' =>
> ['192.168.222.22','/dev/drbd1'] },
>                              data_share2 => { 'node1.local' =>
> ['192.168.222.21','/dev/drbd2'],
>                                                        'node2.local'
> => ['192.168.222.22','/dev/drbd2'] }
>                             }
>   $data = inline_template("
> <% drbd_resource.each do |res,resdata| -%>
> resource <%= res -%> {
>   <% resdata.each do |nodedata| -%>
>         device          <%= nodedata[1][1] -%>;
>         disk            /dev/vg_shared/drbd_<%= res -%>;
>         meta-disk       internal;
>
>         startup { become-primary-on both; }
>
>         on <%= fqdn %> {
>                 address         <%= nodedata[1][0] %>:7789;
>         }}
>
>     <% end -%>
> <% end -%>
> ")
> notify{$data: }
>
> and the output is like the following:
>
> notice:
> resource data_share1 {
>
>         device          /dev/drbd1;
>         disk            /dev/vg_shared/drbd_data_share1;
>         meta-disk       internal;
>
>         startup { become-primary-on both; }
>
>         on test.local {
>                 address         192.168.222.22:7789;
>         }
>
> }
>
>         device          /dev/drbd1;
>         disk            /dev/vg_shared/drbd_data_share1;
>         meta-disk       internal;
>
>         startup { become-primary-on both; }
>
>         on test.local {
>                 address         192.168.222.21:7789;
>         }
>
> }
>
>     resource data_share2 {
>
>         device          /dev/drbd2;
>         disk            /dev/vg_shared/drbd_data_share2;
>         meta-disk       internal;
>
>         startup { become-primary-on both; }
>
>         on test.local {
>                 address         192.168.222.22:7789;
>         }
>
> }
>
>         device          /dev/drbd2;
>         disk            /dev/vg_shared/drbd_data_share2;
>         meta-disk       internal;
>
>         startup { become-primary-on both; }
>
>         on test.local {
>                 address         192.168.222.21:7789;
>         }
>
> }
>
> What I want to see is that a file is created containing the following
> (drbd.d/data_share2.res):
>     resource data_share2 {
>
>         device          /dev/drbd1;
>         disk            /dev/vg_shared/drbd_data_share2;
>         meta-disk       internal;
>
>         startup { become-primary-on both; }
>
>         on test.local {
>                 address         192.168.222.22:7789;
>                 address         192.168.222.21:7789;
>         }
>
> }
>
> Any help?
>
> Den

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Cross-module (package) dependencies

[Walter Heck]

On Wed, Jan 25, 2012 at 05:51, Nigel Kersten  wrote:
> Yeah. I went for functions to try and hide the fact that this is a resource
> underneath, but perhaps modeling this more transparently makes sense.
>
>> We'd also need a way to test if a capability is being provided by the
>> system as a whole. Ie, a mysql module needs to be able to check if it
>> needs to include resources for a firewall, monitoring, etc.
> Something like defined()? ;-)

Come on, I thought we all agreed that defined is Nasty and Evil. At
least make it defined_new() or maybe even defined2() :P


-- 
Walter Heck

--
follow @walterheck on twitter to see what I'm up to!
--
Check out my new startup: Server Monitoring as a Service @ http://tribily.com
Follow @tribily on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/tribily

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Cross-module (package) dependencies

[Nigel Kersten]

On Tue, Jan 24, 2012 at 4:34 PM, Walter Heck  wrote:

> > I had this thought the other day, but more focused around the higher
> level
> > problem of dependency specification and consumption than Packages in
> > particular.
> Yeah, since that is something that is currently kind of difficult to
> implement properly. I'd welcome a proper way to do this.
>
> > What if you made two functions:
> >
> > 1. declare_capability("foo")
> >   This would essentially just create an empty resource, Capability[foo].
> If
> > multiple modules tried to declare the same capability, it would error,
> just
> > like we do today with duplicate resources.
> >
> > 2. require_capability("foo")
> >   This would just declare a requirement relationship to Capability[foo].
> If
> > it couldn't find that resource, compilation would fail.
> >
> >
> > Wouldn't something like this solve the general problem? We don't really
> want
> > to just speak about packages, you generally want to be able to express
> > requirements like:
> >
> > * This module requires a working SSH server
> > * This module requires a MySQL database
> >
> > etc etc
> >
> > I've deliberately focused this on doing this with functions as the
> extension
> > point as I think it keeps us focused, even if we decide that in the
> future
> > this should be solved in the metadata layer of a module.
> Hmm, while I can see your point of using functions, I think a more
> "puppety" way of doing this would be to have
>
> require Capability['yadda']
>
> vs
>
> capability{'yadda':
>  ensure => present
> }
>

Yeah. I went for functions to try and hide the fact that this is a resource
underneath, but perhaps modeling this more transparently makes sense.


>
> We'd also need a way to test if a capability is being provided by the
> system as a whole. Ie, a mysql module needs to be able to check if it
> needs to include resources for a firewall, monitoring, etc.
>
>
Something like defined()? ;-)

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] hash iteration with erb templates

[denmat]

Hi list,

I'm trying to deploy a configuration file via a template (puppet 2.6.13).

The problem is that I can't get my iteration right.

You can check out the gist here:
https://gist.github.com/1674234

But the code is like the following:

$drbd_resource = { data_share1 => { 'node1.local' =>
['192.168.222.21','/dev/drbd1'],
  'node2.local' =>
['192.168.222.22','/dev/drbd1'] },
 data_share2 => { 'node1.local' =>
['192.168.222.21','/dev/drbd2'],
   'node2.local'
=> ['192.168.222.22','/dev/drbd2'] }
}
  $data = inline_template("
<% drbd_resource.each do |res,resdata| -%>
resource <%= res -%> {
  <% resdata.each do |nodedata| -%>
device  <%= nodedata[1][1] -%>;
disk/dev/vg_shared/drbd_<%= res -%>;
meta-disk   internal;

startup { become-primary-on both; }

on <%= fqdn %> {
address <%= nodedata[1][0] %>:7789;
}
}
<% end -%>
<% end -%>
")
notify{$data: }

and the output is like the following:

notice:
resource data_share1 {

device  /dev/drbd1;
disk/dev/vg_shared/drbd_data_share1;
meta-disk   internal;

startup { become-primary-on both; }

on test.local {
address 192.168.222.22:7789;
}
}

device  /dev/drbd1;
disk/dev/vg_shared/drbd_data_share1;
meta-disk   internal;

startup { become-primary-on both; }

on test.local {
address 192.168.222.21:7789;
}
}

resource data_share2 {

device  /dev/drbd2;
disk/dev/vg_shared/drbd_data_share2;
meta-disk   internal;

startup { become-primary-on both; }

on test.local {
address 192.168.222.22:7789;
}
}

device  /dev/drbd2;
disk/dev/vg_shared/drbd_data_share2;
meta-disk   internal;

startup { become-primary-on both; }

on test.local {
address 192.168.222.21:7789;
}
}

What I want to see is that a file is created containing the following
(drbd.d/data_share2.res):
resource data_share2 {

device  /dev/drbd1;
disk/dev/vg_shared/drbd_data_share2;
meta-disk   internal;

startup { become-primary-on both; }

on test.local {
address 192.168.222.22:7789;
address 192.168.222.21:7789;
}
}

Any help?

Den

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] scaling projections for dashboard database?

[Daniel Pittman]

On Tue, Jan 24, 2012 at 14:55, Jo Rhett  wrote:
> Sorry for the long delay, had my head down on some other issues. Reply
> below.
>
> On Jan 10, 2012, at 10:55 AM, Daniel Pittman wrote:
>
>> Yes.  It sounds like the current storage of reports isn't going to
>> work well for you, at least if you want to retain history.  This is
>> absolutely unfortunate, and is one of the serious shortfalls we are
>> aware of around the Dashboard and StoreConfigs databases.  We are
>> working on improving these, but there isn't anything presently public
>> available.
>
> My main concern here is that we're keeping a large amount of data twice.  We
> have the report file, and then we have all of the same content in the
> database. I think that it should be documented:
>
> 1. What does keeping the reports around give you?
> 2. What does keeping the database reports around give you?
>
> If I am right, we could stop storing the reports for as long if we can
> browse them in the dashboard interface, right?  Or is there some loss of
> functionality by discarding reports after just a few days?

Yeah, you can ditch the files on disk in favour of the database with
no real loss of anything.

-- 
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ 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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] constraint checking

[Nick]

Hi,

I want to assert a file exists - but in a way that doesn't have the potential to
create conflicting resource definitions.

I know this has been asked many times before:

  "How can I check whether a file exists, like 'File.exists?(file)'
  or '-f $file'?"

My very specific use case is with a user-account define.  I want something like
this:

 define user_account($name, $shell = '/bin/bash', /* ... */) {
/* ... */

assert file_exists($shell) # make sure the shell is available

/* ... */
 }

I don't want to create the file $shell, nor do I care how it gets there, but I
want it to be there (and ideally, executable).  Declaring a resource user("foo":
shell = $shell) doesn't appear to assert this by itself (trying in 2.7.9).

Just to be clear, "require File[$shell]" and equivalents are no good, because
they force me to define a File resource which "owns" the file $shell, and since
there can only be one of those I am in trouble if something else wants to define
the same condition.  In general I cannot know if this is being asserted
elsewhere by the author of another module.

However, the question has a more general aspect. Why doesn't core Puppet make
assertions like this easy?  It seems a simple, obvious, and common thing to
want.  And not just for files - I often want to express similar assertions about
users, groups, packages, and probably other resources.

This question seems like it ought to be addressed in the puppet FAQ [1], but I
can't find any discussion of it there, nor in the puppet cookbook [2], puppet
language guide [3], nor the "Puppet types" reference page [4].

I know there are workarounds of sorts:

 - if !defined(File[$shell]) { file{ $shell: ensure => 'exists' } }

 - Exec { "check ${shell} exists for ${user}":
  command => "/usr/bin/test -f '${shell}'" }

 - if inline_template("<% File.exists?(shell)? 'true':'false' %>") == "true"
{  /* fail somehow */ }

 - define a custom function which simply does File.exists?(shell) and fails if
   false


They are all sledgehammers to crack a nut, the first is apparently dangerous and
another thread on this list is proposing to outlaw it.

To sum up, it appears that this feature is missing for a reason, but why?  And
what's the best workaround available?

Cheers,

N


1. http://docs.puppetlabs.com/guides/faq.html
2. http://www.puppetcookbook.com/
3. http://docs.puppetlabs.com/guides/language_guide.html
4. http://docs.puppetlabs.com/references/2.7.9/type.html

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Cross-module (package) dependencies

[Walter Heck]

> I had this thought the other day, but more focused around the higher level
> problem of dependency specification and consumption than Packages in
> particular.
Yeah, since that is something that is currently kind of difficult to
implement properly. I'd welcome a proper way to do this.

> What if you made two functions:
>
> 1. declare_capability("foo")
>   This would essentially just create an empty resource, Capability[foo]. If
> multiple modules tried to declare the same capability, it would error, just
> like we do today with duplicate resources.
>
> 2. require_capability("foo")
>   This would just declare a requirement relationship to Capability[foo]. If
> it couldn't find that resource, compilation would fail.
>
>
> Wouldn't something like this solve the general problem? We don't really want
> to just speak about packages, you generally want to be able to express
> requirements like:
>
> * This module requires a working SSH server
> * This module requires a MySQL database
>
> etc etc
>
> I've deliberately focused this on doing this with functions as the extension
> point as I think it keeps us focused, even if we decide that in the future
> this should be solved in the metadata layer of a module.
Hmm, while I can see your point of using functions, I think a more
"puppety" way of doing this would be to have

require Capability['yadda']

vs

capability{'yadda':
  ensure => present
}

We'd also need a way to test if a capability is being provided by the
system as a whole. Ie, a mysql module needs to be able to check if it
needs to include resources for a firewall, monitoring, etc.

cheers,
-- 
Walter Heck

--
follow @walterheck on twitter to see what I'm up to!
--
Check out my new startup: Server Monitoring as a Service @ http://tribily.com
Follow @tribily on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/tribily

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Cross-module (package) dependencies

[Nan Liu]

On Tue, Jan 24, 2012 at 2:53 PM, Nigel Kersten  wrote:
>
>
> On Tue, Jan 24, 2012 at 4:42 AM, Walter Heck  wrote:
>>
>> What if there was some standardised way modules expose a sort of list
>> of requirements or an API of some sort?
>
>
> I had this thought the other day, but more focused around the higher level
> problem of dependency specification and consumption than Packages in
> particular.
>
> What if you made two functions:
>
> 1. declare_capability("foo")
>   This would essentially just create an empty resource, Capability[foo]. If
> multiple modules tried to declare the same capability, it would error, just
> like we do today with duplicate resources.
>
> 2. require_capability("foo")
>   This would just declare a requirement relationship to Capability[foo]. If
> it couldn't find that resource, compilation would fail.

I'm actually also interested in detect capability too. For example if
class firewall is included, add the following iptable rules, otherwise
don't include firewall rules in the catalog. It can be implemented as
parameter in the application class, but feels much nicer if I can
simply include firewall, and all the app added firewall rules, vs.
class { 'app1': firewall => true }... I'm aware this might be order
dependent and  tricky to implement.

Thanks,

Nan

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Error at the end of a puppet agent run...

[Stefan Schulte]

On Tue, Jan 24, 2012 at 11:24:58AM -0500, Peter Berghold wrote:
> On Sun, Jan 22, 2012 at 7:54 PM, Stefan Schulte <
> stefan.schu...@taunusstein.net> wrote:
> 
> >
> > What version of puppet are you using on the agent side and for your
> > puppet master? Do you use mongrel or passenger or how do you run your
> > puppet master?
> >
> >
> puppetmasterd2.7.9
> puppet agent   2.7.9
> 
> As of right now I am using neither passenger or mongrel.  Considering doing
> so in the future.
> 
> The puppet master and the puppet agents run as daemons both on the client
> side and the master side.
> 

You can run your agent with the command line option --trace. This way
you should see a backtrace when the exception happens so we hopefully
know exactly where the error is happening.

But I'm not sure if the output will go to the logfiles so you might have
to run your agent in foreground mode

puppet agent --verbose --trace --no-daemonize

As far as I know Puppet itself (when not run behind passenger or similar)
is not really capable of handling concurrent request. If multiple agents
query your master at the same they might run into timeouts.

-Stefan


pgpIL1QSIpOCV.pgp
Description: PGP signature

Re: [Puppet Users] scaling projections for dashboard database?

[Jo Rhett]

Sorry for the long delay, had my head down on some other issues. Reply below.

On Jan 10, 2012, at 10:55 AM, Daniel Pittman wrote:
> Yes.  It sounds like the current storage of reports isn't going to
> work well for you, at least if you want to retain history.  This is
> absolutely unfortunate, and is one of the serious shortfalls we are
> aware of around the Dashboard and StoreConfigs databases.  We are
> working on improving these, but there isn't anything presently public
> available.


My main concern here is that we're keeping a large amount of data twice.  We 
have the report file, and then we have all of the same content in the database. 
I think that it should be documented:

1. What does keeping the reports around give you?

2. What does keeping the database reports around give you?

If I am right, we could stop storing the reports for as long if we can browse 
them in the dashboard interface, right?  Or is there some loss of functionality 
by discarding reports after just a few days?

-- 
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source and other 
randomness

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Error at the end of a puppet agent run...

[Aaron Grewell]

Depending on your hardware and ruleset a dozen might be more than
Mongrel will handle.

On Tue, Jan 24, 2012 at 11:32 AM, Peter Berghold
 wrote:
> Aaron,
>
> What does scalability have to do with this case?  There are maybe a dozen
> systems being managed in this case (soon will be more, so then scalability
> may play into this) and the configs aren't that complicated.
>
>
>
> On Tue, Jan 24, 2012 at 2:21 PM, Aaron Grewell 
> wrote:
>>
>> If you didn't specifically configure Puppet to use Passenger then
>> you're using Mongrel by default.  Scalability => false.
>>
>> On Tue, Jan 24, 2012 at 8:24 AM, Peter Berghold 
>> wrote:
>> >
>> >
>> > On Sun, Jan 22, 2012 at 7:54 PM, Stefan Schulte
>> >  wrote:
>> >>
>> >>
>> >> What version of puppet are you using on the agent side and for your
>> >> puppet master? Do you use mongrel or passenger or how do you run your
>> >> puppet master?
>> >>
>> >
>> > puppetmasterd    2.7.9
>> > puppet agent   2.7.9
>> >
>> > As of right now I am using neither passenger or mongrel.  Considering
>> > doing
>> > so in the future.
>> >
>> > The puppet master and the puppet agents run as daemons both on the
>> > client
>> > side and the master side.
>> >
>> >
>> > --
>> > Peter L. Berghold
>> > Owner, Shark River Technical Solutions LLC
>> >
>> > --
>> > 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+unsubscr...@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+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
>
>
> --
> Peter L. Berghold
> Owner, Shark River Technical Solutions LLC
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] difficulty installing dashboard.

[Jo Rhett]

Install the rdoc gem.  You'll always get the deprecation warnings, those are 
reported in bug 
https://projects.puppetlabs.com/issues/11669

Michael agreed its a bug, but there's no evidence it's fixed in dashboard 1.2.5 
afaict.

On Jan 24, 2012, at 10:56 AM, Peter Berghold wrote:
> I think I'm gonna give up on dashboard.  Now that I have ruby 1.8.7 
> (2011-12-28 patchlevel 357) [x86_64-linux]
> installed there are new messages being spewed:
> 
>  rake --trace RAILS_ENV=production reports:migrate
> NOTE: Gem.source_index is deprecated, use Specification. It will be removed 
> on or after 2011-11-01.
> Gem.source_index called from 
> /root/puppet-dashboard/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:21.
> NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It will 
> be removed on or after 2011-11-01.
> Gem::SourceIndex#initialize called from 
> /root/puppet-dashboard/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It 
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from 
> /usr/lib/ruby/site_ruby/1.8/rubygems/source_index

Re: [Puppet Users] difficulty installing dashboard.

[Jo Rhett]

Just FYI I went through the struggle of getting 1.8.7 on a CentOS 5.7 system 
and documented it here:

http://groups.google.com/group/puppet-users/browse_thread/thread/0904c78fd9c8602c/090371e0efab606f?show_docid=090371e0efab606f&pli=1

Puppet dashboard is up and running fine on CentOS 5.7 using the steps 
documented here.  And I know these steps work because I have multiple 
environments to deploy so I used this document to build out in the new 
environments ;-)

On Jan 24, 2012, at 8:42 AM, Peter Berghold wrote:
> On Tue, Jan 24, 2012 at 11:34 AM, Michael Stahnke  
> wrote:
> 
> 
> Dashboard isn't supported (and doesn't really work) on Ruby 1.8.5.
> 1.8.7 is the minimum requirement.  Can you try EL6?
> 
> 
> Oh man...
> 
> Here is what the installation docs say:
> Ruby or Ruby Enterprise Edition programming language interpreter, version 
> 1.8.4 to 1.8.7, but not 1.9.x
> 
> so... I gotta get 1.8.7 on the box?   EL6 is not an option at this point as 
> this is not a new box and does more than just puppet...
> 
> 
> -- 
> Peter L. Berghold 
> Owner, Shark River Technical Solutions LLC 
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.

-- 
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source and other 
randomness

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] async_storeconfigs updating agent hosts.ip to puppetmaster IP

[Jake - USPS]

So we are trying to use async_storeconfigs.  It seems when I get it
all up and running the hosts.ip for an agent gets its hosts.ip entry
in the DB set to the puppetmaster that it got its catalog from instead
of its own IP.

If I turn async_storeconfigs off and re-run puppet agent on the node
that had its IP updated incorrectly it then updates back to the
correct IP.

I am using puppet 2.7.5 on SLES10 and SLES11.

Would this be a configuration issue or a bug with puppet?

If you want more information let me know.

Thanks!
Jake

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Cross-module (package) dependencies

[Nigel Kersten]

On Tue, Jan 24, 2012 at 4:42 AM, Walter Heck  wrote:

> What if there was some standardised way modules expose a sort of list
> of requirements or an API of some sort?


I had this thought the other day, but more focused around the higher level
problem of dependency specification and consumption than Packages in
particular.

What if you made two functions:

1. declare_capability("foo")
  This would essentially just create an empty resource, Capability[foo]. If
multiple modules tried to declare the same capability, it would error, just
like we do today with duplicate resources.

2. require_capability("foo")
  This would just declare a requirement relationship to Capability[foo]. If
it couldn't find that resource, compilation would fail.


Wouldn't something like this solve the general problem? We don't really
want to just speak about packages, you generally want to be able to express
requirements like:

* This module requires a working SSH server
* This module requires a MySQL database

etc etc

I've deliberately focused this on doing this with functions as the
extension point as I think it keeps us focused, even if we decide that in
the future this should be solved in the metadata layer of a module.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Error at the end of a puppet agent run...

[Peter Berghold]

Aaron,

What does scalability have to do with this case?  There are maybe a dozen
systems being managed in this case (soon will be more, so then scalability
may play into this) and the configs aren't that complicated.


On Tue, Jan 24, 2012 at 2:21 PM, Aaron Grewell wrote:

> If you didn't specifically configure Puppet to use Passenger then
> you're using Mongrel by default.  Scalability => false.
>
> On Tue, Jan 24, 2012 at 8:24 AM, Peter Berghold 
> wrote:
> >
> >
> > On Sun, Jan 22, 2012 at 7:54 PM, Stefan Schulte
> >  wrote:
> >>
> >>
> >> What version of puppet are you using on the agent side and for your
> >> puppet master? Do you use mongrel or passenger or how do you run your
> >> puppet master?
> >>
> >
> > puppetmasterd2.7.9
> > puppet agent   2.7.9
> >
> > As of right now I am using neither passenger or mongrel.  Considering
> doing
> > so in the future.
> >
> > The puppet master and the puppet agents run as daemons both on the client
> > side and the master side.
> >
> >
> > --
> > Peter L. Berghold
> > Owner, Shark River Technical Solutions LLC
> >
> > --
> > 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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
Peter L. Berghold
Owner, Shark River Technical Solutions LLC

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Error at the end of a puppet agent run...

[Aaron Grewell]

If you didn't specifically configure Puppet to use Passenger then
you're using Mongrel by default.  Scalability => false.

On Tue, Jan 24, 2012 at 8:24 AM, Peter Berghold  wrote:
>
>
> On Sun, Jan 22, 2012 at 7:54 PM, Stefan Schulte
>  wrote:
>>
>>
>> What version of puppet are you using on the agent side and for your
>> puppet master? Do you use mongrel or passenger or how do you run your
>> puppet master?
>>
>
> puppetmasterd    2.7.9
> puppet agent   2.7.9
>
> As of right now I am using neither passenger or mongrel.  Considering doing
> so in the future.
>
> The puppet master and the puppet agents run as daemons both on the client
> side and the master side.
>
>
> --
> Peter L. Berghold
> Owner, Shark River Technical Solutions LLC
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Cross-module (package) dependencies

[Aaron Grewell]

I was thinking more in terms of an exception handler:

package { "foo": ensure => installed, exceptDefined => skip}

Or something of that nature.  This could also be used in other
situations where you want to bypass default behaviors.  We've seen
situations where users want to apply a file if it exists in the module
but otherwise proceed without errors.  This could be done like so:

file {"$foo": ensure => present, source => "${foo}.txt", exceptAbsent => skip}


On Tue, Jan 24, 2012 at 1:28 AM, Felix Frank
 wrote:
> Hi,
>
> there was a discussion in the "can we deprecate defined() in Telly"
> thread about how we can even begin to design Forge modules without it.
>
> A recurring problem is that multiple modules rely on certain packages,
> and there is no good model (yet) to unite their resource declarations.
> Therefore it's a common (although imho disgusting) workaround to do
> things like
> if !defined(Package[foo]) { package { "foo": ensure => installed } }
>
> On 01/20/2012 11:34 PM, Cody wrote:
>> Defining all somewhat common packages in a central location becomes
>> unrealistic when you no longer "control" the code that is in every
>> module you use.  If you obtain five modules from the forge and they
>> all require a specific package and so all define that package your not
>> going to convince, nor is it a good design to require everyone to move
>> the package definitions from that collection of modules.  They need to
>> function as a collection out of the box.
>
> Agreed. How can this be accomplished?
>
> Perhaps there needs to be some kind of "Forge common" module that by
> policy can only ever declare virtual resources (packages are a prominent
> example).
> A user who wishes to retain the capability of using modules from the
> Forge would be required to install this common module, and replace their
> own resource declarations with realizations of the common resources.
> For this to work, it's definitely a plus that you can override
> attributes in collections:
> Package<| title == "apache2": |> { ensure => "2.2.12" }
> ...although that does bear some caveats. Does this still work in recent
> versions?
>
> If we can take this for granted, all Forge modules can adhere to that
> same standard.
>
> This is a rough sketch of how things might possibly work, and surely has
> lots of wrinkles of its own. Still, I'm quite sure we need a proper way
> to rid ourselves of the horror that is the parse order dependent check
> for defined resources ;-)
>
> Cheers,
> Felix
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] difficulty installing dashboard.

[Peter Berghold]

On Tue, Jan 24, 2012 at 1:59 PM, Randall Hansen wrote:

>
> You may have other issues (aside from the mass of deprecation warnings
> ... ew), but this makes it look like you're missing the rdoc gem.
>
>
 puppet-dashboard]# gem list

*** LOCAL GEMS ***

actionmailer (2.1.1)
actionpack (2.1.1)
activerecord (2.1.1)
activeresource (2.1.1)
activesupport (2.1.1)
dashboard (0.0.0)
facter (1.6.3, 1.6.2, 1.6.1)
json (1.6.5)
libdir (1.3.1)
puppet (2.7.9, 2.7.6, 2.7.4)
rails (2.1.1)
rake (0.9.2.2, 0.8.7)
rdoc (3.12)

It's there.  Now it complains it doesn't know how to build task
'reports:migrate'

-- 
Peter L. Berghold
Owner, Shark River Technical Solutions LLC

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] difficulty installing dashboard.

[Randall Hansen]

On Tue, Jan 24, 2012 at 10:56 AM, Peter Berghold
 wrote:

> rake aborted!
> no such file to load -- rdoc/task

You may have other issues (aside from the mass of deprecation warnings
... ew), but this makes it look like you're missing the rdoc gem.

r

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] difficulty installing dashboard.

[Peter Berghold]

I think I'm gonna give up on dashboard.  Now that I have ruby 1.8.7
(2011-12-28 patchlevel 357) [x86_64-linux]
installed there are new messages being spewed:

 rake --trace RAILS_ENV=production reports:migrate
NOTE: Gem.source_index is deprecated, use Specification. It will be removed
on or after 2011-11-01.
Gem.source_index called from
/root/puppet-dashboard/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:21.
NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It
will be removed on or after 2011-11-01.
Gem::SourceIndex#initialize called from
/root/puppet-dashboard/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
rake aborted!
no such file to load -- rdoc/task
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in
`gem_original_require'
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
/root/puppet-dashboard/Rakefile:9
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/rake_module.rb:25:in
`load'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/rake_module.rb:25:in
`load_rakefile'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:501:in
`raw_load_rakefi

Re: [Puppet Users] difficulty installing dashboard.

[Stefan Heijmans]

Op dinsdag 24 januari 2012 17:42:08 UTC+1 schreef Salty Old Cowdawg het 
volgende: 
>
> so... I gotta get 1.8.7 on the box?   EL6 is not an option at this point 
> as this is not a new box and does more than just puppet...
>
>  
There is a topic about this from Jo Rhett; 
https://groups.google.com/d/msg/puppet-users/CQTHj9nIYCw/b2Cr7-BxAwkJ
Or you can compile Ruby Enterprise Edition 1.8.7 yourself on that host.
 
So there are some options you could go for.
 
Stefan
 
 

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

Re: [Puppet Users] difficulty installing dashboard.

[Randall Hansen]

On Tue, Jan 24, 2012 at 8:46 AM, Michael Stahnke  wrote:

> Which docs?  I swear we've had this updated.

These, Mike:   http://docs.puppetlabs.com/guides/installing_dashboard.html.
 I've pinged Nick Fagerlund about a fix.

Apologies for the bother, Peter.  We have this documented in too many places.

r

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] difficulty installing dashboard.

[Michael Stahnke]

On Tue, Jan 24, 2012 at 8:42 AM, Peter Berghold  wrote:
>
>
> On Tue, Jan 24, 2012 at 11:34 AM, Michael Stahnke 
> wrote:
>>
>>
>>
>> Dashboard isn't supported (and doesn't really work) on Ruby 1.8.5.
>> 1.8.7 is the minimum requirement.  Can you try EL6?
>>
>
> Oh man...
>
> Here is what the installation docs say:
> Ruby or Ruby Enterprise Edition programming language interpreter, version
> 1.8.4 to 1.8.7, but not 1.9.x

Which docs?  I swear we've had this updated.  1.8.7 will work.  You
can use REE or something from http://centos.karan.org/el5/ruby187/.

http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html#installing-puppet-dashboard
that says 1.8.7.


>
> so... I gotta get 1.8.7 on the box?   EL6 is not an option at this point as
> this is not a new box and does more than just puppet...
>
>
>
> --
> Peter L. Berghold
> Owner, Shark River Technical Solutions LLC
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] best practices for caching packages on EC2

[Michael Stahnke]

On Mon, Jan 23, 2012 at 4:06 PM, Rayson Ho  wrote:
> On Mon, Jan 23, 2012 at 5:14 PM, Michael Stahnke  
> wrote:
>> How would Puppet handle it?  It would still have to either cache the
>> package locally (eating lots of disk space) or point to a proxy, which
>> you can do with Puppet already.  Your simplest solution might be to
>> look for a mirror hosted in EC2, which I assume there are some.
>
> Hi Michael,
>
> I knew that I could point to a proxy - but I am looking for ways to
> automate the setup. Hardcoding yum or apt proxies is not a very
> "Puppet" way of setting things up. If someone has 100 machines on EC2,
> then I am sure it would be way more efficient to pull the package once
> into EC2, cache it on the puppet master, and then redistribute it to
> all of the 100 machines. And when the master finds that every machine
> has the package installed, it can retire the package and free up space
> (with an ordinary proxy it is harder to do the retirement part) - of
> course if it is needed again it needs to be pulled in again.

I assure you, it is not more efficient to serve it through it puppet
(at least in its file serving capacity). Coding a proxy in a
configuration file is common pattern in puppet.  It can be a variable
set at top scope, via ENC, fact, or other methods.  It's also
available as an option in the yumrepo type, if I am remembering
correctly.

>
> If the package provider layer can handle all the work of caching, then
> that would save lots of time - not every site wants to reinvent the
> wheel of package caching.

I would think it would be better to have a puppet module that sets up
package repository mirroring and caching rather than modify each
provider.  Packages are managed differently across different types of
systems.  (quite differently in some cases).  However a good squid
module for setting up a cache would reduce reinvention.  Additionally
in many setups the puppet client talks to the master over a different
set of TCP ports than the package management clients do.

Here are some decent looking modules.  I think we internally use a
variation of the first one.

https://github.com/xaque208/puppet-squid

https://github.com/duritong/puppet-squid

https://github.com/example42/puppet-modules/tree/81489cbf7fc79fb0c0e05fde65233d6132b7b5b4/squid

Of course another option is to use a close proximity mirror.






>
> Rayson
>
> =
> Open Grid Scheduler / Grid Engine
> http://gridscheduler.sourceforge.net/
>
> Scalable Grid Engine Support Program
> http://www.scalablelogic.com/
>
>
>>
>> Another option would be to build up a squid proxy via puppet and then
>> configure a client-side usage of that cache, but that's no different
>> in EC2 vs any other setup.
>>
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] difficulty installing dashboard.

[Peter Berghold]

On Tue, Jan 24, 2012 at 11:34 AM, Michael Stahnke wrote:

>
>
> Dashboard isn't supported (and doesn't really work) on Ruby 1.8.5.
> 1.8.7 is the minimum requirement.  Can you try EL6?
>
>
Oh man...

Here is what the installation docs say:
Ruby  or Ruby Enterprise
Editionprogramming
language interpreter, version 1.8.4 to 1.8.7, but not 1.9.x

so... I gotta get 1.8.7 on the box?   EL6 is not an option at this point as
this is not a new box and does more than just puppet...


-- 
Peter L. Berghold
Owner, Shark River Technical Solutions LLC

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] difficulty installing dashboard.

[Michael Stahnke]

On Tue, Jan 24, 2012 at 6:32 AM, Peter Berghold  wrote:
>
>
> On Mon, Jan 23, 2012 at 5:10 PM, Michael Stahnke 
> wrote:
>>
>>
>> OS
>
>
> CentOS release 5.7 (Final)
>
>
>>
>> ruby version
>
> ruby 1.8.5 (2006-08-25) [x86_64-linux]

Dashboard isn't supported (and doesn't really work) on Ruby 1.8.5.
1.8.7 is the minimum requirement.  Can you try EL6?
>
>>
>> rubygems version
>
> 1.3.1
>
>>
>> gem list
>>
>>
> *** LOCAL GEMS ***
>
> actionmailer (2.1.1)
> actionpack (2.1.1)
> activerecord (2.1.1)
> activeresource (2.1.1)
> activesupport (2.1.1)
> dashboard (0.0.0)
> facter (1.6.3, 1.6.2, 1.6.1)
> libdir (1.3.1)
> puppet (2.7.9, 2.7.6, 2.7.4)
> rails (2.1.1)
> rake (0.8.7)
>
>
>
> --
> Peter L. Berghold
> Owner, Shark River Technical Solutions LLC
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Error at the end of a puppet agent run...

[Peter Berghold]

On Sun, Jan 22, 2012 at 7:54 PM, Stefan Schulte <
stefan.schu...@taunusstein.net> wrote:

>
> What version of puppet are you using on the agent side and for your
> puppet master? Do you use mongrel or passenger or how do you run your
> puppet master?
>
>
puppetmasterd2.7.9
puppet agent   2.7.9

As of right now I am using neither passenger or mongrel.  Considering doing
so in the future.

The puppet master and the puppet agents run as daemons both on the client
side and the master side.


-- 
Peter L. Berghold
Owner, Shark River Technical Solutions LLC

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] difficulty installing dashboard.

[Peter Berghold]

On Mon, Jan 23, 2012 at 5:10 PM, Michael Stahnke wrote:

>
> OS
>

CentOS release 5.7 (Final)



> ruby version
>
ruby 1.8.5 (2006-08-25) [x86_64-linux]


> rubygems version
>
1.3.1


> gem list
>
>
> *** LOCAL GEMS ***

actionmailer (2.1.1)
actionpack (2.1.1)
activerecord (2.1.1)
activeresource (2.1.1)
activesupport (2.1.1)
dashboard (0.0.0)
facter (1.6.3, 1.6.2, 1.6.1)
libdir (1.3.1)
puppet (2.7.9, 2.7.6, 2.7.4)
rails (2.1.1)
rake (0.8.7)



-- 
Peter L. Berghold
Owner, Shark River Technical Solutions LLC

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] A Related Question - (Was: Template Help Please)

[Dan White]

What is the minimum version of puppet (and other bits) that this technique will 
work on ?

I am still on 2.6 (latest in EPEL) and I have the impression that this is 2.7+ 
stuff.

“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

- ollies...@googlemail.com  wrote:
> 
> 
> On Jan 24, 7:14 am, "ollies...@googlemail.com"
>  wrote:
> > On Jan 23, 9:07 pm, Guy Matz  wrote:
> >
> > > Is your issue resolved?  It looks like you don't have the correct erb
> > > syntax in your loop
> >
> > > *<%=* scope.lookupvar('resolver::params::resolvers').split(/\s+/).each
> >
> > > I think should be
> >
> > > *<%* scope.lookupvar('resolver::params::resolvers').split(/\s+/).each
> >
> > Thanks Gary, the split now works. Although I get an line break.
> >
> >  # more /etc/resolv.conf
> > # File managed by puppet
> > domain example.com
> > searchpath example.com example2.com
> >
> > nameserver 10.10.10.10
> >
> > nameserver 11.11.11.11
> 
> No worries sorted that with:-
> <% scope.lookupvar('resolver::params::resolvers').split(/\s+/).each do
> | ns | -%>
> nameserver <%= ns %>
> <% end -%>
> 
> Thanks to all for the help.
> 
> -- 
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] I just discovered I cannot resource-purge yumrepos -- Is there another way ?

[Dan White]

Thank you.
Simple enough to ignore the hack-ish nature :)

Looks like it will do the job

All it needs are a few yum commands to run whenever the file changes to refresh 
the local databse.

I will tinker with that and report back to the list.

Pay It Forward !
Share & Enjoy !

“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

- Eric Sorenson  wrote:
> This is sort of hackish but not too bad... set a list of file resources 
> that are the resultant names of the /etc/yum.repos.d/.repo files, and 
> purge everything else in that directory.
> 
> class yum::cleanup {
> # shorthand for the repo directory
> $rd = "/etc/yum.repos.d"
> 
> # clean the yum.repos.d directory of any non-managed files
> file { "$rd": ensure => directory, purge => true, recurse => true }
> 
> # NOTE: If you add a new yumrepo, make a matching file resource here!
> file { [ "$rd/local.repo",
>  "$rd/os.repo",
>  "$rd/base.repo", ] : 
> ensure => present, 
>  }
> 
> }
> 
> class yum::repositories {
> require yum::cleanup
> 
> yumrepo { "os"
> 
> etc ...
> 
> }
> 
> }
> 
> -- 
> 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/-/62XjufqJOh8J.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: client not getting updates no error message

[bhagyesh]

finally was able to solve by reinstalling puppet server.

On Jan 23, 6:39 pm, bhagyesh  wrote:
> guys any other suggestions ?still i am not able to find the error.
>
> On Jan 22, 12:02 am, bhagyesh  wrote:
>
>
>
> > [root@PROXY-03 puppet]# puppet apply networking/manifests/init.pp -d -
> > e 'include networking::resolver'
> > debug: importing '/etc/puppet/modules/networking/manifests/init.pp' in
> > environment production
> > debug: Automatically imported networking::resolver from networking
> > into production
> > debug: Failed to load library 'rubygems' for feature 'rubygems'
> > debug: Puppet::Type::File::ProviderMicrosoft_windows: feature
> > microsoft_windows is missing
> > debug: Creating default schedules
> > debug: Failed to load library 'ldap' for feature 'ldap'
> > debug: Puppet::Type::User::ProviderLdap: feature ldap is missing
> > debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/
> > dscl does not exist
> > debug: Puppet::Type::User::ProviderUser_role_add: file roledel does
> > not exist
> > debug: Puppet::Type::User::ProviderPw: file pw does not exist
> > debug: /File[/var/lib/puppet/ssl/private_keys]: Autorequiring File[/
> > var/lib/puppet/ssl]
> > debug: /File[/var/lib/puppet/ssl/private_keys/
> > proxy-03.carnation.in.pem]: Autorequiring File[/var/lib/puppet/ssl/
> > private_keys]
> > debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/
> > puppet]
> > debug: /File[/var/lib/puppet/ssl/public_keys]: Autorequiring File[/var/
> > lib/puppet/ssl]
> > debug: /File[/var/lib/puppet/state/state.yaml]: Autorequiring File[/
> > var/lib/puppet/state]
> > debug: /File[/var/lib/puppet/state/last_run_summary.yaml]:
> > Autorequiring File[/var/lib/puppet/state]
> > debug: /File[/var/lib/puppet/ssl/public_keys/
> > proxy-03.carnation.in.pem]: Autorequiring File[/var/lib/puppet/ssl/
> > public_keys]
> > debug: /File[/var/lib/puppet/client_data]: Autorequiring File[/var/lib/
> > puppet]
> > debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/
> > puppet]
> > debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring
> > File[/var/lib/puppet/ssl]
> > debug: /File[/var/lib/puppet/state/graphs]: Autorequiring File[/var/
> > lib/puppet/state]
> > debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/
> > puppet]
> > debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/
> > lib/puppet]
> > debug: /File[/var/lib/puppet/state/last_run_report.yaml]:
> > Autorequiring File[/var/lib/puppet/state]
> > debug: /File[/var/lib/puppet/ssl/certs/proxy-03.carnation.in.pem]:
> > Autorequiring File[/var/lib/puppet/ssl/certs]
> > debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring File[/var/lib/
> > puppet/ssl]
> > debug: /File[/var/lib/puppet/ssl/private]: Autorequiring File[/var/lib/
> > puppet/ssl]
> > debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring File[/
> > var/lib/puppet/ssl/certs]
> > debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
> > debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring File[/var/lib/
> > puppet/ssl]
> > debug: /File[/var/log/puppet/http.log]: Autorequiring File[/var/log/
> > puppet]
> > debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet]
> > debug: Finishing transaction 23673548974640
> > debug: Loaded state in 0.00 seconds
> > debug: Loaded state in 0.00 seconds
> > info: Applying configuration version '1327172288'
> > notice: /Stage[main]/Networking::Resolver/File[/tmp/resolv.conf]/
> > ensure: created
> > debug: Finishing transaction 23673547908420
> > debug: Storing state
> > debug: Stored state in 0.01 seconds
> > notice: Finished catalog run in 0.03 seconds
> > [root@PROXY-03 puppet]#
>
> > On Jan 21, 7:14 am, Christopher McCoy  wrote:
>
> > > What happens when you run this:
> > > puppet apply networking/manifests/init.pp -d -e 'include
> > > networking::resolver'
>
> > > On Fri, Jan 20, 2012 at 8:41 PM, bhagyesh  wrote:
> > > > file/manifest/init.pp is a class but its not yet included in the
> > > > templete so can be left alone as of now
>
> > > > and the file /tmp/resolve.conf dosent exist but still I am not getting
> > > > any output
>
> > > > On Jan 21, 3:46 am, Christopher McCoy  wrote:
> > > > > Ok, so I'm looking at this again.
>
> > > > > what is in file/manifests/init.pp?
> > > > > you ran a puppet apply on it, but never showed us what is in it, so it
> > > > > could just be class file { }
>
> > > > > And lastly, does the file /tmp/resolv.conf already exist? If so you 
> > > > > won't
> > > > > see anything output.
>
> > > > > On Fri, Jan 20, 2012 at 3:50 PM, bhagyesh  
> > > > > wrote:
> > > > > > whenever i run a test from client it finishes sucessfully but client
> > > > > > is not getting any configuration changes from server
>
> > > > > > [root@PROXY-02 tmp]# puppetd --noop --test
> > > > > > notice: Ignoring --listen on onetime run
> > > > > > info: Caching catalog for proxy-02.carnation.in
> > > > > > info: Applying configuration v

Re: [Puppet Users] Cross-module (package) dependencies

[Walter Heck]

What if there was some standardised way modules expose a sort of list
of requirements or an API of some sort? I don't know how this would
work in practice since it just popped in my mind, but I imagine for
instance a monitoring module would expose some kind of hook that other
modules can check for, and if it is found then execute the code
pertaining to monitoring. It would mean a certain abstraction, so
instead of saying an external module needs to implement nagios-perl,
it would just ask for an external module to implement monitoring, and
pass certain parameters to it in order to get that monitoring
implemented. The nagios module would then be responsible for the
actual monitoring stuff.

Come to think of it, this wouldn't take care of the duplicate resource
stuff discussed here. Nevertheless I wanted to put out this thought
anyway as it seems to be a larger issue related to this.

As for the duplicate resource issue, what about a diff/merge strategy:
If duplicate resources are found, tehre are three options:
1. if the two resource were compared and found the same it would just
be allowed and logged to the user
2. if not found the same, merged and logged:

file{x: ensure => present} and
file {x: owner => root}
becomes
file {x: ensure => present, owner => root},

3. if merge conflicts are found (ensure => present and ensure =>
absent in the two definitions) we get an error.

Could that work?

Walter

On Tue, Jan 24, 2012 at 13:38, Tim Sharpe  wrote:
> The only "clean" way to handle this that I can think of off the top of my
> head
> is for Puppet to start silently discarding duplicate definitions and just
> using
> the first one it comes across (with perhaps a message being logged at info
> level so that it's not completely invisible).
>
> This is far from ideal but so are the other proposed solutions so far :)
>
> On Tuesday, 24 January 2012 at 10:20 PM, Matthias Saou wrote:
>
> On Tue, 24 Jan 2012 10:32:31 +0100
> Felix Frank  wrote:
>
> Perhaps there needs to be some kind of "Forge common" module that by
> policy can only ever declare virtual resources (packages are a
> prominent example).
>
>
> This only takes care of the Forge case. The problem of having the same
> package being required in multiple places isn't limited to Forge, it's
> one I run into locally all the time (and I'm sure I'm not the only one).
>
> On top of that, once you try to cover multiple distributions where
> package names diverge, it starts getting hard. And once the packaging
> itself is different, as in (non-existing) sub-packages... there is no
> end (1).
>
> I don't have the slightest idea as to how all this could be solved in
> a clean way, but "requiring a common bit of high level code" isn't the
> global solution I'm myself hoping for.
>
> Matthias
>
> (1) Example where a nagios plugin requires the package for the nagios
> perl bindings. It's "nagios-perl" for most RPMs, but not split out and
> in the main "nagios-plugins" on Gentoo... then for any other plugin
> from nagios-plugins RPMs, such as "nagios-plugins-file_age", same
> thing. So you get a big mess with duplicate definitions for the main
> Gentoo "nagios-plugins" package, or you need yet another layer of high
> level code hack :-/
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.



-- 
Walter Heck

--
follow @walterheck on twitter to see what I'm up to!
--
Check out my new startup: Server Monitoring as a Service @ http://tribily.com
Follow @tribily on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/tribily

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Cross-module (package) dependencies

[Felix Frank]

On 01/24/2012 12:38 PM, Tim Sharpe wrote:
> The only "clean" way to handle this that I can think of off the top of
> my head
> is for Puppet to start silently discarding duplicate definitions and
> just using
> the first one it comes across (with perhaps a message being logged at info
> level so that it's not completely invisible).
> 
> This is far from ideal but so are the other proposed solutions so far :)

No, it really adheres to KISS very nicely.

This reminds me of the discussion of how resource defaults should stack
when they combine from different scopes. (How did that turn out, anyway?)

The vision here would probably be that the compiler collects all
definitions or the same resource, and only dies if any attributes differ.
Sadly, *due* to resource defaults, this could be more likely than one
would think.

Also, depending on how the compiler is implemented, it may be Very Hard
to do.

Cheers,
Felix

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Cross-module (package) dependencies

[Tim Sharpe]

The only "clean" way to handle this that I can think of off the top of my head
is for Puppet to start silently discarding duplicate definitions and just using
the first one it comes across (with perhaps a message being logged at info
level so that it's not completely invisible).

This is far from ideal but so are the other proposed solutions so far :)

On Tuesday, 24 January 2012 at 10:20 PM, Matthias Saou wrote: 
> On Tue, 24 Jan 2012 10:32:31 +0100
> Felix Frank  (mailto:felix.fr...@alumni.tu-berlin.de)> wrote:
> 
> > Perhaps there needs to be some kind of "Forge common" module that by
> > policy can only ever declare virtual resources (packages are a
> > prominent example).
> > 
> 
> 
> This only takes care of the Forge case. The problem of having the same
> package being required in multiple places isn't limited to Forge, it's
> one I run into locally all the time (and I'm sure I'm not the only one).
> 
> On top of that, once you try to cover multiple distributions where
> package names diverge, it starts getting hard. And once the packaging
> itself is different, as in (non-existing) sub-packages... there is no
> end (1).
> 
> I don't have the slightest idea as to how all this could be solved in
> a clean way, but "requiring a common bit of high level code" isn't the
> global solution I'm myself hoping for.
> 
> Matthias
> 
> (1) Example where a nagios plugin requires the package for the nagios
> perl bindings. It's "nagios-perl" for most RPMs, but not split out and
> in the main "nagios-plugins" on Gentoo... then for any other plugin
> from nagios-plugins RPMs, such as "nagios-plugins-file_age", same
> thing. So you get a big mess with duplicate definitions for the main
> Gentoo "nagios-plugins" package, or you need yet another layer of high
> level code hack :-/
> 
> -- 
> 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 
> (mailto:puppet-users@googlegroups.com).
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com 
> (mailto:puppet-users+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Cross-module (package) dependencies

[Matthias Saou]

On Tue, 24 Jan 2012 10:32:31 +0100
Felix Frank  wrote:

> Perhaps there needs to be some kind of "Forge common" module that by
> policy can only ever declare virtual resources (packages are a
> prominent example).

This only takes care of the Forge case. The problem of having the same
package being required in multiple places isn't limited to Forge, it's
one I run into locally all the time (and I'm sure I'm not the only one).

On top of that, once you try to cover multiple distributions where
package names diverge, it starts getting hard. And once the packaging
itself is different, as in (non-existing) sub-packages... there is no
end (1).

I don't have the slightest idea as to how all this could be solved in
a clean way, but "requiring a common bit of high level code" isn't the
global solution I'm myself hoping for.

Matthias

(1) Example where a nagios plugin requires the package for the nagios
perl bindings. It's "nagios-perl" for most RPMs, but not split out and
in the main "nagios-plugins" on Gentoo... then for any other plugin
from nagios-plugins RPMs, such as "nagios-plugins-file_age", same
thing. So you get a big mess with duplicate definitions for the main
Gentoo "nagios-plugins" package, or you need yet another layer of high
level code hack :-/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Why is 'notify' acting as a 'before' and not a 'require' ?

[Felix Frank]

On 01/24/2012 10:51 AM, Alexandre wrote:
>  But it seems that for Puppet,
> parsing and applying the notified ressource is one operation, which
> means, if i understand correctly, that it is not possible to require
> and notify the same resource as i was expecting erroneously.

It's not. Both notify and require operate *only* on the order in which
the *agent* will apply resources.

Parsing happens on the master. There is no reason you would change its
order.

I sense we're still talking in circles so to make it yet more clear:
The decision wether an applied resource needs changing (I believe you
refer to this decision as "parsing") is indeed made at the time of
resource application and there is no way to separate these steps.

HTH,
Felix

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Why is 'notify' acting as a 'before' and not a 'require' ?

[Alexandre]

> Think about it. You want puppet to send a notification to a resource.
> Puppet must decide whether this notification gets sent. So it must
> process the notifying resource. After that, *if* a notification was in
> fact generated, it can process the notified resource.

I see. I was making a difference between parsing the notified
ressource and applying this resource. That is why i -though- the
notify would require the parsing, but Puppet would then apply/refresh
the notified resource afterwards. But it seems that for Puppet,
parsing and applying the notified ressource is one operation, which
means, if i understand correctly, that it is not possible to require
and notify the same resource as i was expecting erroneously.

>
> with whatever implementation you choose for your reload (in most cases
> you want to notify a service resource instead of an exec, but it's not
> more than a rule of thumb).

Yes, my class apache includes a Service, and the Exec requires it. But
since notifying the service will trigger an restart and not a reload,
i do not notify the Service directly ( I see there are open issues
#3323 and #1014 )

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Cross-module (package) dependencies

[Felix Frank]

Hi,

there was a discussion in the "can we deprecate defined() in Telly"
thread about how we can even begin to design Forge modules without it.

A recurring problem is that multiple modules rely on certain packages,
and there is no good model (yet) to unite their resource declarations.
Therefore it's a common (although imho disgusting) workaround to do
things like
if !defined(Package[foo]) { package { "foo": ensure => installed } }

On 01/20/2012 11:34 PM, Cody wrote:
> > Defining all somewhat common packages in a central location becomes
> > unrealistic when you no longer "control" the code that is in every
> > module you use.  If you obtain five modules from the forge and they
> > all require a specific package and so all define that package your not
> > going to convince, nor is it a good design to require everyone to move
> > the package definitions from that collection of modules.  They need to
> > function as a collection out of the box.
Agreed. How can this be accomplished?

Perhaps there needs to be some kind of "Forge common" module that by
policy can only ever declare virtual resources (packages are a prominent
example).
A user who wishes to retain the capability of using modules from the
Forge would be required to install this common module, and replace their
own resource declarations with realizations of the common resources.
For this to work, it's definitely a plus that you can override
attributes in collections:
Package<| title == "apache2": |> { ensure => "2.2.12" }
...although that does bear some caveats. Does this still work in recent
versions?

If we can take this for granted, all Forge modules can adhere to that
same standard.

This is a rough sketch of how things might possibly work, and surely has
lots of wrinkles of its own. Still, I'm quite sure we need a proper way
to rid ourselves of the horror that is the parse order dependent check
for defined resources ;-)

Cheers,
Felix

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.

[Felix Frank]

On 01/24/2012 01:57 AM, Nigel Kersten wrote:
> Felix, could you take this to a new thread please? I'd really like to
> keep this one focused on the topic at hand if possible :)

I'd had loved to, but I'm apparently too dumb to use E-Mail. Let's try
again ;(

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Cross-module (package) dependencies

[Felix Frank]

Hi,

there was a discussion in the "can we deprecate defined() in Telly"
thread about how we can even begin to design Forge modules without it.

A recurring problem is that multiple modules rely on certain packages,
and there is no good model (yet) to unite their resource declarations.
Therefore it's a common (although imho disgusting) workaround to do
things like
if !defined(Package[foo]) { package { "foo": ensure => installed } }

On 01/20/2012 11:34 PM, Cody wrote:
> Defining all somewhat common packages in a central location becomes
> unrealistic when you no longer "control" the code that is in every
> module you use.  If you obtain five modules from the forge and they
> all require a specific package and so all define that package your not
> going to convince, nor is it a good design to require everyone to move
> the package definitions from that collection of modules.  They need to
> function as a collection out of the box.

Agreed. How can this be accomplished?

Perhaps there needs to be some kind of "Forge common" module that by
policy can only ever declare virtual resources (packages are a prominent
example).
A user who wishes to retain the capability of using modules from the
Forge would be required to install this common module, and replace their
own resource declarations with realizations of the common resources.
For this to work, it's definitely a plus that you can override
attributes in collections:
Package<| title == "apache2": |> { ensure => "2.2.12" }
...although that does bear some caveats. Does this still work in recent
versions?

If we can take this for granted, all Forge modules can adhere to that
same standard.

This is a rough sketch of how things might possibly work, and surely has
lots of wrinkles of its own. Still, I'm quite sure we need a proper way
to rid ourselves of the horror that is the parse order dependent check
for defined resources ;-)

Cheers,
Felix

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Why is 'notify' acting as a 'before' and not a 'require' ?

[Felix Frank]

Hi,

On 01/24/2012 10:09 AM, Alexandre Fouché wrote:
> I find it logical that my 'BackupPC.conf' apache file is put after the
> apache package is installed, or more broadly after the apache class is
> complete. Afterwards, i put the 'BackupPC.conf' conf, and then
> afterwards, i want to notify Exec['apache-reload'], that it needs to
> reload. To me, the notify is a good way to ensure the apache class does
> not have to know anything about the backup class, and stay generic,
> while at the same time ensuring that the backup class can notify the
> apache service if it thinks it needs to.

Your outset looks a bit contradictory to me. Yes, requiring
Class["apache"] is sound design. But notifying a resource decalred
*within* that class is the complete opposite of that.

A better solution will take care of your problem as well.

> Unfortunately, the 'notify' is acting as a 'before' and creates a
> dependency cycle. It breaks the scheme of being able to keep the apache
> class generic yet able to respond to notifications

Think about it. You want puppet to send a notification to a resource.
Puppet must decide whether this notification gets sent. So it must
process the notifying resource. After that, *if* a notification was in
fact generated, it can process the notified resource. The opposite order
cannot be achieved. Therefore, notifies and subscriptions imply
before/requires relationships.

I suggest you add a class
apache::service {
 ...
}
with whatever implementation you choose for your reload (in most cases
you want to notify a service resource instead of an exec, but it's not
more than a rule of thumb).

The you can go ahead and require Class[apache] but notify
Class[apache::service]. For good measure, class apache will likely
include apache::service.

Hope this makes sense to you.

Cheers,
Felix

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Why is 'notify' acting as a 'before' and not a 'require' ?

[Alexandre Fouché]

Why is 'notify' acting as a 'before' and not a 'require' ?

Can someone explain why this way is unlogical to Puppet parser, why the
'notify' would create a dependency cycle ? Why would the 'notify' need to
create an order ? Isn't it supposed to carry a message, and not a
constraint ?

Typically i would need something like this

# First i have an Apache class
class apache {
#(...)
exec { 'apache-reload':
command => '/sbin/service httpd reload',
refreshonly => true,
require => Service['apache'],
}
}

# Then another class which adds an Apache conf file
class backup::backuppc::web {
#(...)

require 'apache'

file { '/etc/httpd/conf.d/BackupPC.conf':
#(...)
require => [ Class['apache'] ],
notify  => Exec['apache-reload'],
}
}

I find it logical that my 'BackupPC.conf' apache file is put after the
apache package is installed, or more broadly after the apache class is
complete. Afterwards, i put the 'BackupPC.conf' conf, and then afterwards,
i want to notify Exec['apache-reload'], that it needs to reload. To me, the
notify is a good way to ensure the apache class does not have to know
anything about the backup class, and stay generic, while at the same time
ensuring that the backup class can notify the apache service if it thinks
it needs to.

Unfortunately, the 'notify' is acting as a 'before' and creates a
dependency cycle. It breaks the scheme of being able to keep the apache
class generic yet able to respond to notifications

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.