>>>>> "David" == David Lutterkort <[EMAIL PROTECTED]> writes:
David> On Fri, 2006-10-13 at 19:11 -0500, Narayan Desai wrote:
>> I think that most classing systems are probably roughly
>> comparable. From what I gather, puppet's groups are
>> half-specified server side, and half-derived client side.
David> My view is that they are fully specified server-side, but
David> that some decisions in the specification can be influenced by
David> data that the client provides; it's important though that the
David> client-provided data is generated in a very controlled way,
David> and is generated without any regard to what's in the
David> specification.
I agree.
>> This is a really important difference. For example, how do you
>> upgrade a solaris9 system to solaris10? We do this sort of thing
>> with bcfg2 all of the time, and it ends up being pretty important
>> for auditing reasons.
David> This in itself strikes me as a very hard problem; is the
David> auditing you mention mainly concerned with providing a clear
David> record of how the upgrade happened ?
I don't think it is actually all that hard, but that may be an
artifact of the modelling language we use. We actually had one guy who
needed to upgrade a cluster from SLES8 to SLES9. He was able to build
out his spec in a relatively short amount of time, and had nodes up
with the new config for testing within a day. We did similar things
building new spec for dapper, based on sarge.
The auditing is largely unrelated, it just requires a lot of server
side data to make real sense of things.
>> We can use client-derived data, but try not to use it for
>> anything too substantial. We use a disjunct normal form, so we
>> are sure that it is equivalent to boolean logic, though works in
>> a slightly more natural way, considering the goals.
David> Are you saying that the way in which client data enters into
David> server side decisions is restricted to certain circumstances
David> (I didn't understand the mention of DNF) ?
Again, I guess that I should have used newlines. Client data ingress
is tightly controlled.
We use something equivalent to DNF in the specification, we're sure
we've got the corner cases covered.
>> I can't really bring myself to get to deep into puppet's
>> language. I get the same sinking feeling when I look at
>> cfengine's language. They both don't seem to be describing things
>> that I care about; the granularity seems wrong to me. I am
>> probably not explaining it well; sometimes it is hard to
>> completely describe visceral reactions. I guess that I feel like
>> I am working in assembly.
David> I agree that it's easy to get lost in details with any of
David> these tools - though I don't really see how you could start
David> talking about higher-level things ('this is what a webserver
David> should be like') without getting into the nitty-gritty of
David> individual settings and copying around of config files.
That is true, details are certainly essential. I just always felt like
the proverbial blind men with an elephant when trying to use cfengine.
>> Conceptually, the overall model of bcfg2 contains two high-level
>> object types. There is a specification, which describes all
>> aspects of all clients in the network. We have a group of
>> clients, each of which is in some configuration state, perhaps
>> coordinated with the specification. The only actions that occur
>> in the system are validation and synchronization. Administrators
>> perform reconciliation between these objects. Any discrepancy
>> between the specification's idea of client state and that
>> client's state is viewed as a problem to be reconciled. These
>> problems can occur for a number of reasons. Perhaps the
>> specification has been updated. Alternatively, the client might
>> have been modified. The only actor in this system that can
>> reliably make a decision how a change should be reconciled is the
>> system administrator.
David> I am not sure I understand the difference between
David> synchronization and reconciliation in the above; it sounds
David> that any changes to clients need to be ok'd by an admin on a
David> case-by-case basis .. is that true ? Or are you saying that
David> synchronization is the act of changing the client's config in
David> accordance with the centralized spec whereas reconciliation
David> is taking things from the client and putting it into the
David> centralized spec ? That sounds pretty neat and slick.
synchronization is when the specification is enacted on the
client. Reconciliation is the act of deciding which bits can be
enacted. I have some sandboxy implementations of client -> server spec
sync, but this is a pretty hard problem, particularly as the
specification gets more abstract...
David> You also mentioned a second high-level object type; seems
David> like you skipped its description ;)
The clients are just things that interact with the specification in
our model. they have a state that can be meaningfully compared to the
spec. In this way, they can really be anything...
-nld
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
