On Wed, Oct 20, 2010 at 12:09 PM, Martin Langhoff
wrote:
> On Wed, Oct 20, 2010 at 3:00 PM, Mohit Chawla
> wrote:
>>> Except that some definitions may be gone. That's what worries me. Sure
>>> I can read the pp files as they are today.
>>
>> That's probably true for any tool or method. Unless it
On 10/21/2010 05:33 PM, Martin Langhoff wrote:
> On Thu, Oct 21, 2010 at 4:56 AM, Felix Frank
> wrote:
>> I guess what you're getting at is this: No, puppet is not exactly good
>> at "uninstall this now and from then on, don't care about it anymore".
>> This is not what puppet has been conceived f
On Thu, Oct 21, 2010 at 4:56 AM, Felix Frank
wrote:
> I guess what you're getting at is this: No, puppet is not exactly good
> at "uninstall this now and from then on, don't care about it anymore".
> This is not what puppet has been conceived for, though.
OK - but putting (config) files into plac
On 10/20/2010 06:56 PM, Martin Langhoff wrote:
> Except that some definitions may be gone. That's what worries me. Sure
> I can read the pp files as they are today.
>
> - John had a webmail server class assigned to server Frodo. Service
> apache must be running, an /etc/apache/conf.d/webmail.conf
On Wed, Oct 20, 2010 at 3:00 PM, Mohit Chawla
wrote:
>> Except that some definitions may be gone. That's what worries me. Sure
>> I can read the pp files as they are today.
>
> That's probably true for any tool or method. Unless it was in version
> control.
Not true of packages under any modern p
On Wed, Oct 20, 2010 at 10:26 PM, Martin Langhoff wrote:
> Pretty fundamental feature :-)
>
You don't have random scripts doing random business. If the puppet modules
have been written nicely, I don't see any reason to be unable to go through
them once, understand the structure, and work from th
On Wed, Oct 20, 2010 at 12:03 PM, Patrick wrote:
> I wouldn't call it unreasonable. I would call it "lack of a really cool
> feature".
Pretty fundamental feature :-)
I am not saying Puppet needs to magically know what I'd like to happen
with the file. However, it should at least give us enough
On Oct 20, 2010, at 8:00 AM, Martin Langhoff wrote:
> On Mon, Oct 18, 2010 at 9:13 AM, jcbollinger
> wrote:
>> I'm guessing you mean you have written sub-*classes* to do that job.
>> That is indeed the Puppet way to do it, and I don't find it at all
>> ridiculous.
>
> As a puppet newcomer, tha
On Mon, Oct 18, 2010 at 9:13 AM, jcbollinger wrote:
> I'm guessing you mean you have written sub-*classes* to do that job.
> That is indeed the Puppet way to do it, and I don't find it at all
> ridiculous.
As a puppet newcomer, that is a bit surprising, and IMO unreasonable.
Imagine you are join
On 10/19/2010 3:29 PM, jcbollinger wrote:
On Oct 18, 9:03 am, David Schmitt wrote:
Exactly. If done right, this can be achieved by using purging on the
proper directories (like /etc/http/conf.d) to keep away unmanaged
contents. For the most things this obviates the need for a ::no class
altoge
On Oct 18, 9:03 am, David Schmitt wrote:
> Exactly. If done right, this can be achieved by using purging on the
> proper directories (like /etc/http/conf.d) to keep away unmanaged
> contents. For the most things this obviates the need for a ::no class
> altogether.
But purging makes my skin craw
On 10/18/2010 3:13 PM, jcbollinger wrote:
On Oct 18, 5:19 am, Daniel Maher wrote:
I am curious to know what is the best practice for removing a module
(and the resources it maintains) from a system ?
[...]
I have occasionally written sub-modules to do the work of cleaning the
resources awa
On Oct 18, 5:19 am, Daniel Maher wrote:
> I am curious to know what is the best practice for removing a module
> (and the resources it maintains) from a system ?
[...]
> I have occasionally written sub-modules to do the work of cleaning the
> resources away (ex. « webservice::no »), but this se
13 matches
Mail list logo
