[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf BCP-07 vs configuration management

Hi Randy...

At 04:28 PM 11/28/2001 -0800, rpresuhn-lists@dorothy.bmc.com wrote:
>  For
>example, though the document spends quite a bit of time on the
>transaction concept, only one sentence in section 5 (2) seems
>to even touch on the issue of versioning of configurations,
>and almost nothing on the concept of identifying configurations.

Well, for my own contribution on this, my professional affiliation might 
make discussing the right way to do configuration versioning a, uh, 
conflict of interest. :)

No, seriously, you'll notice that in a prior version (don't bother digging 
it out, just take my word for it) we had this involved pseudo-state-machine 
for configuration deployment which included this very task area (archival) 
as an important step, with certain detail.  We took that out, mostly 
because it seemed that the readership was evenly split between having that 
deployment roadmap/state machine either not matter to them, or having it 
give them migraines.

Since we have in fact retained the separate "Deployment and Security 
Issues" section though, I think that text like what Jon proposed is 
appropriate for that section.  Independent of ITIL's take on the matter 
(which, although valid and defensible, does appear to have a fairly 
subjective point of view and isn't what I'd call 'normative'), I would 
enhance it with a few other practical points..

First of all, there's the notion of simply version identification (perhaps 
we could add that into whatever section we have in Section 3 about 
including last modified stamps as MIB table row design?).

In practical usage, though, there are considerations for how one does 
config version *archival* (forgive me if I'm driving a lot further down the 
road than you intended, but I think it's vitally pertinent, no?).  In 
modern practice, that's generally about storage of a CLI-based 
configuration, using homebrew scripting or something a la Rancid or the 
Gold Wire Formulator product.  The most common usage, or certainly the 
simplest, is to treat the unit of archival (CLI or the results of a MIB 
walk) as opaque with respect to the archival itself.  An interesting 
operational point, however, is that the connection between the SNMP 
configuration and the CLI isn't always direct (mostly meaning, the way the 
management information is structured is often not the same between a 
config-savvy MIB module and the CLI bits covering the same function), but 
the same changes should have the same effect (i.e., tweak the CLI--it may 
have a nonobvious change in the config as reported by SNMP, but make the 
same CLI tweak again, and the same change should be evident).

Finally, there are devices that don't actually *lend* themselves to having 
a complete "config" for archival as such.  A cable modem is the main 
example that comes to mind.  DOCSIS specifies that I can set a 
configuration in bulk, but I can't retrieve a configuration in bulk.  The 
practical upshot of this is that one needs to scope the configuration one 
cares about in the version archival practice, and implement it carefully 
into the management application.

Anyways, thanks much for your thoughtful review of the BCP.