I will be snapshotting the VM to lower the rollback effort there, but good
point at that. Otherwise that saves me a bunch of preprod fiddling, thank you.
On Mon, Aug 24, 2015 at 01:35:21PM -0700, Wyatt Alt wrote:
> On 8/24/15 12:59 PM, Christopher Wood wrote:
> >(Although I may dump/restore the d
On 8/24/15 12:59 PM, Christopher Wood wrote:
(Although I may dump/restore the data via puppetdb since that's the actual api
to the data, we do not log in via PostgreSQL.)
Others can speak to the rest of the plan, but just to clarify in case
I'm understanding you right: the PuppetDB import/expo
I am not seeing a large amount of blog entries complaining about this upgrade,
how has that gone for you? Is there anything you found particularly painful?
Would you have done anything different in retrospect?
I'm staring down a 3.7.2 -> 4.2.1 upgrade and after reading a number of docs
the back
I believe you're looking at it from the wrong view point if you're
trying to simply use an existing AMI and not for the creation of a new
AMI to load.
The cloud-init configuration can be manipulated using the user-data
passed to the EC2 instance on initialization just as you can trigger the
p
I thought this would be super easy but hit a road block (at least in terms
of an elegance solution - yes I know how to use exec type with sed and grep
but that feels a bit to much like a workaround)
My requirements is for a file at /etc/cloud/cloud.cfg that looks like this:
users:
- default
Thanks .. that module did changed the ownership of libdir.
Regards, Patrick.
Op maandag 17 augustus 2015 17:55:51 UTC+2 schreef Josh Cooper:
>
> Hi Patrick,
>
> On Thu, Aug 13, 2015 at 6:10 AM, Patrick G. > wrote:
>
>> Hi,
>>
>> When running puppet agent -t I get
>>
>> Notice: /File[/var/lib/pu
