On 9/22/2010 2:31 PM, michoski wrote:
> On 9/22/10 12:16 PM, "Les Mikesell"<[email protected]> wrote:
>> Well, no. I don't consider reading and sometimes responding to things
>> on a mail list as being fed. Or that I have anything to lose from
>> having an opinion that differs from yours. So far I don't think
>> cfengine does what I need but it is interesting enough to watch.
>
> Fair enough, but I'd like to expand this based upon my own personal
> experience...
>
> Based upon my trials and tribulations (over the past 10 years), no tool does
> what I need it to out of the box. This is the same for bcfg, blade logic,
> cfengine, isconf, puppet, etc (alpha order). Each consists of a steep
> learning curve, followed by waves of understanding (including understanding
> the shortcomings that must be worked around), and then a somewhat
> site-specific mastery that typically involves process and tool development
> outside the configuration management platform itself.
Agreed, but this is a matter of philosophy, not details, I think. I
need something that gives central control over groups of load-balanced
sets of machines where testing means from the perspective of a remote
viewer and preferably knows something about the grouping (i.e. that some
number of a group can be out of service at once and what to do if you
exceed that number). Also when deploying changes, I need fine grained
central control of the timing and the ability to skew the rollout so the
equivalent groups in different locations happen on different days
(generally...). And even though I want central control, it needs to be
redundant, able to work from at least 2 locations.
> Configuration management really is a discipline unto itself, which requires
> a lot of time and planning to do right. I feel this is an obvious shift the
> industry has slowly acknowledged, but still needs work to fully understand.
> For example, being asked to "just make configuration management happen" as
> an extra hat to wear without any insight into the development lifecycle or
> guiding principles usually won't have desirable effects.
Agreed again, but I just don't see the remote testing, split group
deployment, and fine grained central control as inherent concepts. I'd
also like to have version tracking from source->binaries->qa->production
(cross platform, of course...). That can probably be pushed into
something else that writes cfengine config files but I'm not sure I see
the point compared to any number of other ways that would end up with
finer-grained central control - unless maybe it would hide some
cross-platform differences in a useful way.
The end result that I'd want is a simple interface for QA people to make
a new application release available for production, and another for
operations to deploy it to groups of machines with very specific control
over timing and auditing of what happens. That's probably not
impossible, but it seems far removed from cfengine's focus.
> Any tool one selects will take some time to understand and extend. I'm glad
> to hear Nova is attempting to offer a boxed solution to many of the hurdles
> IT management faces with configuration management, but realistically expect
> to do a fair amount of work integrating any new tool with our environments.
> I've experienced the same amount of "integration" work in commercial
> solutions charging thousands just to license the endpoints.
Ours is weird enough that nobody is going to box a solution - and I
don't expect that. But, I'm not prepared to suggest using something
that is both expensive and needs a lot of work without some testing to
know it will do what we need - and I'm not particularly motivated to do
that testing when the free version isn't the same as what we'd end up
needing. And no, that's not a negative personal attack on you, Mark,
it's just the way I feel.
--
Les Mikesell
[email protected]
_______________________________________________
Help-cfengine mailing list
[email protected]
https://cfengine.org/mailman/listinfo/help-cfengine
