Revision control is not always work well, e.g:
1) some vendors have their config db in binary format
2) OS/firmware upgrade.
Min
> -----Original Message-----
> From: Andrew Fort [mailto:andrew.fort@gmail.com]
> Sent: Monday, April 18, 2005 6:28 PM
> To: Daniel Hagerty
> Cc: Network Automation List
> Subject: Re: CLI transactions
>
> On 4/19/05, Daniel Hagerty <hag@linnaean.org> wrote:
>
> > This is all doable. If you want rollback, you're going to
> > discover that it starts to curve back on the modeling questions: how
> > do you explain the rollback capabilities of a juniper
> versus those of
> > a cisco, and how does we use these capabiltiies within a
> larger, more
> > platonic notion of rollback?
>
> I only see the concept of a revision number in the model (and what the
> currently enacted revision is) - is anything else required?. As long
> as you can diff between the "current enacted configuration" (last
> transaction ACK) and the "to be applied configuration", you can
> produce configuration statements that will roll forward and roll
> backward (if supported by your device configuration language), or you
> can produce the whole configuration for rollback.
>
> The lurking assumption in that is "produce the whole configuration".
> Surely this implies a congruent tool (i.e., it is the GOD of its
> minions/devices). We can probably do equally well with simply
> reloading a previously known good configuration and reloading.
> However, if your tool is not congruent, and you implicitly change
> state (by reloading existing configuration), is there a danger of
> increasing entropy through such recoveries? I think this is going to
> be OK, but is this system what you might call a strong axiomatic
> system? (if so, we can't know for sure if it is going to be OK). I'm
> guessing this is "the problem" with rollback.
>
> As for building a device's configuration from a limited amount of
> overall 'state'...
>
> Could this be as simple as defining the device's role (or roles, in
> smaller networks cash is much more limited). Each of these defines
> pre-requisites, which gives you order, e.g. you must configure your
> IGP before you configure BGP, you must configure crypto keys before
> IPsec, and so on. But as always, syntax (i'm most familiar with IOS)
> is rolling back on the semantics. Is this type of text-template
> pre-requisite approach suitable for all device configuration
> languages? What about overlaps between roles.. This is probably where
> the tool relies on the implementor to avoid the implications of
> occam's razor.
>
> -andrew
>
|
|
