[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Separation of configuration and control - good or bad?
- To: firstname.lastname@example.org
- Subject: Re: Separation of configuration and control - good or bad?
- From: Eliot Lear <email@example.com>
- Date: Wed, 21 May 2003 12:11:38 -0700
- Cc: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507
[I am *still* not receiving netconf mail. Please include me in responses].
This is true if you are updating the entire configuration, or if your
interfaces are sequentially named on the fly. Those circumstances do
exist, and some care must be taken to avoid such race conditions.
Locking is a viable approach to tackling the problem. The granularity
of locking is something I addressed in my previous message.
What I was expressing is that if you wish to, for example, delete an interface without
deleting one that might be created, then after you have done your "get" operation
you must lock the configuration to prevent, for example, another interface being created
by another user that will be SILENTLY deleted when you submit your delete operation.
By the way, I didn't say that locking was useless. I believe we are
arguing over granularity.
Try it. You won't like it.
For some value of "serious". I would agree that there is a need for
locking on big hardware. On small hardware the need is perhaps less.
That's a marketing decision (indeed some hardware might not even support
locking at all). Ultimately the protocol attempts to allow the
expression of what the underlying hardware and software can reasonably
support without having to warp any given operating model.
The absence of an agreement upon how to express locking makes my point even more strongly.
We should not adopt an approach that relies upon locking to achieve robustness. The draft
requires locking if it is not to introduce race conditions not exhibited by other approaches.
Therefore, following your lead, the draft is seriously broken. There are much better solutions.
Solutions that do not introduce these race conditions.
In any event, without having a standard meta-data model you can only
have one big lock. And that turns out even to be an improvement over
what we have today. And I see no reason not to include such a thing.
This is just hyperbole. Adding even a non-granular lock fixes your
You have missed the point. The spec forces a mechanism that makes many
simple configuration operations fragile and dangerous. Nothing to do with the
schema. All to do with the model adopted in the draft.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.