[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf BCP-07 vs configuration management
At 04:28 PM 11/28/2001 -0800, email@example.com wrote:
>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.