Re: [Puppet Users] Using Puppet for application deployment

2010-03-16 Thread Michael DeHaan
On Tue, Mar 16, 2010 at 1:14 PM, David Schmitt  wrote:
> On 3/16/2010 6:13 PM, Joe McDonagh wrote:
>>
>> David Schmitt wrote:
>>>
>>>
>>>
>>> Which leads me to another idea: inter-node dependencies:
>>>
>>> | node a { mysql_db { "foo": ... } }
>>> |
>>> | node b { app { "x": after => A>>Mysql_db["foo"]; } }
>>>
>>>
>>>
>> David, are you suggesting this, or are you saying that this works?
>>
>
> I'm suggesting something like this. Internally it'd probably work like
> external_resource (see -dev list for details) but would query the
> storeconfig DB instead of calling a script on the client.
>
>

Yeah I had the same idea.

I think Luke was suggesting a higher level of modelling, but that can
work now, provided there's a way to easily create the content for the
remote resource check.

The Func-like approach would be for each node to surface what it's
"gates" were, and then set up authorization to allow other nodes to
ask them if a particular task was performed.

I'm not /quite/ sure that is sufficient though, or otherwise the gates
would have to be pretty smart -- for controlling an app upgrade you
would need more of a check than just seeing if the DB was present or a
version number was in a table.

--Michael

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] hard to define

2010-03-16 Thread Marcus Moeller
Hi all.

I am trying to use debian package preseeding within my modules.
Therefor I have created a preseed_package.pp like:

define authentication::preseed_package ( $ensure ) {
file { "/var/local/preseed/$name.preseed":
source => "$module_path/files/$name.preseed",
mode => 600,
backup => false,
require => File["/var/local/preseed"],
}
package { "$name":
ensure => $ensure,
responsefile => "/var/local/preseed/$name.preseed",
require => File["/var/local/preseed/$name.preseed"],
}
}

First of all I would like to know if it's possible to use variables
within the define statement, e.g.:

define $module_name::preseed_package

This would make the define much more flexible as I could then just
copy it over to the other modules if necessary.

But now to the main question: as you can see from above, the file
deployment requires a directory /var/local/preseed/ to be present.

I wonder what's the best way to create this directory? Within the
init.pp of the specific module, e.g ?.:

class authentication {
# general module settings
$module_name = "authentication"
$module_path = "$puppet_standalone/modules/$module_name"

# preseed functionality
file { "/var/local/preseed":
owner => root, group => root, mode => 755,
ensure => "directory",
}


}

Or perhaps even at the top of preseed_package.pp?

Best Regards
Marcus

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Apps that are using facter as a library or shell out to facter?

2010-03-16 Thread Michael DeHaan
>
> Exactly, just add a "ttl-hint: 24" (hours) value to the JSON.

Hmm

I'd saw this as something that would be a property of the fact, rather
than the output of the fact.

That is, I didn't see a need for variable timeouts.

That being said, if we do the "fact.d" for plugins, those scripts will
want to also use this mechanism,
so perhaps those /do/ speak it in JSON.

>
> On the other hand, stuff like --test should probably ignore such hints.

Yep.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Using Puppet for application deployment

2010-03-16 Thread Joe McDonagh

David Schmitt wrote:

[crossposting to puppet-dev, please trim follow-ups appropriately]

On 3/16/2010 11:52 AM, Jesús Couto wrote:



On Mon, Mar 15, 2010 at 3:18 PM, Michael DeHaan
mailto:mich...@reductivelabs.com>> wrote:

 > that are very much procedural while Puppet manifest are more
 > useful on a description of required software level.

Sort of.

The long story is that we don't have a really native feeling way to
model multinode deployments and workflow now, but we can think of
modeling it based on a set of checkpoint conditions.


On a complete pipe-dream, "I'm not the one with the skills to do this"
comment, I think it would be great to extend the Puppet language toward
"site" configurations. As exported resources, but more. If you could
define, say, an "application" resource that is not on a node but on
several nodes, that would model the application - this app is this and
this running on those 2 servers who are on loadbalancing and this and
that on those other 2, and the parts on the webservers requires the
parts on the appservers that requires the parts on the database
servers...dont know at what level could it be modeled to be flexible
enough and not one size "deploy" model for all, but the idea would be to
make it like Puppet goes from "let me script this" to "let me describe
how it should be", with you describing your application structucture and
relationships and such.




If you want to prototype something like this, you can use a define 
outside of a node in the site.pp and use checks against $fqdn to 
distribute resources among hosts.


Maybe even use the external_resource type that's currently floating 
around to sequence the deployment.



Which leads me to another idea: inter-node dependencies:

| node a { mysql_db { "foo": ... } }
|
| node b { app { "x": after => A>>Mysql_db["foo"]; } }


(please ignore the crude syntax)


Best Regards, David
I don't immediately see it in my dev list, but I'll take your word for 
it. I am with you on the inter-node dependencies.


--
Joe McDonagh
AIM: YoosingYoonickz
IRC: joe-mac on freenode
L'ennui est contre-révolutionnaire

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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] Running on EC2 without a puppetmaster?

2010-03-16 Thread Akins, Brian
On 3/16/10 2:42 PM, "Ben Lavender"  wrote:

> I'm wondering if anyone else has run this sort of setup, and if so, if
> you preferred it or came to regret it?

We are doing something similar.  We have a "wrapper" script that tries to
rsync down the latest version of /etc/puppet, then runs puppet in a loop
until it exits 0 or runs 10 times.  So far, so good.


-- 
Brian Akins

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Running on EC2 without a puppetmaster?

2010-03-16 Thread Ben Lavender
Hi all,

I'm setting up a buzzword-compliant auto-scaling thing on EC2, and I
have something I'd like some more opinion on.  Namely, I am going to
be making my own AMI (getting the app set up takes ~20 mins
otherwise), and it seems perfectly workable to store the entire config
in /etc/puppet and just running puppet on the manifest--no puppetd, no
puppetmaster, just a git pull to get any recent changes and run once
at boot.  This works fine, of course, but I lose the ability to push
changes to the nodes without touching them manually.

I'm wondering if anyone else has run this sort of setup, and if so, if
you preferred it or came to regret it?

Thanks,
Ben

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Using Puppet for application deployment

2010-03-16 Thread David Schmitt

On 3/16/2010 6:13 PM, Joe McDonagh wrote:

David Schmitt wrote:




Which leads me to another idea: inter-node dependencies:

| node a { mysql_db { "foo": ... } }
|
| node b { app { "x": after => A>>Mysql_db["foo"]; } }




David, are you suggesting this, or are you saying that this works?



I'm suggesting something like this. Internally it'd probably work like 
external_resource (see -dev list for details) but would query the 
storeconfig DB instead of calling a script on the client.



Regards, David
--
dasz.at OG  Tel: +43 (0)664 2602670 Web: http://dasz.at
Klosterneuburg UID: ATU64260999

   FB-Nr.: FN 309285 g  FB-Gericht: LG Korneuburg

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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] Using Puppet for application deployment

2010-03-16 Thread Joe McDonagh

David Schmitt wrote:




Which leads me to another idea: inter-node dependencies:

| node a { mysql_db { "foo": ... } }
|
| node b { app { "x": after => A>>Mysql_db["foo"]; } }




David, are you suggesting this, or are you saying that this works?

--
Joe McDonagh
AIM: YoosingYoonickz
IRC: joe-mac on freenode
L'ennui est contre-révolutionnaire

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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] config_version in template?

2010-03-16 Thread Daniel Kerwin
Hi list,

is it possible to add a system variable like config_version to a template?

-- 

Cheers,

Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] dynamic parameters in defines - HowTo?

2010-03-16 Thread David Schmitt

On 3/16/2010 2:06 PM, Simon Mügge wrote:

Hi there!

Context: HowTo define a somewhat generic serviceinstance

Ive got:
#define.pp
define service::instance ( $instancename, $instanceip ) {
#do stuff
}

#class.pp
class serviceA {
service::instance{"funnyname":
instancename =>  ["somenameA", "realnameA"],
instanceip =>["1.2.3.4", "2.3.4.5", "3.4.5.6"],
}
}

which wich works, but (depending on the usecase) is damn ugly and does
not exactly handle the way I want it to..

id like to be able to do:
#define.pp
define service::instance ( $instancename, ${${instancename}_ip} ) {
#do stuff
}

#class.pp
class serviceA {
service::instance{"funnyname":
instancename =>  ["somenameA", "realnameA"],
somenameA_ip =>  "1.2.3.4",
realnameA_ip =>  ["2.3.4.5", "3.4.5.6"],
}
}

But puppet does NOT seem to like this construct "${${instancename}
_ip}" (and I cant really blame it..) - does anyone have a hint as to
how to do this?


The proper syntax would be

> class serviceA {
>service::instance{
>"somenameA":
>ip =>  "1.2.3.4";
>"realnameA":
>ip =>  ["2.3.4.5", "3.4.5.6"];
>}
> }

or

> class serviceA {
>service::instance{
>"funnyname":
>public => "somenameA",
>public_ip => "1.2.3.4",
>realnames => "realnameA",
>real_ips =>  ["2.3.4.5", "3.4.5.6"];
>}
> }

(where public_ip and real_ips would be hardcoded names)

depending on your use case.

if you can describe your particular case in more depth, perhaps there 
are other, better methods to implement this.



Regards, David
--
dasz.at OG  Tel: +43 (0)664 2602670 Web: http://dasz.at
Klosterneuburg UID: ATU64260999

   FB-Nr.: FN 309285 g  FB-Gericht: LG Korneuburg

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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] dynamic parameters in defines - HowTo?

2010-03-16 Thread Simon Mügge
Hi there!

Context: HowTo define a somewhat generic serviceinstance

Ive got:
#define.pp
define service::instance ( $instancename, $instanceip ) {
#do stuff
}

#class.pp
class serviceA {
service::instance{"funnyname":
instancename => ["somenameA", "realnameA"],
instanceip =>   ["1.2.3.4", "2.3.4.5", "3.4.5.6"],
}
}

which wich works, but (depending on the usecase) is damn ugly and does
not exactly handle the way I want it to..

id like to be able to do:
#define.pp
define service::instance ( $instancename, ${${instancename}_ip} ) {
#do stuff
}

#class.pp
class serviceA {
service::instance{"funnyname":
instancename => ["somenameA", "realnameA"],
somenameA_ip => "1.2.3.4",
realnameA_ip => ["2.3.4.5", "3.4.5.6"],
}
}

But puppet does NOT seem to like this construct "${${instancename}
_ip}" (and I cant really blame it..) - does anyone have a hint as to
how to do this?

Cheers,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] seg fault after client upgrade

2010-03-16 Thread Len Rugen
See above, I upgraded Ruby to 1.8.5, but then ruby-shadow fails.  The link
posted is what I used to get ruby-shadow working long ago under 24.8, but
it's not helping now.

On Mon, Mar 15, 2010 at 10:32 PM, Ohad Levy  wrote:

> this breaks because puppet still uses YAML for the local catalog cache.
>
> the best way to solve it now is by upgrading your ruby (or installing a
> newer ruby next to the old one).
>
> I do it for RHE3 machines, seems like it also must be done for RHEL4 as its
> seems low prio for RL.
>
> cheers,
> Ohad
>
>
> On Tue, Mar 16, 2010 at 3:47 AM, Todd Zullinger  wrote:
>
>> Len Rugen wrote:
>> > We updated our server last week to 25.4 and have updated a few clients.
>> > I've got one now that is irritated:
>> >
>> > info: Caching catalog for 
>> > /usr/lib64/ruby/1.8/yaml/rubytypes.rb:315: [BUG] Segmentation fault
>> > ruby 1.8.1 (2003-12-25) [x86_64-linux-gnu]
>> >
>> > Any thoughts?
>>
>> Yuck.  This is http://projects.reductivelabs.com/issues/2604
>>
>> We'll have to get some sort of work-around into the EPEL packages.
>> Seems no one reported this after a month or so in epel-testing. :/
>>
>> --
>> ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
>> ~~
>> I honor and express all facets of my being, regardless of federal,
>> state and local laws.
>>
>>
>   --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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] Package Providers for OS X Server

2010-03-16 Thread Alan Barrett
On Mon, 15 Mar 2010, Gary Larizza Jr. wrote:
> Visiting here -->
> http://docs.reductivelabs.com/references/stable/type.html#package
> It looks like appdmg, pkgdmg, and darwinport are the most viable
> providers for OS X.

I don't use OS X, but it is one of the platforms supported by pkgsrc
(see http://www.pkgsrc.org/), and some binary packages are available at
ftp://ftp.netbsd.org/pub/pkgsrc/packages/Darwin/ if you don't want to
build your own.

Puppet doesn't have a "pkgsrc" package provider, but either of the
"openbsd" or "freebsd" package providers will probably be close enough.

--apb (Alan Barrett)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] managing secondary groups

2010-03-16 Thread Dick Davies
On Mon, Mar 15, 2010 at 9:52 AM, Bruce Richardson  wrote:
> On Mon, Mar 15, 2010 at 09:31:54AM +, Dick Davies wrote:
>> Offhand, does anyone know the difference between the 2
>> constructs below to manage secondary groups ?
>> This is the 'groupadd' provider I think (CentOS).
>> Think I'd prefer the  former if the result is the same
>
> The result will be the same.  How did you think it might be different?

Was thinking of operational quirks - whether they both support ensure
= absent, etc.
But yeah, i suppose they both edit /etc/groups at the end of the day.

> The path to execution within Puppet will be different, which may or may
> not matter to you.
>
> --
> Bruce
>
> Remember you're a Womble.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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] Using Puppet for application deployment

2010-03-16 Thread David Schmitt

[crossposting to puppet-dev, please trim follow-ups appropriately]

On 3/16/2010 11:52 AM, Jesús Couto wrote:



On Mon, Mar 15, 2010 at 3:18 PM, Michael DeHaan
mailto:mich...@reductivelabs.com>> wrote:

 > that are very much procedural while Puppet manifest are more
 > useful on a description of required software level.

Sort of.

The long story is that we don't have a really native feeling way to
model multinode deployments and workflow now, but we can think of
modeling it based on a set of checkpoint conditions.


On a complete pipe-dream, "I'm not the one with the skills to do this"
comment, I think it would be great to extend the Puppet language toward
"site" configurations. As exported resources, but more. If you could
define, say, an "application" resource that is not on a node but on
several nodes, that would model the application - this app is this and
this running on those 2 servers who are on loadbalancing and this and
that on those other 2, and the parts on the webservers requires the
parts on the appservers that requires the parts on the database
servers...dont know at what level could it be modeled to be flexible
enough and not one size "deploy" model for all, but the idea would be to
make it like Puppet goes from "let me script this" to "let me describe
how it should be", with you describing your application structucture and
relationships and such.




If you want to prototype something like this, you can use a define 
outside of a node in the site.pp and use checks against $fqdn to 
distribute resources among hosts.


Maybe even use the external_resource type that's currently floating 
around to sequence the deployment.



Which leads me to another idea: inter-node dependencies:

| node a { mysql_db { "foo": ... } }
|
| node b { app { "x": after => A>>Mysql_db["foo"]; } }


(please ignore the crude syntax)


Best Regards, David
--
dasz.at OG  Tel: +43 (0)664 2602670 Web: http://dasz.at
Klosterneuburg UID: ATU64260999

   FB-Nr.: FN 309285 g  FB-Gericht: LG Korneuburg

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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] Using Puppet for application deployment

2010-03-16 Thread Jesús Couto
On Mon, Mar 15, 2010 at 3:18 PM, Michael DeHaan
wrote:

> > that are very much procedural while Puppet manifest are more
> > useful on a description of required software level.
>
> Sort of.
>
> The long story is that we don't have a really native feeling way to
> model multinode deployments and workflow now, but we can think of
> modeling it based on a set of checkpoint conditions.
>
>
On a complete pipe-dream, "I'm not the one with the skills to do this"
comment, I think it would be great to extend the Puppet language toward
"site" configurations. As exported resources, but more. If you could define,
say, an "application" resource that is not on a node but on several nodes,
that would model the application - this app is this and this running on
those 2 servers who are on loadbalancing and this and that on those other 2,
and the parts on the webservers requires the parts on the appservers that
requires the parts on the database servers...dont know at what level could
it be modeled to be flexible enough and not one size "deploy" model for all,
but the idea would be to make it like Puppet goes from "let me script this"
to "let me describe how it should be", with you describing your application
structucture and relationships and such.





-- 
--

Jesús Couto F.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Apps that are using facter as a library or shell out to facter?

2010-03-16 Thread David Schmitt

On 3/15/2010 6:49 PM, Michael DeHaan wrote:

Yeah that's certainly one of the things I want to do, as is if we're
calling out to a command to parse it and can cache/process it in one
time as opposed to calling a billion ifconfig/dmidecodes that'd be
good too.


Yep, if you're shelling out or executing 'puppet' without the daemon,
in memory caching doesn't work.  (But how slow are we really?)


munin has the same problem on the agents: shelling out with a simple 
text pipe interface gives HUGE(!!) flexibility but hurts collection 
performance.



> Cache dir would be simple though...
>
> You could simply stat the file and see when the last fact storage run
> happened, and each module could set (or not set) a timeout on a
> case-by-case basis.
> No timeout would mean don't cache, so it would automatically work with
> any existing facts, and the facts wouldn't have to implement the
> caching
> themselves.

Exactly, just add a "ttl-hint: 24" (hours) value to the JSON.

On the other hand, stuff like --test should probably ignore such hints.



Best Regards, David


--
dasz.at OG  Tel: +43 (0)664 2602670 Web: http://dasz.at
Klosterneuburg UID: ATU64260999

   FB-Nr.: FN 309285 g  FB-Gericht: LG Korneuburg

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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.