On Nov 8, 2010, at 11:10 AM, Nigel Kersten wrote:
> On Mon, Nov 8, 2010 at 10:51 AM, Patrick <kc7...@gmail.com> wrote:
>>
>> On Nov 8, 2010, at 9:54 AM, Nigel Kersten wrote:
>>
>>
>> On Mon, Nov 8, 2010 at 2:17 AM, Patrick <kc7...@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-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.
