Puppet users - Nov 2010 - EC2 with puppet bootstrap notes and scripts

Hello...


  I wanted to be able to startup an EC2 instance with one command and
have a fully functioning server without having to shell into each new
instance and configure the bits to allow puppet to finish the
configuration.  Here are some notes I came up with for bootstrapping an
ec2 instance with puppet using Ubuntu 10.04.  I left out a lot of things
about creating and running custom AIM images, but the minimum puppet
bits are below.  Hopefully this will help out others working within EC2
and using puppet to manage their running instances.  Currently this
requires the puppetmaster to use autosigning.  At some point I''ll post
this somewhere with more detailed instructions including building a
custom AMI.  


  There is a chicken and the egg problem with bringing up EC2 instances
auto-magically with puppet.  For the puppet client to bootstrap
correctly there are several things that have to match up.  The
puppetmaster is easy, it needs to know the FQDN of the client which is
whatever you want it to be.  The hard part is that the puppet client
needs to know where the puppetmaster is and know its FQDN.

  When a generic EC2 instance is started it has a hostname of
localhost.localdomain (or something like ip-10-111-222-33), a
searchdomain of ec2.internal, and only the loopback address
in /etc/hosts.  To get a puppet client to bootstrap correctly all three
of these things need to be changed.  The searchdomain
in /etc/resolv.conf is reset on each boot by the dhcp client.  To
''fix''
this you can add ''supersede domain-name
"example.com";''
to /etc/dhcp3/dhclient.conf. and add ''server.ip.addr.ess
puppetmaster.example.com'' to /etc/hosts.  To get the hostname changed
without generating custom AMIs for each server I used a small script
called by rc.local to set the hostname, then startup the puppet client.
My complete setup is a little more complicated, but to just do these
three things looks something like the following.


The resulting image is started with something like:
shell> ec2-run-instances ... --user-data "myservername" ami-123abc
resulting in a server with the FQDN myservername.example.com



# mount linux image and chroot to the mount location
# this could be done via debootstrap or other

# install puppet client

# get our domain name in /etc/resolv.conf
cat <<EOF >>/etc/dhcp3/dhclient.conf
supersede domain-name "example.com";
EOF

# add puppetmaster to hosts file
cat <<EOF > /etc/hosts
127.0.0.1   localhost
10.111.222.3 puppetmaster.example.com puppet.example.com puppet
EOF


# add a script to set hostname from userdata set when instance is
started
cat <<EOF > /etc/puppet/ec2init.sh
#!/bin/bash
# simple hack, really needs some sanity checking

# wait for data since it takes a while to show up at first
sleep 120

# the hostname data is added via something like:
# shell> ec2-run-instances ... --user-data "myservername"
ami-123abc
# by definition, the first line MUST be the hostname
# potentially in the future there could be more data
curl --silent http://169.254.169.254/2008-02-01/user-data | head -n
1
> /etc/hostname
hostname --file /etc/hostname

# yes, thrice
/usr/sbin/puppetd --no-daemonize --onetime --server
puppetmaster.example.com
/usr/sbin/puppetd --no-daemonize --onetime --server
puppetmaster.example.com
/usr/sbin/puppetd --no-daemonize --onetime --server
puppetmaster.example.com

# turn ourselves off and reboot
chmod 644 /etc/puppet/ec2init.sh
/sbin/reboot

EOF


# make runable
chmod 755 /etc/puppet/ec2init.sh


# call from rc.local 
sed --in-place "s#exit 0##" /etc/rc.local

cat <<EOF >> /etc/rc.local
test -x /etc/puppet/ec2init.sh && /etc/puppet/ec2init.sh
exit 0
EOF



# unmount and create your AMI 

w00t!  





-- 
Christopher McCrory
To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.

-- 
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, Nov 7, 2010 at 9:52 AM, Christopher McCrory
<chrismcc@gmail.com>wrote:
> Hello...
>
>
>  I wanted to be able to startup an EC2 instance with one command and
> have a fully functioning server without having to shell into each new
> instance and configure the bits to allow puppet to finish the
> configuration.  Here are some notes I came up with for bootstrapping an
> ec2 instance with puppet using Ubuntu 10.04.  I left out a lot of things
> about creating and running custom AIM images, but the minimum puppet
> bits are below.  Hopefully this will help out others working within EC2
> and using puppet to manage their running instances.  Currently this
> requires the puppetmaster to use autosigning.  At some point I''ll
post
> this somewhere with more detailed instructions including building a
> custom AMI.
>
>
>  There is a chicken and the egg problem with bringing up EC2 instances
> auto-magically with puppet.  For the puppet client to bootstrap
> correctly there are several things that have to match up.  The
> puppetmaster is easy, it needs to know the FQDN of the client which is
> whatever you want it to be.  The hard part is that the puppet client
> needs to know where the puppetmaster is and know its FQDN.
>
>  When a generic EC2 instance is started it has a hostname of
> localhost.localdomain (or something like ip-10-111-222-33), a
> searchdomain of ec2.internal, and only the loopback address
> in /etc/hosts.  To get a puppet client to bootstrap correctly all three
> of these things need to be changed.  The searchdomain
> in /etc/resolv.conf is reset on each boot by the dhcp client.  To
''fix''
> this you can add ''supersede domain-name
"example.com";''
> to /etc/dhcp3/dhclient.conf. and add ''server.ip.addr.ess
> puppetmaster.example.com'' to /etc/hosts.  To get the hostname
changed
> without generating custom AMIs for each server I used a small script
> called by rc.local to set the hostname, then startup the puppet client.
> My complete setup is a little more complicated, but to just do these
> three things looks something like the following.
>
>
> The resulting image is started with something like:
> shell> ec2-run-instances ... --user-data "myservername"
ami-123abc
> resulting in a server with the FQDN myservername.example.com
>
>
>
> # mount linux image and chroot to the mount location
> # this could be done via debootstrap or other
>
> # install puppet client
>
> # get our domain name in /etc/resolv.conf
> cat <<EOF >>/etc/dhcp3/dhclient.conf
> supersede domain-name "example.com";
> EOF
>
> # add puppetmaster to hosts file
> cat <<EOF > /etc/hosts
> 127.0.0.1   localhost
> 10.111.222.3 puppetmaster.example.com puppet.example.com puppet
> EOF
>
>
> # add a script to set hostname from userdata set when instance is
> started
> cat <<EOF > /etc/puppet/ec2init.sh
> #!/bin/bash
> # simple hack, really needs some sanity checking
>
> # wait for data since it takes a while to show up at first
> sleep 120
>
> # the hostname data is added via something like:
> # shell> ec2-run-instances ... --user-data "myservername"
ami-123abc
> # by definition, the first line MUST be the hostname
> # potentially in the future there could be more data
> curl --silent http://169.254.169.254/2008-02-01/user-data | head -n 1
> > /etc/hostname
> hostname --file /etc/hostname
>
> # yes, thrice
> /usr/sbin/puppetd --no-daemonize --onetime --server
> puppetmaster.example.com
> /usr/sbin/puppetd --no-daemonize --onetime --server
> puppetmaster.example.com
> /usr/sbin/puppetd --no-daemonize --onetime --server
> puppetmaster.example.com

Why do you have to do it three times?

>
>
> # turn ourselves off and reboot
> chmod 644 /etc/puppet/ec2init.sh
> /sbin/reboot
>
> EOF
>
>
> # make runable
> chmod 755 /etc/puppet/ec2init.sh
>
>
> # call from rc.local
> sed --in-place "s#exit 0##" /etc/rc.local
>
> cat <<EOF >> /etc/rc.local
> test -x /etc/puppet/ec2init.sh && /etc/puppet/ec2init.sh
> exit 0
> EOF
>
>
>
> # unmount and create your AMI
>
> w00t!
>
>
>
>
>
> --
> Christopher McCrory
> To the optimist, the glass is half full.
> To the pessimist, the glass is half empty.
> To the engineer, the glass is twice as big as it needs to be.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
Nigel Kersten - Puppet Labs -  http://www.puppetlabs.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.

On Nov 7, 2010, at 10:45 PM, Nigel Kersten wrote:
> 
> 
> On Sun, Nov 7, 2010 at 9:52 AM, Christopher McCrory
<chrismcc@gmail.com> wrote:
> Hello...
> 
> # the hostname data is added via something like:
> # shell> ec2-run-instances ... --user-data "myservername"
ami-123abc
> # by definition, the first line MUST be the hostname
> # potentially in the future there could be more data
> curl --silent http://169.254.169.254/2008-02-01/user-data | head -n 1
> > /etc/hostname
> hostname --file /etc/hostname
> 
> # yes, thrice
> /usr/sbin/puppetd --no-daemonize --onetime --server
> puppetmaster.example.com
> /usr/sbin/puppetd --no-daemonize --onetime --server
> puppetmaster.example.com
> /usr/sbin/puppetd --no-daemonize --onetime --server
> puppetmaster.example.com
> 
> Why do you have to do it three times?
>  
I would like to know why you do it too.  I''ve needed to do that
because:
1a) This bug http://projects.puppetlabs.com/issues/3561
1b) Sets options in /etc/puppet/puppet.conf
2) Full run (Will be much shorter because lots of stuff was already done in the
first run)
3) One last chance just in case something didn''t work, timed out, or I
forgot a require.  (Finishes in seconds for me)


Also, I''d advise running puppet with "--verbose --debug" and
then logging the output somewhere.  Mostly because if the second run
doesn''t work, you can see it and have a chance at fixing it..

-- 
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.

>  When a generic EC2 instance is started it has a hostname of
> localhost.localdomain (or something like ip-10-111-222-33), a
> searchdomain of ec2.internal, and only the loopback address
> in /etc/hosts.  To get a puppet client to bootstrap correctly all three
> of these things need to be changed.  The searchdomain
> in /etc/resolv.conf is reset on each boot by the dhcp client.  To
''fix''
> this you can add ''supersede domain-name
"example.com";''
> to /etc/dhcp3/dhclient.conf. and add ''server.ip.addr.ess
> puppetmaster.example.com'' to /etc/hosts.  To get the hostname
changed
> without generating custom AMIs for each server I used a small script
> called by rc.local to set the hostname, then startup the puppet client.
> My complete setup is a little more complicated, but to just do these
> three things looks something like the following.
This is precisely why I set the contents of /etc/puppet/certname to
the "hostname" I want the box to have.  In /etc/cron.d/puppet and the
Puppet master''s config.ru, I set the --certname parameter to the
contents of that file, thus Puppet never has to deal with the
worthless IP-based hostnames assigned by EC2.

In /etc/cron.d/puppet:

puppet agent --certname=$(cat /etc/puppet/certname) --no-daemonize --onetime

In config.ru:

ARGV <<
"--certname=#{File.read("/etc/puppet/certname").chomp}"

-- 
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,

Excerpts from Christopher McCrory''s message of Sun Nov 07 12:52:48
-0500 2010:
> 
>   I wanted to be able to startup an EC2 instance with one command and
> have a fully functioning server without having to shell into each new
> instance and configure the bits to allow puppet to finish the
> configuration.  Here are some notes I came up with for bootstrapping an
> ec2 instance with puppet using Ubuntu 10.04. 
On the same topic I''ve outlined in a series of blog posts [1] how
Ubuntu
10.04 images can be bootstrapped and managed in EC2 and UEC. 

[1]: https://ubuntumathiaz.wordpress.com/category/puppet/

Once the puppetmaster is up and running starting a new instance is just
a matter of running one command:

  start_instance.py webserver
  start_instance.py proxyserver

It uses the native support for puppet provided in cloud-init so that the
standard Ubuntu AMI is used. The puppet master isn''t using auto-signing
as S3 is used to store legitimate puppet clients.

-- 
Mathias Gug
Ubuntu Developer  http://www.ubuntu.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.

On Mon, Nov 8, 2010 at 2:17 AM, Patrick <kc7zzv@gmail.com>
wrote:
>
> On Nov 7, 2010, at 10:45 PM, Nigel Kersten wrote:
>
> On Sun, Nov 7, 2010 at 9:52 AM, Christopher McCrory
>
> # yes, thrice
>> /usr/sbin/puppetd --no-daemonize --onetime --server
>> puppetmaster.example.com
>> /usr/sbin/puppetd --no-daemonize --onetime --server
>> puppetmaster.example.com
>> /usr/sbin/puppetd --no-daemonize --onetime --server
>> puppetmaster.example.com
>>
>
> Why do you have to do it three times?
>
>
>
> I would like to know why you do it too.  I''ve needed to do that
because:
> 1a) This bug http://projects.puppetlabs.com/issues/3561
>
That''s a legitimate reason, but there are ways to avoid this.

> 1b) Sets options in /etc/puppet/puppet.conf
>
? Why isn''t this just a templated config file? Then you just need to
supply
appropriate arguments on your first bootstrapping invocation.

> 2) Full run (Will be much shorter because lots of stuff was already done in
> the first run)
> 3) One last chance just in case something didn''t work, timed out,
or I
> forgot a require.  (Finishes in seconds for me)
>
Honestly, you should be discovering such missing requires in your testing
process. It''s not good practice to simply run another one "just in
case" in
my opinion.

-- 
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 Nov 8, 2010, at 9:54 AM, Nigel Kersten wrote:
> 
> 
> On Mon, Nov 8, 2010 at 2:17 AM, Patrick <kc7zzv@gmail.com> wrote:
> On Nov 7, 2010, at 10:45 PM, Nigel Kersten wrote:
>  
> On Sun, Nov 7, 2010 at 9:52 AM, Christopher McCrory 
>> # yes, thrice
>> /usr/sbin/puppetd --no-daemonize --onetime --server
>> puppetmaster.example.com
>> /usr/sbin/puppetd --no-daemonize --onetime --server
>> puppetmaster.example.com
>> /usr/sbin/puppetd --no-daemonize --onetime --server
>> puppetmaster.example.com
>> 
>> Why do you have to do it three times?
>>  
> 
> I would like to know why you do it too.  I''ve needed to do that
because:
> 1a) This bug http://projects.puppetlabs.com/issues/3561
> 
> That''s a legitimate reason, but there are ways to avoid this.
>  
> 1b) Sets options in /etc/puppet/puppet.conf
> 
> ? Why isn''t this just a templated config file? Then you just need
to supply appropriate arguments on your first bootstrapping invocation.
I''m not quite sure what you mean.  My puppet.conf is a templated config
file and I copy it in place using puppet during the first run.
> 2) Full run (Will be much shorter because lots of stuff was already done in
the first run)
> 3) One last chance just in case something didn''t work, timed out,
or I forgot a require.  (Finishes in seconds for me)
> 
> Honestly, you should be discovering such missing requires in your testing
process. It''s not good practice to simply run another one "just in
case" in my opinion.
But because of the randomness, I don''t always discover missing requires
during testing.  I do look over the log file though and if the last run did
something, I can then look into it and fix it.

It theory this might mean I need more testing.  In practice, the order
randomization makes it impossible to ever be sure there are no missing requires
that will cause a run to fail.

-- 
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 Mon, Nov 8, 2010 at 10:51 AM, Patrick <kc7zzv@gmail.com>
wrote:
>
> On Nov 8, 2010, at 9:54 AM, Nigel Kersten wrote:
>
>
> On Mon, Nov 8, 2010 at 2:17 AM, Patrick <kc7zzv@gmail.com> wrote:
>>
>> On Nov 7, 2010, at 10:45 PM, Nigel Kersten wrote:
>
>
>>
>> On Sun, Nov 7, 2010 at 9:52 AM, Christopher McCrory
>>>
>>> # yes, thrice
>>> /usr/sbin/puppetd --no-daemonize --onetime --server
>>> puppetmaster.example.com
>>> /usr/sbin/puppetd --no-daemonize --onetime --server
>>> puppetmaster.example.com
>>> /usr/sbin/puppetd --no-daemonize --onetime --server
>>> puppetmaster.example.com
>>
>> Why do you have to do it three times?
>>
>>
>> I would like to know why you do it too.  I''ve needed to do
that because:
>> 1a) This bug http://projects.puppetlabs.com/issues/3561
>
> That''s a legitimate reason, but there are ways to avoid this.
>
>>
>> 1b) Sets options in /etc/puppet/puppet.conf
>
> ? Why isn''t this just a templated config file? Then you just need
to supply
> appropriate arguments on your first bootstrapping invocation.
>
> I''m not quite sure what you mean.  My puppet.conf is a templated
config file
> and I copy it in place using puppet during the first run.
Perhaps I''m confused by your 1b) notation? Is this within the first
run? If so, then we''re in agreement.
>>
>> 2) Full run (Will be much shorter because lots of stuff was already
done
>> in the first run)
>> 3) One last chance just in case something didn''t work, timed
out, or I
>> forgot a require.  (Finishes in seconds for me)
>
> Honestly, you should be discovering such missing requires in your testing
> process. It''s not good practice to simply run another one
"just in case" in
> my opinion.
>
> But because of the randomness, I don''t always discover missing
requires
> during testing.  I do look over the log file though and if the last run did
> something, I can then look into it and fix it.
> It theory this might mean I need more testing.  In practice, the order
> randomization makes it impossible to ever be sure there are no missing
> requires that will cause a run to fail.
What would make debugging and discovering these situations easier for you then?

I have some simple rules that honestly removed most these problems for me.

Specify relationships within a class at the resource level.
Specify relationships across classes at the class level.

e.g.

class foo {
  file { "foofile":
    require => Package["foopkg"],
  }
  package { "foopkg":
    ...
  }
}

class bar {
  file {"barfile":
    require => Class["foo"],
  }
}

but I''m still interested to hear ideas about how we could make
discovering these issues easier.

Have you tried generating a --graph dot output? I''ve found that simply
visualizing the catalog like this can display obvious problems.


-- 
Nigel Kersten - Puppet Labs -  http://www.puppetlabs.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.

>> 3) One last chance just in case something didn''t work, timed
out, or I
>> forgot a require.  (Finishes in seconds for me)
>
> Honestly, you should be discovering such missing requires in your testing
> process. It''s not good practice to simply run another one
"just in case" in
> my opinion.
+1.  Catalogs that need to "converge" or are anything but a no-op on
their second run should be considered broken.

-- 
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 Nov 8, 2010, at 12:12 PM, Richard Crowley wrote:
>>> 3) One last chance just in case something didn''t work,
timed out, or I
>>> forgot a require.  (Finishes in seconds for me)
>> 
>> Honestly, you should be discovering such missing requires in your
testing
>> process. It''s not good practice to simply run another one
"just in case" in
>> my opinion.
> 
> +1.  Catalogs that need to "converge" or are anything but a no-op
on
> their second run should be considered broken.


*) My philosophy is this puppet.conf should be managed by puppet.
*) Sometimes a run won''t be completed correctly unless puppet.conf is
up to date at the start of a run.

Which of these do you disagree with?

-- 
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 Nov 8, 2010, at 11:10 AM, Nigel Kersten wrote:
> On Mon, Nov 8, 2010 at 10:51 AM, Patrick <kc7zzv@gmail.com> wrote:
>> 
>> On Nov 8, 2010, at 9:54 AM, Nigel Kersten wrote:
>> 
>> 
>> On Mon, Nov 8, 2010 at 2:17 AM, Patrick <kc7zzv@gmail.com> wrote:
>>> 
>>> On Nov 7, 2010, at 10:45 PM, Nigel Kersten wrote:
>> 
>> 
>>> 
>>> On Sun, Nov 7, 2010 at 9:52 AM, Christopher McCrory
>>>> 
>>>> # yes, thrice
>>>> /usr/sbin/puppetd --no-daemonize --onetime --server
>>>> puppetmaster.example.com
>>>> /usr/sbin/puppetd --no-daemonize --onetime --server
>>>> puppetmaster.example.com
>>>> /usr/sbin/puppetd --no-daemonize --onetime --server
>>>> puppetmaster.example.com
>>> 
>>> Why do you have to do it three times?
>>> 
>>> 
>>> I would like to know why you do it too.  I''ve needed to do
that because:
>>> 1a) This bug http://projects.puppetlabs.com/issues/3561
>> 
>> That''s a legitimate reason, but there are ways to avoid this.
>> 
>>> 
>>> 1b) Sets options in /etc/puppet/puppet.conf
>> 
>> ? Why isn''t this just a templated config file? Then you just
need to supply
>> appropriate arguments on your first bootstrapping invocation.
>> 
>> I''m not quite sure what you mean.  My puppet.conf is a
templated config file
>> and I copy it in place using puppet during the first run.
> 
> Perhaps I''m confused by your 1b) notation? Is this within the
first
> run? If so, then we''re in agreement.
Yes.  These are both the same run.  I just meant that is what happens that
really matters.
>>> 
>>> 2) Full run (Will be much shorter because lots of stuff was already
done
>>> in the first run)
>>> 3) One last chance just in case something didn''t work,
timed out, or I
>>> forgot a require.  (Finishes in seconds for me)
>> 
>> Honestly, you should be discovering such missing requires in your
testing
>> process. It''s not good practice to simply run another one
"just in case" in
>> my opinion.
>> 
>> But because of the randomness, I don''t always discover missing
requires
>> during testing.  I do look over the log file though and if the last run
did
>> something, I can then look into it and fix it.
>> It theory this might mean I need more testing.  In practice, the order
>> randomization makes it impossible to ever be sure there are no missing
>> requires that will cause a run to fail.
> 
> What would make debugging and discovering these situations easier for you
then?
> 
> I have some simple rules that honestly removed most these problems for me.
> 
> Specify relationships within a class at the resource level.
> Specify relationships across classes at the class level.
> 
> e.g.
> 
> class foo {
>  file { "foofile":
>    require => Package["foopkg"],
>  }
>  package { "foopkg":
>    ...
>  }
> }
> 
> class bar {
>  file {"barfile":
>    require => Class["foo"],
>  }
> }
> 
> but I''m still interested to hear ideas about how we could make
> discovering these issues easier.
The only ordering problems I''ve missed are ones between execs and files
in the same class, but every few months I miss one.

This third run, which normally functions the same as --noop, is just a last
check "just in case".  The only reason I don''t make it a
--noop is because if I screw up, I want the problem to be automatically be
fixed, as well as reported to me.

-- 
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.

>> +1.  Catalogs that need to "converge" or are anything but a
no-op on
>> their second run should be considered broken.
>
> *) My philosophy is this puppet.conf should be managed by puppet.
> *) Sometimes a run won''t be completed correctly unless puppet.conf
is up to date at the start of a run.
>
> Which of these do you disagree with?
In practice, I "disagree" with the first.  My /etc/puppet/puppet.conf
isn''t managed by Puppet.  On masters, all of /etc/puppet is deployed
via Capistrano.  On agents, /etc/puppet/puppet.conf is written by a
bootstrap.sh program when the server comes up for the first time.

My puppet.conf is only 5 lines long and has never changed.  I may be
in the extreme minority here.

-- 
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 Nov 8, 2010, at 2:03 PM, Richard Crowley wrote:
>>> +1.  Catalogs that need to "converge" or are anything but
a no-op on
>>> their second run should be considered broken.
>> 
>> *) My philosophy is this puppet.conf should be managed by puppet.
>> *) Sometimes a run won''t be completed correctly unless
puppet.conf is up to date at the start of a run.
>> 
>> Which of these do you disagree with?
> On agents, /etc/puppet/puppet.conf is written by a
> bootstrap.sh program when the server comes up for the first time.
> 
> My puppet.conf is only 5 lines long and has never changed.  I may be
> in the extreme minority here.
I used to do this, but then I wanted to turn on reporting on the clients and at
that point I started pushing out puppet''s config so that I
wouldn''t need to change puppet.conf on each computer individually. 
Later I changed it again to turn on pluginsync.  By that time I got tired of
managing puppet.conf in two places so I just manage it using puppet now.

Why would you use Capistrano to manage puppet.conf on your masters?  Does it
give you some advantage over just using puppet to manage itself?

-- 
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.

Nigel Kersten <nigel@puppetlabs.com> writes:
> Honestly, you should be discovering such missing requires in your
> testing process. It''s not good practice to simply run another one
"just
> in case" in my opinion.
That''s easy to say in theory, but extremely difficult to test in
practice,
since order is non-deterministic and therefore you may not notice a
missing requires unless you get lucky, even in test.  You need multiple
iterations in test to probabilistically find all missing requires, which
quickly becomes more trouble than it''s worth when the only drawback is
requiring multiple Puppet runs.

We too consider this to be a bug, but it''s a low-priority bug that we
fix
when we notice it, which can take a while.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

-- 
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.

> Why would you use Capistrano to manage puppet.conf on your masters?  Does
it give you some advantage over just using puppet to manage itself?
We have about half a dozen different web applications that we deploy,
all via git-archive(1) and Capistrano.  The Puppet master is one of
those and is deployed that way for consistency.  When I built it this
seemed completely reasonable and a nice way out of chicken-and-egg
problems.

-- 
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.