HI all,
First thing - I''ve been keeping the puppet manifest, configs,
functions etc. in svn, but due to a few dodgy checkouts to the
puppetmaster (non production) i''d like to get a better process in
place. Are people using anything to test the puppet deployments?
preferably in a continuous environment. How are you
deploying/releasing puppet manifests etc.. to the master?
Also a quick puppet question:
I use this function to get an application tar file which is specified
in node manifest $dist = app-37434-3439493-.tar.gz:
exec { "get-app":
cwd => "/opt/dist",
creates => "/opt/dist/$dist",
path => ["/usr/bin", "/usr/sbin"],
command => "curl -s -f -o $dist
http://$repoUrl/app/$dist",
before => Exec["untar-dist"],
}
The ''creates'' value ensures that it doesn''t get
re-downloaded on every
puppet poll. Any new value to $dist works fine, but if $dist becomes
an old value then the file already exists, so the exec and subsequent
calls are not run.
I guess using the file type would cure this, but I don''t want the
master to serve the file, as I use a similar curl command to get the
file from S3 if specified.
Thanks,
Matt
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
We use environments for a release process, so we can test releases before pushing them to our stable environments. You can also get puppet to check manifests for syntax validity with --parseonly, which we and a lot of other people use as commit hooks in version control so that at least the syntax is guaranteed to be valid. That catches the fat finger errors, and the release process with environments lets us test the actual functionality. On Wed, Jan 7, 2009 at 4:02 AM, Matt <mattmoran76@gmail.com> wrote:> > HI all, > > First thing - I''ve been keeping the puppet manifest, configs, > functions etc. in svn, but due to a few dodgy checkouts to the > puppetmaster (non production) i''d like to get a better process in > place. Are people using anything to test the puppet deployments? > preferably in a continuous environment. How are you > deploying/releasing puppet manifests etc.. to the master? > > Also a quick puppet question: > > I use this function to get an application tar file which is specified > in node manifest $dist = app-37434-3439493-.tar.gz: > > exec { "get-app": > cwd => "/opt/dist", > creates => "/opt/dist/$dist", > path => ["/usr/bin", "/usr/sbin"], > command => "curl -s -f -o $dist http://$repoUrl/app/$dist", > before => Exec["untar-dist"], > } > > The ''creates'' value ensures that it doesn''t get re-downloaded on every > puppet poll. Any new value to $dist works fine, but if $dist becomes > an old value then the file already exists, so the exec and subsequent > calls are not run. > > I guess using the file type would cure this, but I don''t want the > master to serve the file, as I use a similar curl command to get the > file from S3 if specified. > > Thanks, > > Matt > > > >-- Nigel Kersten Systems Administrator Tech Lead - MacOps --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Using Modules, environments and version control you can really scale up. We currently manage a lot of environments with puppet, with a lot of different sys-admins, each group responsible to a different set of modules. since many times, a given node has uses many different modules (which are managed by different people) we decided to tag our "stable" modules (e.g. associate it with a version) and generate an environment out of tested combination of the stable modules. Cheers, Ohad On Thu, Jan 8, 2009 at 2:24 AM, Nigel Kersten <nigelk@google.com> wrote:> We use environments for a release process, so we can test releases before > pushing them to our stable environments. > You can also get puppet to check manifests for syntax validity with > --parseonly, which we and a lot of other people use as commit hooks in > version control so that at least the syntax is guaranteed to be valid. That > catches the fat finger errors, and the release process with environments > lets us test the actual functionality. > > > On Wed, Jan 7, 2009 at 4:02 AM, Matt <mattmoran76@gmail.com> wrote: > >> >> HI all, >> >> First thing - I''ve been keeping the puppet manifest, configs, >> functions etc. in svn, but due to a few dodgy checkouts to the >> puppetmaster (non production) i''d like to get a better process in >> place. Are people using anything to test the puppet deployments? >> preferably in a continuous environment. How are you >> deploying/releasing puppet manifests etc.. to the master? >> >> Also a quick puppet question: >> >> I use this function to get an application tar file which is specified >> in node manifest $dist = app-37434-3439493-.tar.gz: >> >> exec { "get-app": >> cwd => "/opt/dist", >> creates => "/opt/dist/$dist", >> path => ["/usr/bin", "/usr/sbin"], >> command => "curl -s -f -o $dist http:// >> $repoUrl/app/$dist", >> before => Exec["untar-dist"], >> } >> >> The ''creates'' value ensures that it doesn''t get re-downloaded on every >> puppet poll. Any new value to $dist works fine, but if $dist becomes >> an old value then the file already exists, so the exec and subsequent >> calls are not run. >> >> I guess using the file type would cure this, but I don''t want the >> master to serve the file, as I use a similar curl command to get the >> file from S3 if specified. >> >> Thanks, >> >> Matt >> >> >> > > > -- > Nigel Kersten > Systems Administrator > Tech Lead - MacOps > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
> since many times, a given node has uses many different modules (which are > managed by different people) we decided to tag our "stable" modules (e.g. > associate it with a version) and generate an environment out of tested > combination of the stable modules.Would you be willing to describe this process in a bit more detail? -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-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Ok - I''ll try to make it as simple as I can...
***Modules***
We define 3 types of modules (its just our internal definition):
1. host type - this module is the only class that the node would have and
its it primary function of the host (e.g. you can''t use more than one
host
type module in one node)
2. service modules - modules which are usually shared between different host
type modules (e.g. ssh, apache etc), one special module here is the
host-base which every host-type module inherits
3. site modules, these are site specific modules which only apply to a
certain location.
***Version Control***
we use tagging extensively - e.g. when a module is ready for testing, it is
being tagged, if everything is ready, its tagged again is production.
Tagging associate a version to the module - e.g. ssh_1.5
everyone can checkin stuff into the head, but unless they are not tagged,
they would only impact machines which are in the development environment
*** environments ***
environments can be defined per location, application or a mix of the two
for example, the environment global-puppetmasters would include the module
ssh_1.5, apache_1.0 ....
this allows each environment to use a different pretested state of each
module.
a configuration example:
module_dir { "/etc/puppet/env/global_puppetmaster":}
##### Stable service modules #####
modules { "PP-host-base": module => "host-base", site
=>
"global_puppetmaster", type => "services", version =>
"0.12"}
modules { "PP-sudo": module => "sudo", site
=>
"global_puppetmaster", type => "services", version =>
"0.1" }
modules { "PP-ssh": module => "ssh", site
=>
"global_puppetmaster", type => "services", version =>
"0.1" }
modules { "PP-sendmail": module => "sendmail", site
=>
"global_puppetmaster", type => "services", version =>
"0.14"}
modules { "PP-ldap": module => "ldap", site
=>
"global_puppetmaster", type => "services", version =>
"0.11"}
modules { "PP-redhat": module => "redhat", site
=>
"global_puppetmaster", type => "services", version =>
"0.12"}
modules { "PP-autofs": module => "autofs", site
=>
"global_puppetmaster", type => "services", version =>
"0.1" }
modules { "PP-apache2": module => "apache2", site
=>
"global_puppetmaster", type => "services", version =>
"0.1" }
modules { "PP-subversion":module => "subversion",site
=>
"global_puppetmaster", type => "services", version =>
"0.11"}
modules { "PP-syslog-ng": module => "syslog-ng", site
=>
"global_puppetmaster", type => "services", version =>
"0.11"}
modules { "PP-monit": module => "monit", site
=>
"global_puppetmaster", type => "services", version =>
"0.1" }
modules { "PP-munin": module => "munin", site
=>
"global_puppetmaster", type => "services", version =>
"0.1" }
#### stable host types modules #####
modules { "PP-puppetmaster": site =>
"global_puppetmaster", module
=> "host-puppetmaster", version => "0.21" }
}
using this syntax it creates all the necessary environment modules which
are basically links to the version of the "stable/testing" module.
all of this code is available freely at
http://github.com/ohadlevy/puppet-multipuppetmaster
cheers,
Ohad
On Fri, Jan 9, 2009 at 2:43 AM, Ben Beuchler <insyte@gmail.com> wrote:
>
> > since many times, a given node has uses many different modules (which
are
> > managed by different people) we decided to tag our "stable"
modules (e.g.
> > associate it with a version) and generate an environment out of tested
> > combination of the stable modules.
>
> Would you be willing to describe this process in a bit more detail?
>
> -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-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
If it''s not been already mentioned.. http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments may help On Fri, Jan 9, 2009 at 5:01 AM, Ohad Levy <ohadlevy@gmail.com> wrote:> Ok - I''ll try to make it as simple as I can... > > ***Modules*** > > We define 3 types of modules (its just our internal definition): > 1. host type - this module is the only class that the node would have and > its it primary function of the host (e.g. you can''t use more than one host > type module in one node) > 2. service modules - modules which are usually shared between different > host type modules (e.g. ssh, apache etc), one special module here is the > host-base which every host-type module inherits > 3. site modules, these are site specific modules which only apply to a > certain location. > > ***Version Control*** > > we use tagging extensively - e.g. when a module is ready for testing, it is > being tagged, if everything is ready, its tagged again is production. > > Tagging associate a version to the module - e.g. ssh_1.5 > > everyone can checkin stuff into the head, but unless they are not tagged, > they would only impact machines which are in the development environment > > *** environments *** > > environments can be defined per location, application or a mix of the two > > for example, the environment global-puppetmasters would include the module > ssh_1.5, apache_1.0 .... > > this allows each environment to use a different pretested state of each > module. > > a configuration example: > > module_dir { "/etc/puppet/env/global_puppetmaster":} > > ##### Stable service modules ##### > > modules { "PP-host-base": module => "host-base", site => "global_puppetmaster", type => "services", version => "0.12"} > modules { "PP-sudo": module => "sudo", site => "global_puppetmaster", type => "services", version => "0.1" } > modules { "PP-ssh": module => "ssh", site => "global_puppetmaster", type => "services", version => "0.1" } > > modules { "PP-sendmail": module => "sendmail", site => "global_puppetmaster", type => "services", version => "0.14"} > modules { "PP-ldap": module => "ldap", site => "global_puppetmaster", type => "services", version => "0.11"} > modules { "PP-redhat": module => "redhat", site => "global_puppetmaster", type => "services", version => "0.12"} > > modules { "PP-autofs": module => "autofs", site => "global_puppetmaster", type => "services", version => "0.1" } > modules { "PP-apache2": module => "apache2", site => "global_puppetmaster", type => "services", version => "0.1" } > modules { "PP-subversion":module => "subversion",site => "global_puppetmaster", type => "services", version => "0.11"} > > modules { "PP-syslog-ng": module => "syslog-ng", site => "global_puppetmaster", type => "services", version => "0.11"} > modules { "PP-monit": module => "monit", site => "global_puppetmaster", type => "services", version => "0.1" } > modules { "PP-munin": module => "munin", site => "global_puppetmaster", type => "services", version => "0.1" } > > #### stable host types modules ##### > modules { "PP-puppetmaster": site => "global_puppetmaster", module => "host-puppetmaster", version => "0.21" } > } > > using this syntax it creates all the necessary environment modules which > are basically links to the version of the "stable/testing" module. > > all of this code is available freely at > http://github.com/ohadlevy/puppet-multipuppetmaster > > cheers, > Ohad > > > > On Fri, Jan 9, 2009 at 2:43 AM, Ben Beuchler <insyte@gmail.com> wrote: > >> >> > since many times, a given node has uses many different modules (which >> are >> > managed by different people) we decided to tag our "stable" modules >> (e.g. >> > associate it with a version) and generate an environment out of tested >> > combination of the stable modules. >> >> Would you be willing to describe this process in a bit more detail? >> >> -Ben >> >> >> > > > >-- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe ''s/(.)/chr(ord($1)-1)/ge'' --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Nigel, I gather you run puppet --parseonly for each new file that svn is going to commit. Do you have your pre-hook to share? Thanks, Matt 2009/1/7 Nigel Kersten <nigelk@google.com>> We use environments for a release process, so we can test releases before > pushing them to our stable environments. > You can also get puppet to check manifests for syntax validity with > --parseonly, which we and a lot of other people use as commit hooks in > version control so that at least the syntax is guaranteed to be valid. That > catches the fat finger errors, and the release process with environments > lets us test the actual functionality. > > > On Wed, Jan 7, 2009 at 4:02 AM, Matt <mattmoran76@gmail.com> wrote: > >> >> HI all, >> >> First thing - I''ve been keeping the puppet manifest, configs, >> functions etc. in svn, but due to a few dodgy checkouts to the >> puppetmaster (non production) i''d like to get a better process in >> place. Are people using anything to test the puppet deployments? >> preferably in a continuous environment. How are you >> deploying/releasing puppet manifests etc.. to the master? >> >> Also a quick puppet question: >> >> I use this function to get an application tar file which is specified >> in node manifest $dist = app-37434-3439493-.tar.gz: >> >> exec { "get-app": >> cwd => "/opt/dist", >> creates => "/opt/dist/$dist", >> path => ["/usr/bin", "/usr/sbin"], >> command => "curl -s -f -o $dist http:// >> $repoUrl/app/$dist", >> before => Exec["untar-dist"], >> } >> >> The ''creates'' value ensures that it doesn''t get re-downloaded on every >> puppet poll. Any new value to $dist works fine, but if $dist becomes >> an old value then the file already exists, so the exec and subsequent >> calls are not run. >> >> I guess using the file type would cure this, but I don''t want the >> master to serve the file, as I use a similar curl command to get the >> file from S3 if specified. >> >> Thanks, >> >> Matt >> >> >> > > > -- > Nigel Kersten > Systems Administrator > Tech Lead - MacOps > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
I''m now running puppet --parseonly for every .pp in subversion. I''m running it via CI so the configs aren''t updated until they pass that test. Also just discovered the TextMate bundle which allows you to validate your manifests before you check in. Priceless. J. 2009/2/4 Matt <mattmoran76@gmail.com>:> Hi Nigel, > > I gather you run puppet --parseonly for each new file that svn is going to > commit. Do you have your pre-hook to share? > > Thanks, > > Matt > > 2009/1/7 Nigel Kersten <nigelk@google.com> >> >> We use environments for a release process, so we can test releases before >> pushing them to our stable environments. >> You can also get puppet to check manifests for syntax validity with >> --parseonly, which we and a lot of other people use as commit hooks in >> version control so that at least the syntax is guaranteed to be valid. That >> catches the fat finger errors, and the release process with environments >> lets us test the actual functionality. >> >> On Wed, Jan 7, 2009 at 4:02 AM, Matt <mattmoran76@gmail.com> wrote: >>> >>> HI all, >>> >>> First thing - I''ve been keeping the puppet manifest, configs, >>> functions etc. in svn, but due to a few dodgy checkouts to the >>> puppetmaster (non production) i''d like to get a better process in >>> place. Are people using anything to test the puppet deployments? >>> preferably in a continuous environment. How are you >>> deploying/releasing puppet manifests etc.. to the master? >>> >>> Also a quick puppet question: >>> >>> I use this function to get an application tar file which is specified >>> in node manifest $dist = app-37434-3439493-.tar.gz: >>> >>> exec { "get-app": >>> cwd => "/opt/dist", >>> creates => "/opt/dist/$dist", >>> path => ["/usr/bin", "/usr/sbin"], >>> command => "curl -s -f -o $dist >>> http://$repoUrl/app/$dist", >>> before => Exec["untar-dist"], >>> } >>> >>> The ''creates'' value ensures that it doesn''t get re-downloaded on every >>> puppet poll. Any new value to $dist works fine, but if $dist becomes >>> an old value then the file already exists, so the exec and subsequent >>> calls are not run. >>> >>> I guess using the file type would cure this, but I don''t want the >>> master to serve the file, as I use a similar curl command to get the >>> file from S3 if specified. >>> >>> Thanks, >>> >>> Matt >>> >>> >> >> >> >> -- >> Nigel Kersten >> Systems Administrator >> Tech Lead - MacOps >> >> > > > > >-- Julian Simpson Software Build and Deployment http://www.build-doctor.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
> module_dir { "/etc/puppet/env/global_puppetmaster":} > > ##### Stable service modules ##### > modules { "PP-host-base": module => "host-base", site => > "global_puppetmaster", type => "services", version => "0.12"} > modules { "PP-sudo": module => "sudo", site => > "global_puppetmaster", type => "services", version => "0.1" } > modules { "PP-ssh": module => "ssh", site => > "global_puppetmaster", type => "services", version => "0.1" } > modules { "PP-sendmail": module => "sendmail", site => > "global_puppetmaster", type => "services", version => "0.14"} > modules { "PP-ldap": module => "ldap", site => > "global_puppetmaster", type => "services", version => "0.11"} > modules { "PP-redhat": module => "redhat", site => > "global_puppetmaster", type => "services", version => "0.12"} > modules { "PP-autofs": module => "autofs", site => > "global_puppetmaster", type => "services", version => "0.1" } > modules { "PP-apache2": module => "apache2", site => > "global_puppetmaster", type => "services", version => "0.1" } > modules { "PP-subversion":module => "subversion",site => > "global_puppetmaster", type => "services", version => "0.11"} > modules { "PP-syslog-ng": module => "syslog-ng", site => > "global_puppetmaster", type => "services", version => "0.11"} > modules { "PP-monit": module => "monit", site => > "global_puppetmaster", type => "services", version => "0.1" } > modules { "PP-munin": module => "munin", site => > "global_puppetmaster", type => "services", version => "0.1" } > #### stable host types modules ##### > modules { "PP-puppetmaster": site => "global_puppetmaster", module > => "host-puppetmaster", version => "0.21" } > > } > > using this syntax it creates all the necessary environment modules which > are basically links to the version of the "stable/testing" module.Hmm some comments to this... This sounds like a bear to maintain, while I think it''s important to do in a complex environment like you have. I''m wishing the info you are doing is more included in the module syntax of Puppet''s language itself. It''s interesting to see you don''t use Puppet''s built in tagging (ie development, staging, production). Just curious why? What would you consider needed in Puppet to make your development easier? I''m thinking: - module version - dependencies needed to get the module working (with version info) - some sort of naming convention to allow modules to be shareable, and cannot overlap (ie one person has a openssh-server module that does one thing, yet another person uses the same name but does something different) This is needed so modules can be shared in some sort of public repository. -L --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Sun, Feb 8, 2009 at 9:59 AM, Larry Ludwig <larrylud@gmail.com> wrote:> > Hmm some comments to this... > > This sounds like a bear to maintain, while I think it''s important to > do in a complex environment like you have. >The structure itself is complicated, however the usage is quite simple if you understand the structure..... nevertheless, if you have any better/simpler idea - I would really love to hear it..> > I''m wishing the info you are doing is more included in the module > syntax of Puppet''s language itself.I''m not sure I understood your question...What do you mean module syntax? (the define?) we are only using the puppet language (with a special directory structure in scm).> > > It''s interesting to see you don''t use Puppet''s built in tagging (ie > development, staging, production). Just curious why? >by tagging you mean to tag resources? that would be hard to maintain when you have multiple environments (e.g. 10+) additionally, it means that someone could edit/break a productive manifest. if by development staging, production you mean puppet modules/environments, of course we use them, but we simply have way more environments that just 3 ( different locations/applications have different "stable/production" levels) - and thats kinda the tricky part here. one of our goals was to harmonize our global environment, but at the same time, its impossible to force everyone to do a change at a certain given time. therefor, every location subscribes to a module combinations (an environment) which in turn is made out of modules in predefined versions.> What would you consider needed in Puppet to make your development > easier?I''m not really sure if puppet can help much here, its more of having guidelines of how to use modules, where to put them and how to call them...> > > I''m thinking: > - module versionshould not be managed by puppet - puppet is not a scm> > - dependencies needed to get the module working (with version info)thats easy to achieve if you save the version number as a variable - nevertheless, usually you dont care about a specific module version, you care about a mix of modules.> > - some sort of naming convention to allow modules to be shareable, and > cannot overlap (ie one person has a openssh-server module that does > one thing, yet another person uses the same name but does something > different) This is needed so modules can be shared in some sort of > public repository.I would really love to have a public repo (and if I''m allowed, I would love to publish our manifests) I know that there was a try to get a public repo - is it still around? Ohad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Feb 4, 2009 at 2:28 AM, Matt <mattmoran76@gmail.com> wrote:> Hi Nigel, > > I gather you run puppet --parseonly for each new file that svn is going to > commit. Do you have your pre-hook to share?It''s actually perforce, not subversion... and is kind of integrated into some custom infrastructure here. Basically it look at each file to be modified in a changelist, and if it''s an add or a modify, it runs --parseonly. We used to use puppetmasterd --parseonly which was better as it would catch errors like imports of modules that didn''t exist, rather than just syntactic errors, but that started breaking at some point quite a while ago. The best test though is to have machines that puppet against your most unstable branches continuously imho.> > Thanks, > > Matt > > 2009/1/7 Nigel Kersten <nigelk@google.com> >> >> We use environments for a release process, so we can test releases before >> pushing them to our stable environments. >> You can also get puppet to check manifests for syntax validity with >> --parseonly, which we and a lot of other people use as commit hooks in >> version control so that at least the syntax is guaranteed to be valid. That >> catches the fat finger errors, and the release process with environments >> lets us test the actual functionality. >> >> On Wed, Jan 7, 2009 at 4:02 AM, Matt <mattmoran76@gmail.com> wrote: >>> >>> HI all, >>> >>> First thing - I''ve been keeping the puppet manifest, configs, >>> functions etc. in svn, but due to a few dodgy checkouts to the >>> puppetmaster (non production) i''d like to get a better process in >>> place. Are people using anything to test the puppet deployments? >>> preferably in a continuous environment. How are you >>> deploying/releasing puppet manifests etc.. to the master? >>> >>> Also a quick puppet question: >>> >>> I use this function to get an application tar file which is specified >>> in node manifest $dist = app-37434-3439493-.tar.gz: >>> >>> exec { "get-app": >>> cwd => "/opt/dist", >>> creates => "/opt/dist/$dist", >>> path => ["/usr/bin", "/usr/sbin"], >>> command => "curl -s -f -o $dist >>> http://$repoUrl/app/$dist", >>> before => Exec["untar-dist"], >>> } >>> >>> The ''creates'' value ensures that it doesn''t get re-downloaded on every >>> puppet poll. Any new value to $dist works fine, but if $dist becomes >>> an old value then the file already exists, so the exec and subsequent >>> calls are not run. >>> >>> I guess using the file type would cure this, but I don''t want the >>> master to serve the file, as I use a similar curl command to get the >>> file from S3 if specified. >>> >>> Thanks, >>> >>> Matt >>> >>> >> >> >> >> -- >> Nigel Kersten >> Systems Administrator >> Tech Lead - MacOps >> >> > > > > >-- Nigel Kersten Systems Administrator Tech Lead - MacOps --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
> > The structure itself is complicated, however the usage is quite simple if > you understand the structure..... nevertheless, if you have any > better/simpler idea - I would really love to hear it..I''m starting to look into what other users of Puppet are doing before I draw any conclusions/recommendations. I would like to hear of any other users and their comments. In order for Puppet to really work it must not only scale to large amounts of computers but also a large amount of administrations/system programmers working on recipes.> I''m not sure I understood your question...What do you mean module syntax? > (the define?) we are only using the puppet language (with a special > directory structure in scm).Ok really Class statement, other than file structure there is no Module statement in the language itself. Maybe this is part of the problem :-)> > I''m thinking: > > - module version > > should not be managed by puppet - puppet is not a scmnot scm, but the module state it''s version info. Kinda like Ruby gems. So you can require a specific version of a module when running your app. Also have the ability to have multiple versions with Puppet.> > - dependencies needed to get the module working (with version info) > > thats easy to achieve if you save the version number as a variable - > nevertheless, usually you dont care about a specific module version, you > care about a mix of modules.Well it can be both. For example (puppetshow as for one) how many times you an app develop in Ruby and you need a specific version of Rails?? Use the latest and boom! Not nice in a production enviroment. It is also possible in the existing Puppet world that one person has a module that overlaps another module developed by someone else. Yes it can be a variable but it''s not forced on the module creator. Putting it into the language forces this on the developer. In order for Puppet to allow easy sharing of modules something like this needs to happen.> I would really love to have a public repo (and if I''m allowed, I would love > to publish our manifests) I know that there was a try to get a public repo - > is it still around?As I am getting ready to release some Puppet modules, I''m realizing the current limitations of Puppet and sharing modules with the general public. IMHO this is also one of the reasons why the public module list in the wiki is so small. Puppet so far has changed the way we perform administration, what it hasn''t done yet is make it easy to share ''the secret sauce" with other administrators. Once this happens on large scale I think some interesting things will happen. -L --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
> > I would really love to have a public repo (and if I''m allowed, I would love > to publish our manifests) I know that there was a try to get a public repo - > is it still around? >I know about: http://projects.reductivelabs.com/projects/show/pcm But I haven''t seen much action with this yet.. -L --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---