On Wednesday, August 15, 2012 11:41:34 AM UTC-5, Douglas wrote:
>
> On Wed, Aug 15, 2012 at 7:38 AM, jcbollinger
> >
> wrote:
> > I agree that the problem seems general. Does it not work to put your
> > Apt::Source resources into their own classes, and assign those classes
> to
> > your in
On Wed, Aug 15, 2012 at 7:38 AM, jcbollinger wrote:
>
>
> On Tuesday, August 14, 2012 11:37:26 AM UTC-5, Douglas wrote:
>>
>>
>> Not really. I have three run stages that have been working fine. It
>> was when I tried to add
>>
>> Apt::Source <| |> -> Exec["apt-update"]
>> Exec['apt-update'] -> Pac
On Tuesday, August 14, 2012 11:37:26 AM UTC-5, Douglas wrote:
>
>
> Not really. I have three run stages that have been working fine. It
> was when I tried to add
>
> Apt::Source <| |> -> Exec["apt-update"]
> Exec['apt-update'] -> Package <| |>
>
> to site.pp to globally enforce apt source ins
On Tue, Aug 14, 2012 at 6:09 AM, jcbollinger wrote:
>
>
> On Tuesday, August 14, 2012 12:12:33 AM UTC-5, Douglas wrote:
>>
>> Trying to force puppet class execution order with:
>>
>> Class['lvm'] -> Class['network'] -> Class['apt'] -> Class <| |>
>>
>> This is giving me:
>>
>> err: Could not retri
Dreaded. I have found that using the .dot files that puppet --graph option
produces sometimes helps see those dreaded dependency cycle issues (and
some times it does not). I recommend graphviz for anyone on linux for
generating png files for the .dot files (not sure for Windows).
On my setup
On Tuesday, August 14, 2012 12:12:33 AM UTC-5, Douglas wrote:
>
> Trying to force puppet class execution order with:
>
> Class['lvm'] -> Class['network'] -> Class['apt'] -> Class <| |>
>
> This is giving me:
>
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Resour
