On 08/07/2013 08:25 PM, Phil Shafer wrote:
7 aug 2013 kl. 18:03 skrev Phil Mayers <[email protected]>:
Recently this fell apart on us, as the SSH key on the server changed and the
archival
transfers started to silently[1] fail.
Ick. Silence is deadly. This (and the other issues) is now PR 910647.
Cool.
All of which has me wondering if the feature is more trouble than it's worth.
We definitely should be making it more robust and stable, but to
me the value of catching each commit as a distinct delta is a win.
It should also have the commit time, user, and commit comment, if
given. Having this in a repo means one can ask questions like "who
has changed config in my network since last Friday?" or "when did
this statement get added in the first place?".
Agreed; preserving the separate commits and metadata is a big win, IMO,
and I really like the feature. It was surprising and disappointing to
find it had hung up!
(To the many people who suggested RANCID - thanks, but we already have a
config backup system. The question was specifically about strategies to
integrate the JunOS commit archive feature with such systems *given* the
failure modes I noted. This is a somewhat non-trivial problem to solve
in the general case; sure you can have a scheduled "fetch hourly"
belt&braces job, but that is both racy and discards data in some failure
modes)
What else can we do to make this more worthwhile?
Trigger a chassis minor alarm if archive has failed for >X minutes?
(Configurable, of course). The PR may say that, but I can't see it yet ;o)
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
