> I tend to disagree with your view of the world.
The problem you have with my world view boils down to the fact
that it hinges on "magic". There is a key technology needed that does
not actually exist yet, and so my world view doesn't work.
My role here is to remind you that there are two ways to solve the
newtonion motion problem, and the way in which you invent calculus
first is easier that the other way (namely, all the other brute force
ways). Your problem is not newtonion motion, but it may as well be.
My actual copious free time hacking is to make my world possible.
You can see this particular piece of missing magic missing, and
you are quite rightfully saying "excuse me, show me some bloody
proof!".
You need a "magic" denotational semantic approach that is more
powerful and general than Scott Strachey. Such a thing does not exist
on earth yet. Scott Strachey (and denotational semantics in general)
has fallen out of favor due to some corner cases (non-determism and
concurrency) that existing models don't handle well, as well as the
fact that doing it well is Hard.
I am suggesting that denotational semantics doesn't have to be
this way.
> a) Database rollbacks are simple because data objects (at least in the
> pure relational world) just carry data and no side effects. Network
Preaching to the choir. Search the archives of this list and
infrastructures and you will see me saying the same thing.
I will also point out that mathematical reasoning on languages
with side-effects is old hat; see R5RS section 7.2 for a denotational
semantic of scheme that includes treatment of side-effects in the
language.
> b) Reloading whole device configurations because a network-wide
> transaction failed would be a desaster in some environments.
Then let's break the problem in two, shall we?
1. You have devices that can possibly be moved between states short
of "reconfigure from scratch". If so, "simple matter of
programming". Most things I've seen on a cisco fall into this
category.
2. The only way you can possibly implement a rollback involves the
"disasterous total reload". If you *have* to implement rollback
on such a device, it sounds like you have a hard problem that is
out of scope for "simple configuration magic". If you can somehow
build a meta level to hide the rollback (common in system
administration), help can be provided here. But how to be clever
is your problem. Anyway, borderline out of scope since we can't
automate human creativity.
> c) SNMP, the turing machine of network management, requires oracles
> to do anything useful and after more than 15 years of experience
I'm aware of this. I can't immediately offer you anything to
soothe your concerns here other than "that's not hard". The side
effect issues you mention early are much closer to generalized "hard".
> d) Several vendors seem to oppose the idea of making rollback
I am not here to convince your vendors to do the right thing. If
some vendors have clue and some vendors do not, vote with your
pocketbook.
> While in a pure abstract view an oracle can solve all these problems,
> I believe that the proper devision of work requires that devices do
> their share of work to support robust network wide configuration
> transactions.
That is the joy of abstraction. Who said that the oracle is
centralized? You did.
Such an oracle is a concept. Oracle implementation is a detail we
wish to work out.
I don't actually see how the concept of an oracle fundamentally
disagrees with your assertion that their is a division of labor. If
anything, I would strongly agree.
Follow-Ups:
References:
|
|
