Narayan Desai wrote:
First off, doing it pointwise isn't really good enough, and I have a
lot of trouble believing that you can reliably do this if the source
of the configuration was a random admin doing things in the way they
think is best. In order to build your abstraction mechanism, you've
needed to encode a bunch of policy. This may seem innocuous, but for
these purposes, it can cause a lot of trouble.
You are assuming this, and you are wrong. I defy you to find policy
that I've somehow encoded into Puppet's abstraction layer. I really
don't get this; what have I done to make you assume so much against
Puppet? I'm just as big a believer in not encoding policy into tools,
and there are a lot of places where I very consciously avoided it.
Given that you're wrong about my encoding policy, the rest of your
argument basically falls flat. You can have as much trouble as you want
believing anything, but at this point you're just casting aspersions
based on what you assume about me and Puppet, not based on any actual
knowledge or experience.
I stand by my statement that the basic frameworks behind Puppet and
bcfg2 are pretty similar; their usage model is currently quite
different, because of how we have differently focused during its
development and because you have been able to develop bcfg2 within a
specific environment with a specific set of users.
Note that I am not saying that you can't implement any of this
functionality, just that it will be hard to make it robust enough to
cope with administrators, due to the variety of methods people
use. You've previously stated that you aren't so interested in
supporting administrators doing things their way, rather that they
should do things the right way(tm), so I guess this is just another
case of differing priorities.
I'm guessing I would have some difficulty surviving on Puppet if I
didn't care about how sysadmins worked. Yes, my long term goal is to
stratify the sysadmin world, and to that extent I'm not concerned about
what the current generation of sysadmins think about my long-term plans.
However, Puppet as a tool is meant to be used by today's sysadmins,
not the sysadmins of the future.
It's clear that this is getting nowhere, because I'm trying to talk
about functionality, and you're just relying on your assumptions about
Puppet and me. Your statement above attempts to preclude the
possibility of Puppet ever matching bcfg2's purported functionality just
because you don't think I can match bcfg2's "robust" implementation,
which is, pardon my french, utter crap.
Luke> And can you now please define reconciliation?
The idea of reconciliation is that administrators can interpolate
inputs from multiple sources (including the specification and local
modifications) into a specification of increasing accuracy. One of the
most compelling features that bcfg2 has is that the specification can
tell you how accurate it is, in a holistic sense.
This is *exactly* how most sysadmins would use Puppet.
I would *love* to see you somehow show that Puppet can't support this.
Really. Because at this point, you're just making crap up about what
Puppet can and can't do, and then you're taking your made-up beliefs and
trying to somehow claim that Puppet is fundamentally flawed because of them.
Once again, this is getting nowhere. At the least, we should probably
take this offline, because it's getting embarassing.
--
Do not think of knocking out another person's brains because he differs
in opinion from you. It would be as rational to knock yourself on the
head because you differ from yourself ten years ago. -- Horace Mann
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
