Joe McDonagh wrote:
[I'm re-arranging what Joe said a bit so I can keep replies to related
issues together.]
They're not
unix-agnostic resources for one (has that fundamental bit of philosophy
changed?), and they're unlikely to change in a way that you want puppet
to 'correct'.
Puppet has several types that are specific to some Unix(-clone) variant.
Three types that are for MacOS X, 'yumrepo' type is for a subset of Linux
distributions, and there are 'zone', 'zfs' and 'zpool' for Solaris. And
there is talk about creating 'iptables' and 'lvm' types, which are Linux-
specific. It's nice if types *can* be made generic, but I don't think
Luke has any rule that core types must be so, nor do I think there needs
to be such a rule.
I see this as being distinctly part of the provisioning portion of a
server life-cycle. I haven't looked at the discussion on -dev, but i'm
not sure these types really belong in core puppet.
I have never quite understood the distinction between provisioning and
other systems administration. Why is creating a file system provisioning,
but installing a package not?
That being said, some people have 'bootstrap' envs, which would be a
better place to have these destructive resources than in your production
environment.
What is potentially destructive is not so much *types*, as specific
resources. I can easily wreak havoc with an ill-advised file resource,
or with an augeas stanza that isn't cautious enough. Likewise, re-
creating a filesystem automatically doesn't *have* to be dangerous. I
would not hesitate much to let Puppet automatically re-create filesystems
containing pure caches, or the OS installation (which is just a short
kickstart installation away to be re-created).
/Bellman
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
