I dig the pragmatic case, where it is essentially impossible to move forward without piecemeal manipulation of a given file. It seems important to note at that point you're in it for bare manageability, and no longer in the "reproduce the the whole infrastructure from scratch" use case. I think that puts us out on a limb when talking about what Chef does or should do.
Having an in-built file edit facility is great, as is arbitrary ruby or script evaluation or gem inclusion in Chef. They all let you get the job, dirty or not, done in a rich unified context. I'm never going to argue against that, and edit file and family is available whether or not we make it core Chef or provide a resource interface. It goes a bit far to instantly equate discussions of potential primitives instantly with the "opinionated meme". Every existing primitive has plently of opinions baked in to it.
The problem I will continue to have is that, though file edit is like script/execute in that you have to bring your own idempotence contract, with file edit - especially in the very situations where you've been forced into this corner - it is orders of magnitude harder to write idempotency correctly. If you fail to consider edge cases, overlaps, past typos, etc., I've seen the big old' shark bite in the ass that is entirely not visible in any of the current code, and the hunt begins on what horror you birthed perhaps long ago so you can actually move forward again - but this time in the middle of an outage.
I'd go so far as to argue that to be generally successful when approaching non-trivial file edit tasks you have to build and maintain a mental map of what is out there and what has gone before, a form of tribal knowledge that might actually be the contrapositive of idempotent: if you are not in the desired state, then you'd better know if you ever tried to apply the function.
What would interest me is knowing how promoting file edit to a resource could perhaps help people who find themselves wanting/ needing/ thinking they need to use file edits.
-A
On Fri, Jun 15, 2012 at 1:06 PM, Adam Jacob < " target="_blank"> > wrote:
>
> Yeah - I think I was wrong, and you were right: we should've made it a resource.
>
> I was wrong about dry run mode and OpenID, too. :)
>
> Adam
>
> On Fri, Jun 15, 2012 at 7:29 AM, Christopher Brown < " target="_blank"> > wrote:
> > This exchange (Aaron and Lamont) is almost exactly the conversation
> > Adam and I had when I first had Nuo write file_edit and that's why we
> > decided to bury it. It's useful, but cuts against the grain.
> > Pragmatically though, there are files over which you may not have full
> > control. We constantly tell people that you can ease into as much
> > Chef as you can take, without having to rigidly accept our model.
> > Doesn't saying "but you can only manage whole files, rendered by Chef"
> > blunt that argument?
> >
> > -C
> >
> > On Fri, Jun 15, 2012 at 7:21 AM, Aaron Peterson < " target="_blank"> > wrote:
> >> Lamont "I promise I'll only use it correctly, tactfully, and rarely"
> >> Granquist, your argument does not persuade. :). But even if you held
> >> true to that...
> >>
> >> -1, I could never recommend this, and it fails most methodological
> >> tests that Chef works under.
> >>
> >> It should be trivial to take the whole file and templatize it. If you
> >> cannot just easily take the whole file under management, that means
> >> there is interestingly different content "out there" that represents
> >> unmanaged yet important operational state. Now you are making
> >> successive error-prone edits to a collection of interestingly
> >> different files, and there is no guarantee that you will not have
> >> drift unless you have already analyzed the differences across the
> >> collection, at which point you might as well manage the whole thing.
> >>
> >> Even if it is consistent, or the file differences are reproduced
> >> normally by an underlying OS or software process, I had better only
> >> add but never delete file edits to recipes, because if ever a machine
> >> misses a past edit because it is off or whatever, or we launch a new
> >> machine, we won't be creating the file correctly.
> >>
> >> Generally, if you cannot always guarantee the recreation of the file
> >> in its current state, you have entombed state and risk and have failed
> >> to create an infrastructure you can reason about or rebuild.
> >>
> >> Making it a full resource is the Chef imprimatur to use it, and this
> >> isn't just rope, it's already tied into a noose and permanently
> >> attached to a scaffold. IMO.
> >>
> >> -a
> >>
> >> On Jun 14, 2012, at 14:02, Adam Jacob < " target="_blank"> > wrote:
> >>
> >>> I wonder if it's time to finally turn that into a resource, even
> >>> though I think there is near universal agreement it's not a great
> >>> idea?
> >>>
> >>> Adam
> >>>
Archive powered by MHonArc 2.6.16.